停止争论: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)在开始之前定义指标和度量,持续向利益相关者证明你所做努力的价值,因为数字化转型的价值不是在整个组织中可以立即实现的。资深的公司应从适合自己需求的最佳实践和方法入手,从小做起,然后学习、积累专业知识并扩大规模。

©著作权归作者所有:来自51CTO博客作者mob604756e88498的原创作品,如需转载,请注明出处,否则将追究法律责任

更多相关文章

  1. [翻译]微服务设计模式 - 1. 单体应用模式
  2. 6种Scrum工具来提高团队的生产力
  3. 微服务落地反思以及有效落地
  4. 浅谈海量平台的质量管理
  5. 台湾精益老专家:如何运用 OKR 来量化 Sprint 的目标?
  6. 敏捷这么久,你知道如何开敏捷发布火车吗?
  7. 安全星球企业云盘:释放数据价值,推动企业数字化转型
  8. 价值
  9. “网关”的特点及存在的价值和意义

随机推荐

  1. Android百度地图(三):百度地图画运动轨迹
  2. android WebView详解
  3. 使用百度地图SDK 这是之前版本 现在的sdk
  4. 基于 Android NDK 的学习之旅----- C调用
  5. Android的ActivityNotFoundException异常
  6. Android 多线程之 AsyncTask
  7. Android(安卓)-- Vibrator
  8. android 是什么
  9. Android的常见错误及解决办法
  10. Unity 与 Android (Android Studio)的交