如何解决 DevOps 与 ITSM 之间的文化冲突

自从 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 文化冲突？ 请在评论中分享您的策略。