【引言】

伴随着过去十年里DevOps实践在全球的盛行，越来越多的传统IT组织开始思考我们是否该做出一些改变。ITIL®作为全球服务管理的最佳实践仍被很多传统行业所广泛应用。从运维视角出发，ITIL®主张通过安全、稳定的流程化的管理来为客户交付价值。然而DevOps主张通过高速度和高质量的交付软件和功能特性为客户交付价值。

众所周知，传统企业其核心业务不断被互联网企业凭借全新的平台化商业模式所颠覆的案例比比皆是。我们不难发现，由于传统企业组织结构和组织文化的原因，传统行业都以ITIL®流程化的管理方式为主。然而在互联网行业中，组织结构是则扁平化的。这种扁平化的组织结构为组织能够DevOps实践，为客户高速度高质量交付价值，创造了必要前提条件。正如由EXIN国际新型科学考试学员2019年底基于全中国数千名DevOps Master认证持有者调研报告中所指出，数字化转型是传统的IT组织从ITIL®流程化的管理实践切换到DevOps实践的三大核心原因之一。

然而这并不意味着所有传统企业都应该立即放弃传统流程化的IT服务管理，而完全采纳DevOps实践。在做出全面采纳DevOps实践，还是有选择性的结合DevOps思想优化现有流程的选择之前，首先应该评估自己企业从组织结构和组织文化是否已经准备好了。如果不能因地制宜，忽略组织结构、文化和管理层转型的战略部署，盲目采纳DevOps实践则会导致欲速则不达，事与愿违。

在由国际数字化能力基金会-IFDC所发布的数字化转型全球最佳实践-VeriSM管理网格模型中所描述，ITIL®和DevOps同属于数字化转型中管理网格四大维度中的管理实践维度，企业应根据自身的情况来选择响应的管理实践，而没有一个one size fit all的管理实践。

那么既然不建议选择全部抛弃现有ITIL®流程，也不建议立刻全部拥抱DevOps实践。让我们探讨一下IT服务管理中的ITIL®流程如何可以与DevOps共存，携手并进。 

DevOps四大天王级的人物，《凤凰项目》和《DevOps实践指南》作者Gene Kim先生给出的建议为:“传统的ITSM产品是基于工单系统。当发生某些事件或有人提出变更时，他们必须创建工单，然后才能启动一组手动任务，通常由不同的人员所执行。DevOps可以为这种传统的ITSM环境带来自动化。DevOps原则和实践可以与ITIL®流程相结合的关键是ITIL®流程中许多部分现在可以实现自动化，解决了重大挑战，尤其是在配置，发布和部署管理流程中。”在他《DevOps实践指南》中指出DevOps与ITIL®不兼容是一个误区。

DevOps与ITSM

误区: DevOps与ITIL不兼容

DevOps 实践可以与 ITIL 流程相互兼容。但为支持DevOps实践所倡导的更短的前置时间与更高的部署频率, ITIL 流程中的许多方面可以完全通过自动化实现, 这样就解决了许多与配置和发布管理流程相关的问题。由于DevOps在服务事件发生时要求快速检测和恢复,  ITIL 在服务设计、事件和问题管理方面的规程仍然一如既往地重要。

 ——选自《DevOps实践指南》

上图引用来自前雅虎额CIO Mike Kail发表的文章“ How ITIL Can Co-Exist with DevOps”

为了帮助读者充分的了解在ITIL和DevOps之间存在哪些差异，又能如何共存，我们希望通过引用由清华大学出版社发行的《DevOps精要：业务视角》一书5.4章节的部分分享给大家。书中作者指出：

在过去二十多年里，许多公司在ITIL上投入了数百万的英镑、美元和欧元。这些支出通常都有其正当的理由：组织寻求管理信息科技相关问题的方案，并且努力改进IT部门的效率。在企业IT管理领域，类似ITIL和COBIT的知识体系通常被认为是行业标准，尽管在这里用标准一词并不完全准确。很多公司希望从ITIL中获益，很多公司其实也一定程度地获得了投资回报。

