第四章 ITIL 4学习与实践FAQ

Q26：ITIL 4和DevOps的关系？

ITIL 4 对过往的框架进行了重大变革，融合了各类最新的管理方法、思想和工具。其中包括近年来一直被认为挑战其江湖地位的 DevOps。在当今的 IT 服务管理领域中，两者存在着一定的交集，有些体现在理念、思维和指导原则层面，有些体现在产品和工具层面。细看这对“相爱相杀”的冤家， 相互学习，相互追赶超越，真的相映成趣，别有一番风景。我们尝试分析一下个中的异同。

相同之处：

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

                                   图4-11 DevOps三步工作

1.  DevOps 的流动是为了加速从开发到运维的价值交付，而 ITIL 4 定义了价值流以及通盘思考和工作的指导原则。通过整体和系统的思考，聚焦于价值的传递和交付之上。

   • DevOps 有反馈以建立更安全系统的工作制度，而 ITIL 4 定义了基于反馈的迭代推进以及持续改进。通过找到改进点与改进机会，进行优先级排序，消除瓶颈，从而不断地提升组织的管理能力与管理效率，让有效的反馈成为驱动改善系统控制回路的最大动力。
   • DevOps 有持续学习和实验，促进高度信任，形成“无谴责”的文化，将风险承担作为日常工作的一部分；而 ITIL 4 定义了从你所处的地方开始、通盘思考和工作、协作和提升可视化程度的原则以及持续改进的方法。通过工作中掌握的技能和与现有的工具来结合实践，形成更有效的价值链。
2. 目的一致：双方都要求有可视化的价值流，需要通过可视化来管理价值的流动，最终都是追求从端到端打通为用户交付价值的链条，并且强调工作的可视化要考虑全局而不是局部，如果仅仅度量开发的完成率、度量系统的可用性，这些都只是局部的目标。两者都是更关注全局、端到端的价值流动。

相异之处：

1. 在各自体系中将对方所置的地位不同：在 ITIL 4 中，DevOps 被当作在服务设计和转换以及获取 / 构建阶段的执行者。而在 DevOps 知识体系中，ITIL 被一定程度地矮化，仅在运营与周期终止阶段作为一个轻量级的 ITSM（EOL）引入，重点保证 IT 架构和系统的连续性。

1. 发展理念不同：ITIL 4 中虽然扩展了关于价值、价值流、价值共创等理念，但是实际在做“减法”， 部分实践的方法指导相对旧版要显得抽象一些，这样为组织能更好、更简单、更灵活地应用 ITIL 以及适配未来层出不穷的新技术、新思维、新方法预留了弹性空间，也为广大 ITIL 爱好者们指明了更合适的演进路径。而 DevOps 尤其是在 2.0 版本中，开始做“加法”。其已经不再满足只是一条单纯的持续交付工具链或者一项敏捷的工作方法，它开始引入 Lean IT、敏捷等实践方法，试图定义整个ITSM 生态，并成为一种特有的文化。

那么两者是否能够进行整合或相互兼容，从而携手支持更短的交付周期，优化业务的上市时间并实现更高的部署频率呢？答案是可以的。从 ITIL 4 的视角看去，因为 DevOps 方法基于敏捷软件开发和持续交付的自动化技术，强调软件开发和技术操作之间的紧密协作，因此可利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，让 DevOps 能够提升软件产品的可操作性、可靠性和可维护性等。而DevOps 从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动， 以便产品和服务团队保持相同的目标并使用相同的方法。

DevOps 被认为是结合了软件开发技术（敏捷）、价值共创（ITIL 4），以及对学习和改进价值生产方式（精益）执着追求的整体方法。在 ITIL 4 中，组织面临的主要挑战之一是确定其特定的价值流。DevOps 是一个很好的ITIL 4 价值流实例，其涵盖了从业务需求、开发、测试、发布计划到部署的活动。因此，采用或借用 DevOps 方法将为改进软件产品的开发和管理方式提供更多机会，例如：

• 创建从交付和支持到软件开发和技术操作的快速反馈循环；
• 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
• 分离部署管理与发布管理；
• 倡导“整体系统视图”，强调企业治理，促进服务团队、软件开发和技术运维之间的紧密协作。

