学习资料：IT运维管理社区专家讲堂直播300期视频回放

深度解析ITIL4与DevOps的异同，解惑使用和融合中的关键疑问

[color=rgba(0,0,0,0.9)]写在前面

回答这个问题前，我们首先要明确为什么要问这个问题？大家普遍关注是：

• 在组织内该如何管理好运维与开发，哪个实践更好用？
• 研发部门已经实施了DevOps，运维部门想使用ITIL4，在落地中ITIL4和DevOps该如何取舍与融合？
• 我们从实际解决问题的视角来看，ITIL4和DevOps能解决哪些问题？
• 如何落地ITIL4和DevOps，他们能融合吗？
  

在讨论如何落地之前我们还是要对两个实践的内容和边界进行区分，理解清楚概念才能考虑如何落地的问题。 一个管理方法或实践最终是要落实到执行的人或组织上的。因此，我们从IT部门组织协同的视角去看ITIL4和DevOps的设计初衷：

• 管理范围不同：ITIL4定位于“整个IT组织”，DevOps定位于“开发部门”
• 交付价值侧重不同：ITIL4侧重于全员通过规范流程提升价值交付效率，而DevOps强调通过文化、技术来提升价值交付效率；
• 目的相同：提升价值交付效率；
• 解决同样问题：拆掉“部门墙”
  

有了这个全局视角后，我们再来看两个体系的详细内容：ITIL4是什么？

本质：ITIL4的核心是以IT部门为管理对象，以“精益”的底层逻辑，以SVS为管理框架，通过34个管理实践，以帮助IT部门交付价值。

2019年ITIL4推出，ITIL4对过往的框架进行了重大变革，融合了各类最新的管理方法、思想和工具。其中包括近年来一直被认为挑战其江湖地位的DevOps。

在当今的IT服务管理领域中，两者存在着一定的交集，有些体现在理念、思维和指导原则层面，有些体现在产品和工具层面。ITIL4通过服务价值系统（SVS）和服务价值链（SVC）将DevOps融入ITIL框架中以解决这两种模式的冲突，为新技术背景下IT服务管理提供新的指导。ITIL4迎合了新的“IT+业务”生态链模式，通过SVC灵活整合不同实践，实现服务快速交付，从而完成从需求到价值的输出。

简单来说，ITIL将工作重心从流程管理转移到价值交付。同时在维持原有的五大基础流程（配置、变更、发布、事件、问题）不变的前提下，将DevOps纳入到流程内。即在流程内部构成快速迭代的微循环，而整体上保持运维流程的稳定性。

DevOps是什么？

• 本质：DevOps是以开发部门为管理对象，以“精益”的底层逻辑，以敏捷开发、持续集成、持续交付、持续测试、敏捷流程为管理框架，通过文化、衡量、流程和技术为管理抓手，以帮助IT部门交付价值。
  
  
  

DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合，是通过平台（Platform）、流程（Process）和人（People）的有机整合，以C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化IT组织。

ITIL4和DevOps关键内容对比
1.活动对比 DevOps将价值交付的活动分为两个部分共8个活动：规划、开发、构建、测试、发布、部署、运维和监控，且整个过程是持续迭代改进的；

ITIL4将价值交付过程分为六个活动：互动、计划、设计与转换、获取/构建、交付和支持、改进，但根据交付产品和服务的差异，ITIL4可以通过价值流的概念分拆或裁剪掉一些活动。因此，实际执行中的活动可能多于6个或少于6个。这与DevOps受限于“开发”这个业务领域一般都必须经过8个活动不同。

总结：ITIL4和DevOps的向用户交付价值的目标相同；但管理的过程和重点有差异。DevOps更加聚焦于开发过程。

2.实施模型对比：
总结：将DevOps的实施内容按照ITIL4的四维模型进行整理，发现其大致相同，只是DevOps没有单独的改进模型。“衡量”使其关键考虑的问题，也体现了其迭代的思维。而ITIL4倡导的是全局思维，将合作伙伴和供应商作为思考的重要纬度。
3.指导原则对比

总结：

关于交付价值这一点是两个实践共同倡导的；相较于与DevOps而言，ITIL4的原则更加全局，也就是说ITIL4的原则适用于DevOps。

