ITIL 与 DevOps 对比

传统企业的服务更多是站在企业视角，基于自己能够提供什么来设计，内部的 IT 服务也是基于这种逻辑。互联网模式则必须站在用户的视角，基于用户需要什么来设计产品，对外提供服务，同时为了快速响应用户需求（甚至有些时候是为了快速试错与纠错），内部的 IT 服务也必须高效敏捷。

企业对流程都会有诉求，不同企业之间流程数量的多少、流程颗粒度的粗细程度是肉眼可察的，其设计的内在逻辑更是差别巨大。流程规范的本质是增加约束，其设计初衷说得直白些是为了立规矩，业务需求千奇百怪、层出不穷，如果没有任何规则，IT 服务提供者即便疲于奔命也很难应对，服务交付质量和价值也很难衡量。对于复杂的流程和审批，其流转需要经过众多节点，设计上看似面面俱到，但也有可能无人真正履职，导致对于操作者就是一个通知，对于审批者就是点一下按钮，使得流程的作用变成了满足合规要求，最终流于形式。

对于科技团队来说，开发和运维系统出现问题在所难免，差别只在于问题的多或少、早或晚。这并不是说事件管理、问题管理等并无用处，而是说不能始终把关注的焦点放在这上面。引入众多规则、流程、约束，除了让事件落地执行越来越复杂外，没有其他助益，那不如换一个思路，怎么通过立体化的监控体系第一时间发现问题，甚至在事前预测事件可能发生从而提前干预呢？当问题出现以后，通过持续集成、自动化测试、自动化发布等手段快速处置，这些也正是 DevOps 所倡导的。DevOps 也需要流程，不过它的关注点不在流程，而是效率，它建立各项流程、运用各类工具，都是为了提升效率。

举例来说，发布变更不管对开发人员还是运维人员来说都是非常重要的动作。若按照 DevOps 理念来响应发布变更的话，则建设重心会是建立自动化发布系统。在此过程中，一方面要通过制定标准化规范，对要做的操作进行抽象，统一标准，化繁为简；另一方面则是借助工具，对要执行的各项操作进行封装，隐藏细节，简化步骤并实现可视化操作。自动化发布系统建成后，要执行与发布相关的操作，通过视窗界面点击按钮即可，肯定比手动执行命令更快、更简单，也更可靠。在这种模式下还需要流程审批吗？这要根据企业的实际情况而定，有可能还是会有流程，但会是一个特别简化的小流程，因为执行的逻辑都是在系统中固化好的，谁来执行都没有区别。大家也可以对照一下自家企业发布变更流程的流转节点设计，看看有无可优化空间。ITIL 中强调职责边界的清晰定义，变相强调了分工而弱化了协作，这种情况与 ITIL 过多强调流程、甚少关注文化也有一定关系，而对于流行的敏捷模式来说则是推崇高度自治的小团队。DevOps 从开始就强调团队的敏捷基因，比如无边界沟通、团队协作、版本快速迭代、持续优化等，这种倡导创新、协作的文化对团队的行为影响是非常大的。

在 ITIL 中，运维是 IT 服务的直接提供者，“服务”是看我能为你提供什么，“流程”是看需要我为你做什么，运维人员把开发人员当作服务对象来看待，接收到来自 OA 系统的工单流程后会快速响应和交付服务，同时也会考虑通过 SLA 等衡量运维的工作质量，但终归是被动角色。在 DevOps 中，没有纯粹的服务对象，开发、测试、运维各自承担自己的职责，甚至 IT 运维人员也会站在用户视角去思考，如何为最终用户提供有价值的服务，并为最终达成基于产品价值进行交付。

ITIL 重视最佳实践，在实施过程中很多流程确实很有指导意义，不过很多时候它变成了一个规范，甚至在选择 ITSM 产品的时候，也会自然而然地以此为标准进行产品选型。这里要顺带提一下，当流程性规范形成之后，我们要改变它真的很难。而 DevOps 倡导敏捷，提倡不断迭代，所有的流程和规范是嵌入在自动化平台中的，相对更容易解决这样的情况。

尽管有这么多差异，但两者并不是非此即彼的关系，ITIL 在流程方面仍然起着非常重要的指导作用。作为以最佳实践为核心的管理框架，ITIL 必然也非常注重实用性，其中的很多思想仍然值得学习和借鉴。只是在实践过程中，不要被 ITIL 束缚，可以根据自己的实际情况导入一些 ITIL 流程，将 ITIL 与 DevOps 结合，借助 DevOps 敏捷运维方法不断驱动 ITIL 流程优化，不断推动服务交付效率和质量的提升，提供真正面向用户的 IT 服务能力。