自 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 条评论