DevOps有三步工作法，每一个方法均有多个指导原则，而ITIL4则有七项指导原则。ITIL4鼓励跨组织的协作和沟通，并为快速实现变更提供了更多的指导。过去ITIL强调规范、流程，而DevOps强调敏捷；而今天，从ITIL4七项指导原则来看，其已充分吸收DevOps“流动，反馈，持续学习和实验”的三步工作法的指导思想，使之为己所用。

其他不同点：

1.在各自体系中将对方所置的地位不同：

在ITIL4中，DevOps被当作在服务设计和转换以及获取/构建阶段的执行者。

而在DevOps知识体系中，ITIL被一定程度地矮化，仅在运营与周期终止阶段作为一个轻量级的ITSM（EOL）引入，重点保证IT架构和系统的连续性。

2.发展理念不同：

ITIL4中虽然扩展了关于价值、价值流、价值共创等理念，但是实际在做“减法”，部分实践的方法指导相对旧版要显得抽象一些，这样为组织能更好、更简单、更灵活地应用ITIL以及适配未来层出不穷的新技术、新思维、新方法预留了弹性空间，也为广大ITIL爱好者们指明了更合适的演进路径。

而DevOps尤其是在2.0版本中，开始做“加法”。其已经不再满足只是一条单纯的持续交付工具链或者一项敏捷的工作方法，它开始引入LeanIT、敏捷等实践方法，试图定义整个ITSM生态，并成为一种特有的文化。

DevOps和ITIL4是否可以融合呢？

答案是可以的。

• 从ITIL4的视角看，因为DevOps方法基于敏捷软件开发和持续交付的自动化技术，强调软件开发和技术操作之间的紧密协作，因此可利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，让DevOps能够提升软件产品的可操作性、可靠性和可维护性等。而DevOps从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动，以便产品和服务团队保持相同的目标并使用相同的方法。
• 
• DevOps被认为是结合了软件开发技术（敏捷）、价值共创（ITIL4），以及对学习和改进价值生产方式（精益）执着追求的整体方法。在ITIL4中，组织面临的主要挑战之一是确定其特定的价值流。DevOps是一个很好的ITIL4价值流实例，其涵盖了从业务需求、开发、测试、发布计划到部署的活动。因此，采用或借用DevOps方法将为改进软件产品的开发和管理方式提供更多机会，例如：
  
  
  
  • 创建从交付和支持到软件开发和技术操作的快速反馈循环；
    
    
  • 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
    
    
  • 分离部署管理与发布管理；
    
    
  • 倡导“整体系统视图”，强调企业治理，促进服务团队、软件开发和技术运维之间的紧密协作。
    
    
  
  
  DevOps将在ITIL4服务目录管理、服务级别管理、变更管理、配置管理、发布管理、部署管理等实践中大展拳脚。
  • 从DevOps视角看，ITIL与DevOps的有诸多融合场景，帮助DevOps来运行的更好：
    
    
    
  • DevOps与事件管理融合
    
  ITSM有着详尽的事件管理功能，在敏捷开发中融入事件管理的实践原则如下。
  原则1：事件解决不应该影响团队的Sprint目标。
  原则2：每个Sprint都应该为可能出现的事件处理预留时间。
  原则3：预留时间，建议为20%，最好依据具体的项目历史数据。
  原则4：设定事件优先度，优先度最高的需要立即解决。
  原则5：低优先度的事件按照预留处理时间剩余情况顺序解决。
  原则6：超出预留时间的情况需要批准才能进行处理。
  原则7：事件处理队列状况确认可视化。
  原则8：在满足上述原则的基础上，事件处理本着今日事今日毕的原则。
  • DevOps与问题管理融合
    
  原则1：问题管理的任务作为用户故事在产品待办清单中进行管理。
  原则2：问题的管理需要考虑到问题重新分配的情况及可视化状态的确认。
  原则3：尽量最小化技术债务，尽量做到在2个迭代周期内解决问题。
  • DevOps与配置管理融合
    
  原则1：虽然手工配置很多时候还是无法避免，但还是尽量推动配置自动化。
  原则2：引入基础设施即代码的观点管理配置。
  原则3：配置管理纳入版本管理中。
• 写在最后
  ITIL4和DevOps是对IT部门进行不同视角的价值交付过程的管理。二者相辅相成，可以互相借鉴引用最终形成适合组织自身的管理模式，企业也就不存在那种实践更好的问题。另一方面，ITIL4适应性更广，很多组织是没有自己的开发团队的，其产品和服务都是通过“获取”活动来创建的，因此，这种类型的组织就不适合DevOps，如，一些政府组织、医院等。
  
  

