自从 DevOps 出现以来,它一直与 IT 服务管理 (ITSM) 及其 ITIL 框架相抗衡。有人说“ITIL 正受到围攻”,有人要求您选择立场,而另一些人则认为它们是互补的。 真正的事实是,DevOps 和 ITSM 都有支持者和反对者,并且每种方法都会影响软件交付和整体企业文化。
文化 冲突
DevOps 和 ITSM 文化冲突的核心在于 ITSM 是流程密集型的,以至于当组织构建更多以人员和技术为中心的流程来推出产品和服务时,会阻碍业务发展。 中小型企业有时会淹没在 ITSM 的细节中,而大型企业可能会过度建设,因为官僚机构笨拙地将 ITSM 置于客户交付之前。
DevOps 为软件交付带来了敏捷性和速度的承诺,这对各种规模的组织都很有吸引力。 持续交付的主题为仍在缓慢而过时的瀑布和瀑布衍生软件开发生命周期 (SDLC) 流程中挣扎的组织描绘了内部转型和重振客户关注的美好景象。
解决文化冲突
重要的是,在可以的时候,通过加倍关注软件开发、运营和支持的可见性,来宣布 DevOps 和 ITSM 之间的休战。 避开当团队争论 DevOps 和 ITSM 的优点时不可避免地爆发的“旧与新”或“快与慢”的争论。
根据您处理的个性,将对话限制在项目、软件交付和团队上可能很困难。 在这些情况下,是时候通过关注协作、监控和报告来消除对话中的宗教色彩了。 无论您遵循 ITSM 还是 DevOps,这些都是支持产品和服务交付的原则。
对流程变更采取协商方法是避免文化冲突的关键。 就您计划进行的任何可能改变其工作方式的流程变更,征求您的开发和运营团队的参与和意见。
经验教训
虽然最近的一些文章赞同 ITSM 和 DevOps 的共存,但由于对敏捷性的需求日益增长,我们许多人已经不再讨论 ITSM。 服务台之外的一些 ITSM 原则将保留,但它们将被纳入 DevOps 交付流程中。 在 2020 年的 IT 行业中,敏捷并能够快速调整以应对市场需求变得越来越重要。 DevOps 的构建是为了快速调整。 ITSM 没有快速调整的声誉。
从伟大的 ITSM 和 DevOps 文化冲突中可以吸取一些重要的教训,包括
- 关于软件开发过程的信息和报告对于开发人员和整个公司的其他利益相关者仍然至关重要。
- 对于那些熟悉 ITSM 的人来说,DevOps 文化转型仍然是一个挑战,并且它提高了某些企业内部文化变革的风险。
- ITIL 从 v3 到 v4 的缓慢发展为 DevOps、GitOps、AIOps 和其他技术提供了发展空间,组织开始采用这些技术。
- 协作应该是现代软件开发中的日常规则。 DevOps 比 ITSM 讲述了更好的协作故事。
- DevOps 和 ITSM 都需要专业的和协商的实施方法。
您正在采取哪些措施来解决组织内部的 ITSM 与 DevOps 文化冲突? 请在评论中分享您的策略。
4 条评论