DevOps专家们相信，并没有根本性的困难。本节开头引自《DevOps实践指南》的内容是一个典型的示例。一些IT服务管理专家甚至更为这些新的愿景所鼓舞，急切地去掌握新的主张。2017年很多国家的ITSM年度会议上，我们看到很多演讲内容甚至是整个专场都被DevOps以及数字化转型这样的主题所占据。看起来几乎所有的专家都一致认为基于ITIL的流程可以在一定程度上可以与DevOps适配或吻合，与此同时，组织在ITIL方面的投资回报可以得到保障。然而，一切并没有那么简单。

在DevOps与ITSM之间存在根本对立的矛盾，这一观点需要被澄清。

IT服务管理（以及基于流程的活动管理）的两个关键原则之一，是由IT以服务的方式来交付业务价值。服务模式中必不可少的一环是客户与供应商之间的关系：前者决定了需要什么以及为什么需要，后者将风险、成本与成果相关联。这些关系是要求记录在服务级别协议（SLA）中的，包含各方职责。如果客户对交付的服务质量不满意，他们可以尝试去影响服务提供商并基于已签署的协议申诉，甚至是更换供应商。同样地，如果供应商发现客户制造的麻烦大于收益，他们可以终止协议并将注意力放在在其他的客户上。当然，对于客户内部的供应商而言并非这么简单，但基本原则是一样的。

与此同时，DevOps的主张在很大程度上是基于单一团队的概念，包括IT和业务在内。因此各种角色在一起工作，关注长期的成功，而不是短期的胜利，当然更不会去过多关注书面上的协议。团队中不同角色的成员携手共进，随着他们前行，道路也变得愈加清晰可见。团队对于失败早已达成一致，一旦失败他们不会相互问责，而是从自身的错误去学习。在极致情况下，IT与业务之间的边界完全消失，这与前面称为“我们与他们”的工作方式截然不同。

ITSM与DevOps的本质

对于如何解决ITSM和DevOps这一主要矛盾，答案尚未明朗，相对而言，即便是对于小的方面也会存在分歧。例如：

●  如上所述，DevOps的实践在很多方面与传统IT部门的惯常实践不同——并且很多IT主管还未准备好来接受新的理念。

●  DevOps的资金是以完全不同的方式设置的：资金是分配给产品，而不是项目。

●  长期以来，企业IT部门的原则是以成本优化为基本原则，DevOps则建议切换到以提高速度为原则。

●  ITIL®定义的变更管理关注在降低风险，通过相当缓慢并且严格的正式流程实现，包含了诸多的控制、通知、协议以及审批。然而DevOps所提倡的变更，则是在伴随自动化测试以及日志记录的情况下，越快越好。

● 由于大量通过繁重的手工操作来收集和更新配置信息，ITIL®中所描述的配置管理以及配置管理数据库实践中很难实现。与此同时，DevOps中的配置管理在很大程度上是自动化的并且是强制的，以至于配置这一术语在DevOps实践中拥有了一个新的含义。

●  与ITIL相比，在DevOps实践中“发布”的概念发生了变化，从“发布是一个复杂的、有准备的、测试过的、实时执行的变更”到“新功能对客户可用”。

●  事件管理实践，包括支持业务线的分离以及问题的升级，被DevOps中的另一个原则所取代：谁构建的，谁来运行（You build it, you run it）。

●  问题管理（处理事故根因）在DevOps实践中显得毫无意义：在ITSM中问题管理极具挑战性，而在DevOps实践中却并非必要。

●  ITIL®中的容量管理是基于容量计划的极大延伸，应该涵盖对IT资源的所有需求，并且通常与公司每年的预算周期绑定。在DevOps实践中，容量必须在需要的那一刻就绪，不能由于寻找供应商、签订合同、等待交付等事宜而被延误。

事实证明，无论从哪一方面来讲，ITIL®的主张都与DevOps的实践有所不同。也许这些矛盾并非不可调和，在一些场景中只需对现有ITSM流程进行些许调整即可。然而，在另外一些场景下，则需要对ITIL®流程进行大刀阔斧的改革。

——以上内容节选自《DevOps精要：业务视角》5.4章节，ITIL®是Axelos公司注册商标。