学习资料：IT运维管理社区专家讲堂直播300期视频回放

深度解析ITIL4与DevOps的异同，解惑使用和融合中的关键疑问

[color=rgba(0,0,0,0.9)]写在前面

回答这个问题前，我们首先要明确为什么要问这个问题？大家普遍关注是：

• 在组织内该如何管理好运维与开发，哪个实践更好用？
• 研发部门已经实施了DevOps，运维部门想使用ITIL4，在落地中ITIL4和DevOps该如何取舍与融合？
• 我们从实际解决问题的视角来看，ITIL4和DevOps能解决哪些问题？
• 如何落地ITIL4和DevOps，他们能融合吗？
  

在讨论如何落地之前我们还是要对两个实践的内容和边界进行区分，理解清楚概念才能考虑如何落地的问题。 一个管理方法或实践最终是要落实到执行的人或组织上的。因此，我们从IT部门组织协同的视角去看ITIL4和DevOps的设计初衷：

• 管理范围不同：ITIL4定位于“整个IT组织”，DevOps定位于“开发部门”
• 交付价值侧重不同：ITIL4侧重于全员通过规范流程提升价值交付效率，而DevOps强调通过文化、技术来提升价值交付效率；
• 目的相同：提升价值交付效率；
• 解决同样问题：拆掉“部门墙”
  

有了这个全局视角后，我们再来看两个体系的详细内容：ITIL4是什么？

本质：ITIL4的核心是以IT部门为管理对象，以“精益”的底层逻辑，以SVS为管理框架，通过34个管理实践，以帮助IT部门交付价值。

2019年ITIL4推出，ITIL4对过往的框架进行了重大变革，融合了各类最新的管理方法、思想和工具。其中包括近年来一直被认为挑战其江湖地位的DevOps。

在当今的IT服务管理领域中，两者存在着一定的交集，有些体现在理念、思维和指导原则层面，有些体现在产品和工具层面。ITIL4通过服务价值系统（SVS）和服务价值链（SVC）将DevOps融入ITIL框架中以解决这两种模式的冲突，为新技术背景下IT服务管理提供新的指导。ITIL4迎合了新的“IT+业务”生态链模式，通过SVC灵活整合不同实践，实现服务快速交付，从而完成从需求到价值的输出。

简单来说，ITIL将工作重心从流程管理转移到价值交付。同时在维持原有的五大基础流程（配置、变更、发布、事件、问题）不变的前提下，将DevOps纳入到流程内。即在流程内部构成快速迭代的微循环，而整体上保持运维流程的稳定性。

DevOps是什么？

• 本质：DevOps是以开发部门为管理对象，以“精益”的底层逻辑，以敏捷开发、持续集成、持续交付、持续测试、敏捷流程为管理框架，通过文化、衡量、流程和技术为管理抓手，以帮助IT部门交付价值。
  
  
  

DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合，是通过平台（Platform）、流程（Process）和人（People）的有机整合，以C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化IT组织。

ITIL4和DevOps关键内容对比
1.活动对比 DevOps将价值交付的活动分为两个部分共8个活动：规划、开发、构建、测试、发布、部署、运维和监控，且整个过程是持续迭代改进的；

ITIL4将价值交付过程分为六个活动：互动、计划、设计与转换、获取/构建、交付和支持、改进，但根据交付产品和服务的差异，ITIL4可以通过价值流的概念分拆或裁剪掉一些活动。因此，实际执行中的活动可能多于6个或少于6个。这与DevOps受限于“开发”这个业务领域一般都必须经过8个活动不同。

总结：ITIL4和DevOps的向用户交付价值的目标相同；但管理的过程和重点有差异。DevOps更加聚焦于开发过程。

2.实施模型对比：
总结：将DevOps的实施内容按照ITIL4的四维模型进行整理，发现其大致相同，只是DevOps没有单独的改进模型。“衡量”使其关键考虑的问题，也体现了其迭代的思维。而ITIL4倡导的是全局思维，将合作伙伴和供应商作为思考的重要纬度。
3.指导原则对比

总结：

关于交付价值这一点是两个实践共同倡导的；相较于与DevOps而言，ITIL4的原则更加全局，也就是说ITIL4的原则适用于DevOps。

