ITIL4、DevOps和SRE在IT运维中该如何选择
学习资料：IT运维管理社区专家讲堂直播300期视频回放
ITIL4、DevOps和SRE在IT运维中该如何选择
在IT运维领域，ITIL4、DevOps和SRE都被大家所熟知，但也随之带来的是在进行IT运维管理体系建设时该如何选择，该选择哪一个体系作为IT运维的理论参考。今天我们就从真正落地的视角来聊聊这三个体系的差别。先说结论：简单来说，ITIL4是IT整体管理体系、DevOps是开发管理体系、SRE是系统运维岗位职责及其工作方法体系。为什么这么说呢？我们从以下几个方面讨论：
从“定位”纬度来说
ITIL4，是在数字化转型的大趋势背景下于2020年首次发布，ITIL4完全不同于以往的ITIL版本，是着眼于整个IT部门的管理。ITIL4定位于：以IT部门的业务价值链为视角提出的针对IT部门的整体管理体系建设的知识框架。根据价值链的理论大多数IT部门的价值链可以抽象为如下的模型：从上图可以看出，业务系统研发只是ITIL4的管理体系中的一部分，但IT部门的业务不只有开发业务，其他的诸如IT战略、IT组织、IT人力资源、IT财务等都是做IT部门管理不可缺少的关键活动。DevOps的定位是：聚焦于业务系统的研发，目的通过加强研发、测试、运维和质量部门的协调，高质量的向用户交付可用的产品。围绕这一目的当然要关注人、组织、文化、工具等方面的建设，这些都是管理，ITIL和DevOps在这方面是重叠的但不是冲突的。SER的定位：从SER（SiteReliabilityEngineering/Engineer），站点可靠性工程师，它特指的是一个围绕业务系统运维的岗位。因此，他的所有的内容都是围绕这个岗位的目的、职责、工具和使用的方法来描述的。SER关注的是站点（业务系统）的可靠性（稳定性），确保系统能始终提供其约定的能力。在实际的落地过程中，可以以ITIL4作为IT管理体系建设的参考框架，以流程管理理论为指引，建立整个IT部门的管理体系。在IT管理体系确定的情况下，如果IT部门有开发部门，则可以以DevOps为基础建立开发体系。同时将SRE视为一个业务运维开发工程师角色，将其职责、工作方法和相关工具作为系统稳定性、可靠性的保障。
从定义来说
ITIL4是：适用于数字化时代服务管理的框架。通过其最佳实践模块，ITIL4帮助优化数字技术，与消费者共同创造价值，推动业务战略，并拥抱数字转型。DevOps：（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。SRE：(SiteReliabilityEngineering/Engineer),站点可靠性工程/工程师,起源于2003年。最早是由Google设置的一类工程师岗位，专职负责其超大规模分布式产品（如搜索、Gmail、Docs等）的稳定性。而后，SRE慢慢发展成了一系列面向稳定性的，包括技术、管理、流程、组织架构，以及文化建设的最佳实践，并最终被提炼成一套方法论，广泛流传。在系统管理员模式下，通常是通过人工操作完成任务，而SRE倾向通过设计、构建自动化工具来取代人工操作。SRE的本质是用软件工程的思维和方法解决复杂的运维问题。SRE的出发点是“保障和提升系统稳定性”，两者要做的事情其实本质上差别不大，但是角度不同。可以认为DevOps是SRE核心理念的普适版本，SRE是DevOps模型在Google的具体实践
从实际应用场景来说
ITIL4应用于整个IT组织，尝试管理IT组织各方面的整体业务，从IT战略制定直至对用户的交付支持，属于IT部门的全面管理体系，同时提出IT组织与用户的价值创造，即把部分用户也纳入管理的体系。DevOps侧重于业务系统开发这条业务价值流，核心涵盖的业务任务是需求、设计、开发、测试、发布、部署和运维，管理的岗位和角色基本是开发和部分运维的角色。SER侧重于一个业务系统软件运维工程师，这个工程师是有运维思路、用户服务思路的研发工程师，核心是确保业务系统的可靠和稳定，其通过识别各个影响业务系统组件达到对业务系统的可观测性，来达到业务系统可靠和稳定的目标。
从工具的完善度来说
ITIL4作为一个整体管理体系框架来说，其核心解决的是通过不断的价值交付来确保IT组织的战略如何实现。其更加偏向于流程制度的管理，本质是流程管理的管理理念。对于IT部门来说定义的是1、2级流程。由于其管理范围比较大，因此，其支持其工具的往往类似与流程、资源和规范的管理，即ITSM，但围绕着流程如何能高效运转，任务能高质量完成而涉及到的工具都应该属于ITIL4的范围。DevOps在ITIL4整体管理框架之下聚焦于开发的工作领域，但其管理的目标又是高质量的持续发布，因此，其管理的范围识别在开发领域上游产品设计和下游运维方面来延展，以达到其高质量、持续发布的目标。由于更加聚焦，所以围绕着如何确保高质量、持续发布的工具就非常多，如下图：SRE从其定义来看，可以认为最早是属于运维方面的岗位，更加偏向于操作，更加的聚焦，已经不是一个业务，而是一个岗位上的定义。其核心工具目标是确保站点/已发布应用的稳定和可靠。为了达成这一目标，其必须要上游的开发扩展，关注在业务系统研发阶段如何保障稳定性和可靠性，同时也必须向下游的运维扩展关注一旦出现故障如何快速识别、并快速恢复，因此，在自动化和可观测性方面都特别的深入分析。由于SRE的工作更加聚焦，管理的对象也非常明确，所以，围绕SRE的工具也是非常丰富，大多针网络、服务器/操作系统、基础应用（中间件、数据库）、业务应用（各业务系统）等不同的技术岗位，聚焦在智能监控和自动化操作工具上。当然现在一体化的工具和AIOps的相关工具也在发展，核心是提升影响业务系统稳定性和可靠性组件的可观测性以及自动化的处置。其他的工具与ITIL和DevOps重叠。
从行业应用来说
ITIL4属于支持IT战略的管理框架，因此其应用的范围非常广泛，涉及到IT管理、有10人以上的IT组织规模的都适用于ITIL。如下图IT战略和IT管理体系的关系，而ITIL4就是建立IT管理体系的重要参考。当然IT的战略也是从业务战略、数字化转型战略来逐步分解得来的。DevOps主要是针对有自己的开发组织，同时业务应用系统发布比较频繁的行业，如一些制造业的营销系统、电商、互联网、还有一大部分的软件开发公司等，而真多一些业务系统相对稳定、需要变化比较小的IT组织反而不太适用，如高校、政府、医疗等行业。
SRE核心针对的还是超大规模分布式产品（如搜索、Gmail、Docs等）的稳定性和可靠性，因为人工的方式去维护和处理动辄几万台服务器和上百万的应用组件基本是不可完成的，所以就SRE也应运而生。但SRE的思想及其关注点：“可观测性系统、故障响应、测试与部署、容量规划、自动化软件开发、用户支持（核心是在技术层面关注用户体验与ITIL完全不同）、Oncall、制定可交付的SLI/SLO/SLA、故障复盘”在传统的IT应用领域如高效、政府等行业也通用适用，因此，使用SRE构建的监控平台也逐步增多。
未来展望
ITIL4、DevOps和SRE的融合实践在大型互联网公司、金融证券这些IT组织规模、业务系统规模比较大以及需求响应要求比较高的组织中已经实现。但不不代表这融合是趋势，在国内是市场中还有大量的组织属于基础设施提供和稳定应用提供的组织，如高校、政府和部分传统企业。因此，ITIL4、DevOps和SRE都会独立的发展，但彼此的管理思想融合也是趋势，相互借鉴也是必然发生。针对三个体系中管理原则/方针、管理流程、管理制度重叠的部分，基于顶层设计的IT管理体系建设至关重要。只有统一的IT管理体系，各个职能的协作才能发挥最大的效力。针对不同的IT组织来说，最重要的是要理清楚管理目标，明确管理的问题，再去现在融合路径或分离建设的路径就比较清晰。
页:
[1]