DevOps 将在 ITIL 4 服务目录管理、服务级别管理、变更管理、配置管理、发布管理、部署管理等实践中大展拳脚。

Q27：ITIL 4和项目管理的关系？

在 2017 年，美国项目管理协会（PMI）更新了项目管理知识体系（PMBOK）。至此 PMBOK 升级为第 6 版。在第 6 版中，变动并不是太大。知识体系更结构化和标准化；对六个知识领域进行了微调， 并给出了知识领域的剪裁指南和敏捷化指南；取消了“项目管理过程”，提出了“项目经理的角色（The Role of Project Manager）”的概念。

新版本并未改变对项目的定义，仍为“为创造独特的产品、服务或成果而进行的临时性工作”。这直接意味着服务交付是项目类型之一，其中可交付的是客户请求的实际服务。根据 PMBOK 指南区分项目的主要特征，以及服务交付如何满足这些特征，我们可以看到以下几个特点：

• 临时（temporary:）：项目是一项临时的工作，有一个开始和一个结束。服务在其服务价值链中经历了从收到的需求 / 机会开始，到向客户交付价值的连续阶段，而持续改进、治理、实践、指导原则围绕着所有活动。
• 独特的产品、服务或成果（unique product，service，or result）：一个项目的交付物被认为是独特的，不像在运营活动中的重复性活动，这是通过响应特定需求交付给特定客户的 IT 服务来满足的。
• 渐进明细（progressive elaboration）：项目执行是迭代的，并且不断地循序渐进以响应变更，这可以通过 ITIL 4 框架中的持续改进以及基于反馈的迭代推进，以及相关实践来满足。

在过往，我们可以将 ITIL v3/2011 的生命周期与 PMBOK 的五大过程组粗略地做一个映射。服务战略对应启动过程与规划过程；服务设计、服务转换、服务运营对应执行过程，持续服务改进对应监控过程，服务退役对应收尾过程——ITIL v3/2011 并没有这个阶段，我们选择了最接近“关闭”的术语。

但在 ITIL 4 的时代，将 IT 服务交付视为项目表明项目管理的概念和原则与 IT 服务管理的概念

和原则之间存在必要的相似性或对应关系，我们舍易取难，根据 PMBOK 第 6 版的 5 大过程组和 49 个过程，与 ITIL 4 框架下的 34 个实践进行了映射和集成。我们考虑了应用每个 PMBOK 流程时应该考虑的实践，在特定情况下适用的过程集取决于特定的项目需求。在下表中，将概述这些交点。从 PMBOK 指南的角度看项目管理，从 ITIL 4 框架的角度看 IT 服务管理。

                              图4-12 ITIL 4-PMBOK第6版映射图

ITIL 4 将项目管理作为一项实践，其与风险管理一样，穿插于不少的实践过程中。项目管理实践的目的是确保组织中的所有项目都能成功交付，这需要通过规划、指派、监控和维护对项目所有方面的控制，并保持相关人员的积极性来实现的。项目是向组织引入重大变更的手段之一，它们可以被定义为为了根据商定的业务案例提供一个或多个输出（或产品）而创建的临时结构。对于更复杂的转型项目，它们可能是一个独立的计划，也可能是一个更大的计划的一部分，以及其他相互关联的项目。但是，即使是独立项目也应该在组织的项目组合中考虑。最终，ITIL 4 通过调和项目管理与 ITIL 4 众多实践之间的关系，使各实践能与项目管理保持一致。

Q28：ITIL  4和TOGAF的结合关系？

谈及架构管理，各位脑海肯定会浮现出 TOGAF。在 2018 年，TOGAF 也从旧版本 9.1 升级为 9.2。该标准经过重新设计，并重组为较小的出版物，其中包括了一些单独的指南。在新版标准中，TOGAF 框架的核心保持不变，增强了业务架构和内容元模型，对热点技术创新领域进行系统化的设计。TOGAF 目前分为六部分，包括：简介、架构开发方法（ADM）、架构开发方法指南和技术、体系结构内容框架、企业连续性工具以及体系架构能力框架。其架构开发方法见下图：

                               图4-16 TOGAF架构开发方法

TOGAF 列出了四种被广泛接受的子架构：