DevOps有三步工作法，每一个方法均有多个指导原则，而ITIL4则有七项指导原则。ITIL4鼓励跨组织的协作和沟通，并为快速实现变更提供了更多的指导。过去ITIL强调规范、流程，而DevOps强调敏捷；而今天，从ITIL4七项指导原则来看，其已充分吸收DevOps“流动，反馈，持续学习和实验”的三步工作法的指导思想，使之为己所用。

其他不同点：

1.在各自体系中将对方所置的地位不同：

在ITIL4中，DevOps被当作在服务设计和转换以及获取/构建阶段的执行者。

而在DevOps知识体系中，ITIL被一定程度地矮化，仅在运营与周期终止阶段作为一个轻量级的ITSM（EOL）引入，重点保证IT架构和系统的连续性。

2.发展理念不同：

ITIL4中虽然扩展了关于价值、价值流、价值共创等理念，但是实际在做“减法”，部分实践的方法指导相对旧版要显得抽象一些，这样为组织能更好、更简单、更灵活地应用ITIL以及适配未来层出不穷的新技术、新思维、新方法预留了弹性空间，也为广大ITIL爱好者们指明了更合适的演进路径。

而DevOps尤其是在2.0版本中，开始做“加法”。其已经不再满足只是一条单纯的持续交付工具链或者一项敏捷的工作方法，它开始引入LeanIT、敏捷等实践方法，试图定义整个ITSM生态，并成为一种特有的文化。

DevOps和ITIL4是否可以融合呢？

答案是可以的。

• 从ITIL4的视角看，因为DevOps方法基于敏捷软件开发和持续交付的自动化技术，强调软件开发和技术操作之间的紧密协作，因此可利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，让DevOps能够提升软件产品的可操作性、可靠性和可维护性等。而DevOps从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动，以便产品和服务团队保持相同的目标并使用相同的方法。
• 
• DevOps被认为是结合了软件开发技术（敏捷）、价值共创（ITIL4），以及对学习和改进价值生产方式（精益）执着追求的整体方法。在ITIL4中，组织面临的主要挑战之一是确定其特定的价值流。DevOps是一个很好的ITIL4价值流实例，其涵盖了从业务需求、开发、测试、发布计划到部署的活动。因此，采用或借用DevOps方法将为改进软件产品的开发和管理方式提供更多机会，例如：
  
  
  
  • 创建从交付和支持到软件开发和技术操作的快速反馈循环；
    
    
  • 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
    
    
  • 分离部署管理与发布管理；
    
    
  • 倡导“整体系统视图”，强调企业治理，促进服务团队、软件开发和技术运维之间的紧密协作。
    
    
  
  
  DevOps将在ITIL4服务目录管理、服务级别管理、变更管理、配置管理、发布管理、部署管理等实践中大展拳脚。
  • 从DevOps视角看，ITIL与DevOps的有诸多融合场景，帮助DevOps来运行的更好：
    
    
    
  • DevOps与事件管理融合
    
  ITSM有着详尽的事件管理功能，在敏捷开发中融入事件管理的实践原则如下。
  原则1：事件解决不应该影响团队的Sprint目标。
  原则2：每个Sprint都应该为可能出现的事件处理预留时间。
  原则3：预留时间，建议为20%，最好依据具体的项目历史数据。
  原则4：设定事件优先度，优先度最高的需要立即解决。
  原则5：低优先度的事件按照预留处理时间剩余情况顺序解决。
  原则6：超出预留时间的情况需要批准才能进行处理。
  原则7：事件处理队列状况确认可视化。
  原则8：在满足上述原则的基础上，事件处理本着今日事今日毕的原则。
  • DevOps与问题管理融合
    
  原则1：问题管理的任务作为用户故事在产品待办清单中进行管理。
  原则2：问题的管理需要考虑到问题重新分配的情况及可视化状态的确认。
  原则3：尽量最小化技术债务，尽量做到在2个迭代周期内解决问题。
  • DevOps与配置管理融合
    
  原则1：虽然手工配置很多时候还是无法避免，但还是尽量推动配置自动化。
  原则2：引入基础设施即代码的观点管理配置。
  原则3：配置管理纳入版本管理中。
• 写在最后
  ITIL4和DevOps是对IT部门进行不同视角的价值交付过程的管理。二者相辅相成，可以互相借鉴引用最终形成适合组织自身的管理模式，企业也就不存在那种实践更好的问题。另一方面，ITIL4适应性更广，很多组织是没有自己的开发团队的，其产品和服务都是通过“获取”活动来创建的，因此，这种类型的组织就不适合DevOps，如，一些政府组织、医院等。