停止争论：ITIL v4、SRE和DevOps助力数字化转型
许峰 译 DevOps咖啡馆
By Eveline Oehrlich, DevOps Institute
With Stephen Thorne, Google; Jayne Groll, DevOps Institute; Barclay Rae, Barclay Rae Consulting
译者序：本文为发表在DevOps Institute上的一篇文章。阐述了ITIL v4、SRE和DevOps的概念，相似性、差异已经组织应如何采用。对于差异部分，下期会引用另一篇文章重点说明DevOps和ITIL之间的“不兼容”部分。
随着最近ITIL 4的推出以及站点可靠性工程（SRE）的日益普及，关于这些最佳实践的差异和相似性的争论再次浮出水面。
这些框架或最佳做法中的每一个都可以在整个IT价值链中增加价值。但是，面对数字世界中的服务管理，哪一个是正确的？我认为这不是要问的正确问题。IT主管应该停止争论每个方法的优点。相反，他们应该集中精力于如何最好地发展高绩效团队，从而既可以实现又可以加快公司的数字化战略。
这三种方法均具有一些共同的目标，包括：
- 引入协作和联系的文化
- 更加注重为利益相关者快速、优质地创造价值
- 依靠自动化来减少由人造成的浪费和错误的能力
这些框架或最佳实践中的每一个在增加整个IT价值链的价值方面都有其地位。在我们2019 survey on Upskilling DevOps调查中，我们了解到66％的人正在使用DevOps，47％的人将ITIL用作最佳实践框架，以及10％的受访者正在使用（SRE）实践。另外，必须注意的是，我们调查的许多团队同时使用了这三种实践。
为了提供更好的指引，这里列出一些你需要知道的重要的事项。对ITIL 4，SRE和DevOps的高层级概述
让我们对涉及的每个框架分别阐述。
ITIL 4是Axelos服务管理框架的最新发展。
它引入了一个新的服务价值体系（Serive Value System)，该体系由最初开发的指导原则支持，现在随 ITIL Practitioner Guidance出版而进一步发展。该框架使得其与DevOps和敏捷保持了一致性，这种方法保留了以前ITIL版本中的许多活动，但也认可DevOps的实践，如价值流和持续交付。
IT组织的所有成员都参与其中，他们一起工作，通过IT所支持的服务促进价值创造。ITIL 4框架的关键组件围绕着服务价值链（service value chain），旨在通过指导原则、治理、实践和持续改进，根据需求或机会交付价值。
利益相关者（客户）通过需求或机会获得IT所支持的服务或产品。例如，“销售人员花更多的时间与客户互动”（利益相关者和机会），这得益于“一种远程访问服务，使销售人员的笔记本电脑能够可靠地访问公司销售系统”（IT支持的有价值的服务）。重点关注服务功能和可用性、性能、安全性和可维护性等非功能性需求。站点可靠性工程（SRE） 是Google的服务管理方法，在同名书中有介绍 。
它是用于在生产环境中大规模操作大型系统实践集，其工程重点是运维。关键角色是SRE团队，这是组织内部定义的工作角色。这些团队成员是旨在执行运维功能的软件工程师，而不是专门的运维团队。
生产系统及其用户的可靠性由工程师提供支持，该工程师采用SRE站点原则来管理可用性、延迟、性能、效率、变更管理、监视、紧急响应和容量规划。
他们还可以充当支持工程师，利用监控、容量和优化自动化工具。他们的重点是可用性、性能、安全性和可维护性的非功能性需求。DevOps是由多学科的开发和运维团队组成的，以取代竖井式的开发和运维团队。这些团队与共享的、高效的实践和工具一起工作。
DevOps团队的关键成员是来自开发、运维和安全团队的成员，他们在软件生命周期中协同工作，以提高软件开发和交付的质量和速度，从而提高客户体验；重点关注功能（应用程序特性等）的速度和质量，以及可用性、性能、安全性和可维护性等非功能需求。
ITIL 4，SRE和DevOps的目的是什么？
ITIL 4强调服务质量和一致性，旨在通过从利益相关者的角度确保价值来提高利益相关者的满意度。它的指导原则是支持组织为其利益相关者的需求增加价值，而不管这些利益相关者是内部还是外部客户。它由服务生命周期中的34种实践组成。有关更多详细信息，请参见此处：https : //www.axelos.com/welcome-to-itil-4
SRE强调系统和软件的开发，以提高应用程序和服务的可靠性和性能。SRE还具有随叫随到的责任，这意味着它们需要随时可用以提供服务或支持。有关更多详细信息，请参见此处：https : //landing.google.com/sre/
DevOps在软件的开发和交付中集成了各种团队和流程。DevOps的目的是提高质量，同时为业务线管理足够的速度的软件和服务。该方法符合精益原则和敏捷。有关更多详细信息，请参见此处：http : //www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ITIL 4，SRE和DevOps有哪些相似之处？
所有这三个方法都涉及变更管理的关键主题。ITIL 4聚焦在变更管理治理，而SRE使用“出错预算”（error budget）1的概念，该概念允许SRE团队进行变更，直到出错预算“耗尽” 。DevOps团队则以渐进的方式不断地管理变更。
1 译注：业务或产品必须建立系统的可用性目标。一旦目标建立，用1减去该可用性目标就是我们所说的出错预算。
所有这三种方法都鼓励IT部门不同利益相关者之间以及与业务和/或产品所有者之间的协作。而且，所有方法都由大量自动化工具支持。一些工具声称专注于DevOps，另一些工具则使关键流程自动化。由于新进入者，技术（AI等）以及并购，自动化工具的格局非常复杂且不断变化。集成是可能的，但也具有挑战性。
每种方法还着重于持续学习和实验。这些方法的技能可能有所不同，但实际上你需要结合自动化和流程技能、软技能、功能技能（functional skills）以及业务和技术技能 2。
2 译注：这些技能说明在2019 survey on Upskilling DevOps可以找到对应的说明和调查结果ITIL 4，SRE和DevOps之间有什么区别？
这些方法之间的主要区别在于团队拓扑结构（team topology），度量标准和自动化工具，以及其基本理念和对治理模型的遵循。ITIL 4不需要团队成员组成一个团队。它还具有许多可以应用的子过程，并且在基础级别、管理专业人士级别、战略领导者级别和Master级别有各种认证。ITIL 4中的关键指标是服务水平目标的实现。该框架为中型和大型组织的IT和企业服务管理流程的优化和改进提供了坚实的治理。
SRE具有确定的角色和明确的头衔。正如其头衔所指明的那样，关键责任包括应用程序和服务的可靠性，重点放在服务级别目标和服务级别指标上。Google和其他公司可以提供学习和理解SRE的课程。DevOps研究所还将提供SRE Foundation认证。
DevOps团队的拓扑结构各不相同，但是最有效的DevOps团队是一个具有相同目标和指标的团队。DevOps的关键指标包括部署频率和恢复时间。DevOps认证包含基础级别和其他各个级别 3。治理模型主要通过自组织完成。
3 译注：EXIN DevOps认证系列包含了DevOps Foundation、DevOps Professional和DevOps Master三个级别什么时候应该使用ITIL 4，SRE和DevOps？
任何时候都可以采用ITIL 4。不需要以前的ITIL版本。一个关键的触发点是在设计、开发和构建阶段创建产品和服务的整体方法。ITIL 4引入并管理通用的最佳实践和语言，以提高客户满意度、服务可用性和财务效率。ITIL 4还涉及组织和人员、信息和技术、合作伙伴和供应商以及价值流和流程。
可以通过在DevOps团队或服务管理团队中引入SRE工程师作为正式团队成员来采用SRE。不采用ITIL 4或DevOps的组织也可以采用SRE。SRE成员也是新系统设计中的涉众，因为在设计新系统时会充分利用他们对当前服务、产品和/或环境的了解。采用SRE的关键是当可靠性是组织的既定目标，并且系统的用户、复杂性和/或配置项的数量正在增长时。SRE团队的一个主要好处是创建了自服务工具和自动化脚本，以解决应用程序和服务的可靠性和性能问题，从而消除了手工工作。
DevOps的采用可以随时进行。关键的触发点是对交付给利益相关者的软件、产品和/或服务的速度和质量提高的要求。一个主要好处是，它带来了文化变革，提高了软件开发和交付方式的速度和质量。它建立在敏捷软件开发和服务管理技术的基础之上，并鼓励使用自动化来减少熟练技能人员的手工工作，从而专注于更多的增值任务和活动。DevOps要求所有团队成员都重视软件的可靠性、可维护性和可运维性。分析：
软件产品的开发和管理需要敏捷技术，重点是通过减少浪费的方式共同创造价值。这三种方法可以共存，以使团队保持一致，满足利益相关者的需求，并改进交付的价值。
无论您选择哪种方法（或其组合），只要专注于：
1）一个共同的愿景和目标，
2）注入和管理关怀文化（a culture of care）
3）制定决策并使决策可见
4）在开始之前定义指标和度量，持续向利益相关者证明你所做努力的价值，因为数字化转型的价值不是在整个组织中可以立即实现的。资深的公司应从适合自己需求的最佳实践和方法入手，从小做起，然后学习、积累专业知识并扩大规模。