• 业务架构：定义了商业策略、管理、组织和关键业务流程；
• 应用架构：为待配置的应用系统提供一个蓝图，从他们的交互、他们的关系到该组织核心的业务流程；
• 数据架构：描述一个组织逻辑的和物理的数据资产和数据管理资源的结构；
• 技术架构：描述了支持核心部署和关键任务应用的软件基础设施。

四种子架构，可以认为是 TOGAF 对 IT 世界的一种抽象的归纳。回想起 ITIL，也有这么一个术语与之匹配，那就是 CMDB（配置管理数据库）。我们的 CMDB 基于消费的情况来进行配置，当系统比较复杂，使用精度要求比较高的情况下，CI（配置项）同样可以按照业务、应用、数据、技术四类来进行分类。从最前端的业务开始，将 CI 最终分解到基础架构上去，并且其后带着 CI 之间上下、平行、互相引用等关系。

ITIL 4 将架构管理作为实践之一，纳入其 SVS 框架。该实践的目的是提供对构成组织的所有不同元素的理解以及这些元素之间如何相互关联，从而使组织能够有效地实现其当前和未来的目标。它提供了原则、标准和工具，使组织能够以结构化和敏捷的方式管理复杂的变更。这些不仅包括如何提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。如果没有通过适当的架构管理实践来实现可见性和协调，最终组织只会获得一个传统架构下的迷宫，任何变化都难以实施，并具有极高的风险。

完整的体系架构管理实践应该涉及所有体系架构域：业务，服务，信息，技术和环境。对于规模较小且不太复杂的组织，可由架构师开发单一的集成架构。

• 业务架构：允许组织查看其能力，了解它们如何与为组织及其客户创造价值所需的所有具体活动保持一致。然后将这些与组织的策略进行比较，并执行目标状态与当前能力的差距分析。确定基线和目标状态之间的已确定差距的优先级，并逐步解决这些能力差距。以“路线图”的方式，描述了从当前状态到未来状态的转变，以实现组织的战略。
• 服务架构：服务结构为组织提供了其提供的所有服务的视图，包括描述架构的服务和服务模型之间的交互（服务组件如何组合在一起）和每个服务的动态（活动、资源流和交互）。服务模型可以用作多个服务的模板或蓝图。
• 信息架构：描述了组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共享信息资源以使组织受益。
• 技术架构：定义了支持产品和服务组合所需的软件和硬件基础架构。IT 系统的运作往往需要依赖架构。组织提供服务时，受到挑战的往往是 IT 系统的综合能力，例如在双十一的凌晨，各大电商的后台如何处理突然倍速暴增的订单，这对该组织技术架构的弹性提出了巨大的挑战。
• 环境架构：描述了影响组织的外部因素和变革的驱动因素，以及环境控制及其管理的所有方面、类型和水平。环境包括发展、技术、商业、运营、组织、政治、经济、法律、监管、生态和社会影响。

在应用过程中，ITIL 4 对 TOGAF 的架构开发方法，进行充分地融合。由于 TOGAF 本身所具有的开放性和灵活性，因此不会排斥组织中对其他框架理论的引入和使用，这当然也包括了 ITIL 4。企业架构开发方法各阶段的输入与输出可以不拘泥于其定义，可采用适合组织自身情况的其他框架中所定义的相关内容，并作适当的剪裁，甚至各阶段的先后顺序也是可以调整的。在架构管理的过程中，同样需要采用“持续优化”的方式，进行循环的迭代。

通过 TOGAF 的应用，能够为组织增加弹性、提高敏捷性、增加收入、降低成本以及整合横跨竖井的应用和组织。这些恰恰都是 ITIL 4 所需要的！组织在刚进行架构管理的时候，难免会因为架构的缺乏和粗略而举步维艰。但随着一个又一个架构被开发出来，被应用与管理，架构管理的循环持续进行着，则架构管理的内容将日趋丰富和成熟，从而架构的开发也会越发轻快，架构的管理也会越发纯熟。

总而言之，ITIL 4 将架构管理纳入实践，可以很好地将 TOGAF 的架构设计和演进方法引入服务的价值交付过程中，通过更优化的架构来为客户创造更大的价值。