ITIL与DevOps的比较：不同的观点

关于ITIL与DevOps的讨论是很常见的。对此问题存在很多不同的看法：有些人认为ITIL和DevOps有不同的思维方式；也有人认为ITIL和DevOps是兼容的；还有人认为他它们是不同的，但是在IT部门都有自己的位置。在最近的一篇文章中，Charles Betz，Open Group IT4IT论坛的敏捷工作流（Agile Workstream，该组织致力于提供“与供应商无关的参考架构，来管理IT业务”）的负责人，认为它们的原则是不一致的。ITIL仍然陷于一种阶段性的流程。而DevOps拥抱精益产品管理原则，比如管理进行中的工作，管理队列，或者进行小批量处理。

Betz和Jeff Sussna，同为ITIL的怀疑者，同意ITIL通过“促进以服务为中心、从外到内、以客户为中心的思想”，对IT社区做出了重大的贡献。但是他们认为，尽管ITIL V3关于“持续改进服务”的讨论，致力于不断调整IT过程，保持与业务需求一致，但是仍然是分阶段步骤的思维方式。正如Betz所说的：

对于每次提到“迭代”或“反馈”，就有十次提到“计划”或者“制定计划”。值得注意的是，单词“实验”只在服务战略中出现过几次，而在其它卷中就压根儿没有出现。

根据Sussna所述，ITIL V3：

V3把持续改进服务放在由服务战略、设计、转变和运营组成的一系列阶段的末尾。见到这样一个看起来象瀑布流的方法，我真的有点儿震惊。

在Betz看来，ITIL把IT流水线描述为“在战略、开发和运营之间转换的精确计划的大批量工作”。Betz认为ITIL基本上相信过程是解决问题的主要机制，通过计划和文档可以缓解风险。Betz认为一些这样的基本观点源自于ITIL的大部分要追溯到10年前这样的事实，因此，是过时的：

ITIL要求把经过改进的IT交付基本模型作为一个集中关注执行、反馈和流程的社会技术系统。

另一方面，Gene Kim说ITIL／ITSM是非常兼容于DevOps的：

ITIL和ITSM仍然是支撑IT运营的业务流程的最佳汇编，并且实际上描述了许多需要为了让IT运营支持DevOps式工作流的能力。

以及：

不过，更重要的是，ITSM从业者都拥有独特的优势，帮助DevOps的举措，并为企业创造价值。

Kim举了一些ITIL／ITSM从业者增加价值的例子。在一个基础设施自动化项目中，ITSM从业者可以将现有的“发布管理准备清单、安全加固清单、等等”集成到自动构建过程中。标准变更，是ITIL术语，描述频繁、记录在案的、低风险、预先批准的变更。 ITSM从业者可以帮助把标准变更嵌入到生产环境的自动部署中。

Rob England不同于Betz、Sussna和Kim双方。England认为，ITIL和DevOps是不一致的，但两者可能在同一个IT组织内都有它们的位置。他从Gartner的bi-modal和pace layer模型获得灵感，主张多种速度的IT（multi-speed IT）：

• 保守的：传统的，也许是瀑布流，变更管理和运营
• 敏捷：DevOps的一些变体

根据England所述，企业应当决定采用哪种方法。一些业务需求及配套的应用程序，需要强调创新和变更速度：它们需要敏捷的方法。其它业务需求要求稳定和极低的风险：它们需要保守的方法。

查看英文原文：ITIL vs. DevOps: Different Viewpoints

感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。