0. 目录

1. 前言
2. 什么是ITIL
3. ITIL知识模块概览
4. 服务战略
5. 服务设计
6. 服务转换
7. 服务运营
8. 持续性服务改进
9. 总结
10. 参考资料

1. 前言

我所在公司研发中心运维部内按工作内容划分为以下几个小团队：办公IT资产管理、IT基础设施管理、数据运维、业务运维和专门进行运维工具的研发。我参与其中的研发工作，目前正在进行CMDB项目的开发，该项目的目的是满足SA在管理IT基础设施资源时需求，SA管理的资源有：机房、机器、机器的配件、耗材、网络交换机、虚拟网络、IP池等，业务场景有：机房规划、主机交付、资产维护等。

项目名虽为CMDB，但实际所开发的服务与“CMDB”所代表的含义并不全相符。为什么呢？CMDB（Configuration Management Database）全称为“配置管理数据库”。故名思意，它对应的服务是针对“配置项”的“管理”：配置项指的是组织中所有的与IT相关的资产，硬件、软件、文档、人员等都可以视作配置项，管理指的是对配置项的创建、更新、删除（即生命周期）以及配置项之间的关系进行管理。

目前的已开发出来的“CMDB”提供了硬件资产、部分虚拟资源的生命周期的管理，因暂无需求，故未计划提供针对软件、文档、人员等非硬件资产的配置项的生命周期管理和配置项之间的关系的管理。不过，已有的“CMDB”除了CMDB本身定义的能力外，还掺杂了诸如“机房布局设计”、“批量装机”、“机器信息采集”、“工作记录集”等有助于SA高效工作的功能，因而它是不完整但更符合当前需求的“CMDB”。

CMDB对应的“配置管理流程”其实是ITIL（信息技术基础架构库）中的一个流程。ITIL是用于指导实践IT服务管理的框架，其内容是IT服务管理领域内的经过验证的最佳实践，包括流程、任务、checklist等。除了配置管理流程之外，还有我们熟悉的事件管理流程、变更管理流程、问题管理流程等，这些流程有的已存在于我们的工作中，但未被明确定义，未被精确度量、未有计划地对其进行改进。

查看相关资料后，我产生了“原来有许多事情可以通过流程来解决“这样的念头，对ITIL中定义的流程、以及它们如何配合从而实践ITSM非常感兴趣，因此决定花一段时间进行学习。

2. 什么是ITIL

信息技术基础架构库（IT Infrastructure Library，ITIL）是用于指导实践IT服务管理（IT Service Management, ITSM）的框架，其内容是IT服务管理领域内的经过验证的最佳实践，包括流程、任务、checklist等。

ITSM的定义：

自从计算机诞生，企业的运作愈来愈依赖于IT服务质量，对于以提供IT服务的企业更甚。对于IT服务质量的需求催生了IT服务管理，它描述一个组织如何为客户管理他们的IT服务，IT服务管理涉及以下五个过程：计划、设计、交付、运维和控制，它强调持续改进，要求持续度量、改进流程、IT服务、IT基础设施，目标是控制成本、并且高效提供IT服务。

关键词：ITSM、组织、客户、五个过程、流程、持续改进、成本、ITIL、实践。

3. ITIL知识模块概览

ITIL先后有4个版本问世，新版较旧版有更丰富、完善的流程定义和更有逻辑的分类，其中v4于2019年2月份提出，学习材料获取起来不那么方便，因此我选择了学习v3版本的ITIL，它诞生于2007年，因此也被称为“ITIL2007版”。

ITILv3将内容划分为【五大块】，包含多达【26个流程&职能】。这五大块分别是：

1. ITIL Service Strategy: understands organizational objectives and customer needs.
2. ITIL Service Design: turns the service strategy into a plan for delivering the business objectives.
3. ITIL Service Transition: develops and improves capabilities for introducing new services into supported environments.
4. ITIL Service Operation: manages services in supported environments.
5. ITIL Continual Service Improvement: achieves services incremental and large-scale improvements.

一个服务的生命周期一般会有以下几个阶段：立项、设计、研发、测试、上线、转运维、下线。可以按照以下方式建立起从非常基础的服务生命周期到ITIL的五块主题的映射：需求/立项-【服务战略】、设计-【服务设计】、研发/测试/上线-【服务转换】、转运维-【服务运营】、全生命周期-【持续性服务改进】。

4. 服务战略

服务战略是指通过有效的IT服务管理将组织的IT资源转化为组织实现商业目标的【战略资产】。

服务战略涉及4个流程：战略制订、财务管理、服务组合管理、需求管理。

【战略制订】中我们需要考虑愿景、使命、产品、客户群体、市场定位、竞争目标等问题，例如：

1. 我们提供什么服务
2. 谁是我们的客户
3. 当前所处的位置与竞争对手
4. 如何获得市场渠道
5. 如何衡量服务的质量
6. 如何很亮客户的需求是否得到满足，实现客户价值

【财务管理】分为3个阶段：预算、结算和收费。（IT支持部门在消耗预算满足来自业务部门需求的同时做好结算，给支撑的业务部门开收据？）

【服务组合管理】负责对组织内所有服务的生命周期和组合进行管理。它主要回答以下几个问题：

1.目前有哪些服务已落入需求管道、正在开发、或是已经可以提供使用？

2. 通过哪些服务的组合能够提供更加符合客户需求的产品和解决方案？
3. 哪些服务计划下线不再供应？

在服务设计部分中有一个流程“服务目录管理”与服务组合管理很相似，它们之间的关系应是：服务组合管理包含服务目录管理。服务组合管理除了服务目录管理外还多出了决定要做的或是正在研发的服务以及对服务的下线进行管理这两部分，较之服务目录管理更为全面。

提前给出服务目录管理的定义以便对比：

目前可以直接部署和允许授权给客户使用的服务。包括关于服务可交付件的名称、价格、联系人和申请信息等。

【需求管理】负责决定做什么。客户的需求是动态的，具有渐进明性的特点，因此在开发过程中有意识地与客户确认需求非常重要。需求沟通有两个方法可以推荐：用例图和系统关系图。任何需求的变更都需要进过客户的最终确认。

用例图是统一建模语言中用于确定需求范围的一种图，使用通用的“语言”进行沟通，对于明确系统的功能、业务边界非常有效，是我最喜欢使用的工具。（再加上进行用户原型设计、通过用户原型与用户最终确认需求，对开发出来的服务符合用户期望会更有信心）。

关键词：做什么、渐进明性、随需而变、用例图、系统关系图、业务单元、外部组件、信息流动、业务范围、不做什么、客户确认

大致过了一遍服务战略中的四个流程：战略制订、财务管理、服务组合管理、需求管理。可以暂且概括为：确定做什么、明确当前能以及计划将来能提供什么服务并且管理好财务。

5. 服务设计

服务设计是指为了满足商业需要而设计新的服务，或者为已有服务增加新的功能，内容包括系统架构、业务服务流程、企业运营策略规划以及指导组织如何提高服务管理能力等。

服务设计涉及7个流程：服务目录管理、服务级别管理、容量管理、可用性管理、服务持续性管理、安全管理、供应商管理。

【服务目录管理】即维护一份组织所能够提供的服务的清单，服务的信息可能包括价格、可交付件、联系人等。在大型的提供各种IT服务的组织中服务目录大概会更加重要。不过，即使在新兴的以某几个应用甚至一个手机客户端应用为核心产品的ToC的企业中，建立的商业服务目录也很重要，结合技术服务目录，我们除了能够给内外部客户提供一份“下单”用的”菜单“外，还能够基于服务目录对发生的故障进行根因部件归类，这对于事件的收敛非常重要。

【服务级别管理】即与客户对于如何衡量服务的质量达成一致，需要明确度量的指标、满足要求的范围、以及在协议未达成时违约的一方所要付出的代价。部门可能需要与三类对象建立服务级别协议，与客户建立的协议被称作”服务级别协议（SLA）“、与内部客户达成的协议被称作“操作级别协议（OLA）”、而与供应商达成的协议被称作支撑合同（UC）“。

【容量管理】即在合理成本控制下，提供适宜而有效的资源管理，使得IT资源能够被合理地利用，并且能够适应当前和未来的商业需要。具体包含以下三类：商业容量（用户）、服务容量（性能）、资源容量（基础设施资源利用率）。

关于容量管理，Google的SRE Book中有一个很有趣的概念——“基于意图的容量管理”。基于意图，指的是业务方提出申请一定数量的资源时，IT部门会通过不断追问为什么，来确定对方最终想到达成的目标，这个目标一般是“希望服务的SLA得到保障”，最终资源的分配会以达成这个最终的目标为目标进行，而不是完全按照以业务方的直接需求进行。为了基于意图进行容量管理，Google研发了一套专门用于进行容量管理的系统，通过输入业务方的意图、历史的性能数据、服务之间的依赖关系等数据，再通过线性规划求解得出可能不是全局最优但是局部最优的资源分配方案。

【可用性管理】指通过各种方法来使得服务达到较高的可用性。服务的可用性即服务的实际可用时间与承诺的可用时间之比，所以提高可用性的方法有两个：提高服务实际可用的时间（减少故障时间）、不要承诺不切实际的可用时间（比如100%）。

在提高服务的可用性方面，Google的SRE有很好的经验可以借鉴：通常业务方更专注于也更擅长于系统的功能性需求开发，对于系统的非功能性需求（可靠性、安全性等）则关注地较少，而有经验的运维人员因为需要承担对服务的后期维护工作，因而对于服务的可维护性、可靠性更敏感。 Google提出了PRR模型（PRR，Production Readiness Review Model）——运维部门将积累的有助于服务可靠性的经验整理成为一份清单，在服务进入生产环境前对照该清单进行核对，评估服务是否满足进入生产环境所具备的可靠性要求。BTW，这个评估过程是灵活地，并不是只有在服务完全满足要求时才可通过评审，通过评审的标准可以根据服务所处的阶段、评估项的重要程度进行适当地调整，核心是不断完善评估标准（哪些是必须满足的、哪些是有条件必须满足的、或者是建议满足的），对服务当前的可运维能力、稳定性进行全面的评估，并且运维与开发就改进计划达成一致，类似在上线前先建立了一个戴明质量环。对于运维方面外的重要非功能性的需求（如：安全、运营）也可以模仿这一方法进行，实施生产环境安全性准备度评估、生产环境运营能力准备度评估。

【服务持续性管理】指确保在重大自然灾害中，服务中断后能够在一定的时间内恢复中断的服务，尽可能减小商业影响。即我们常讲的灾难恢复计划，平时做好备份，制订好灾难恢复计划，在发生灾难时，按照既定的流程进行处理。这听起来就很难的样子，要确保灾难恢复计划的有效性，最佳的方法应该是进行灾难恢复演练了。有计划地定期备份恢复计划有效性测试这类活动进行是非常有必要的。

【信息安全管理】指通过实践【ISMS标准】保障组织内信息的保密性、完整性和可用性。

【供应商管理】指对供应商进行管理，确保供应商的资质以及所提供的服务能够帮助组织实现商业目标，具体需要进行三个方面的工作：供应商资质审核关系维护、商业洽谈、创建和维护合同数据库（第三个方面的工作其实是对前两个方面工作的成果进行存储维护，在OA系统有供应商相关的流程入口，能够进行对供应商资质、相关合同进行管理的流程处理）。

6. 服务转换

服务转换

服务转换涉及4个流程：变更管理、服务资产和配置管理、发布与部署管理、知识管理。

【变更管理】指通过标准的流程来管理变更，确保变更达到目的，且尽可能减少因变更导致的生产环境故障、能够回答什么时候，什么东西发生了什么改变这样的问题。

（这里的变更是变更申请，变更申请被提出后不一定能通过审批、通过审批后实施不一定成功，所以变更管理回答的是什么时候、什么变更被提出来、被实施、被回退，什么时候什么东西发生了什么改变应该是配置管理来回答？）

处理变更请求是运维部最重要的工作内容之一，因为变更验证不充分、操作过程有误、缺少回滚方案等原因可能导致故障的发生，所以对于变更的管理会比较重视。在ITIL中对于变更定义的流程中存在的活动先后是：记录、验收、分类、规划和批准、协调、评价。要完全按照这几个步骤来执行的话，对于组织的成熟度要求比较高，相对难以实现，比较好起步的是做好记录、分类和评价，先收集数据评价现状，再基于数据反映的现实进行改进。

在理想的情况下“变更必须在类生产环境验证通过后才可以发布到生产环境”，有时会因为一些原因导致验证没有被执行或是验证缺乏有效性。最经典的原因大概是：类生产环境与生产环境不一致。类生产环境与生产环境严格一致可能确实难以做到，不过可以尽可能地保持一致，目标是使变更在上线前的验证的有效性尽可能得到保证。【变更的可靠性取决于是否经过可靠的验证，以及实施人员严格按照操作指南进行】，如果没有可靠的验证结果、没有详细的操作指南，无论是多么有经验的运维人员，都难以保障变更成功，因此一旦回溯变更导致的故障时，至少需要考虑：变更是否在类生产环境上验证过？变更的步骤是否严格按照操作指南？如果是，为什么在类生产环境上验证时未能发现问题？

追问这些问题，不是为了处罚某一个人或团队，而是为了找出流程中的漏洞，对流程进行完善。在《Effective DevOps》一书中有这样的观点——问责的方式应该避免犯错的人因受到责备与惩罚而发展出恐惧的文化，这可能会导致团队内出现高墙，阻碍清晰透明的沟通；相反地，应该把问题看作个人和组织学习的机会，通过协作解决问题。前后两种处理问题的方法，体现出两种对立的思维方式：1、错误是由于人的恶意或能力不足造成的，解决人的问题即可；2、个人的错误只是一种“症状”，指示系统可能存在更深层次的问题，个体只是根据具体的上下文和对他们来说最有意义的方面做出选择并采取行动，而不是有意的恶意行为或能力不足，因此组织应该对系统做更全面的考虑，以尽可能地减少问题。（这里所说的更全面的考虑有一部分指的就是流程上的考虑吧）

【服务资产和配置管理】负责对组织内所有与IT服务相关的配置项的生命周期，以及他们之间的关系进行管理。

对于配置管理在前文中已有描述，开源的产品比如：腾讯的蓝鲸配置管理平台，是一个地地道道的配置管理数据库，它支持用户对配置项进行定义、对关系进行定义，与配置管理的定义相契合，使用起来可定制化的程度非常高。

【发布与部署管理】有两个定义：

定义一、采用一种项目规划的方法来实施IT服务中的变更，负责对即将导入运营环境的软件和硬件进行分发。

定义二、确保服务提供者能够快速交付、降低发布成本、减少风险，并提交与客户最初需求一致性的产品。

定义二与CICD的理念不谋而合：在构建阶段充分测试内建质量、通过流水线自动化部署快速迭代交付新特性，能够在保证产品质量的前提下提高生产率，快速地将可靠的产品推向市场，及时获取用户反馈，引导开发正确的产品，最终提高用户的满意度。一般会从速度和稳定性上对CICD能力进行衡量，包括2个速度指标（部署频率、平均部署时长）和2个稳定性指标（部署失败率、平均部署失败恢复时长）。

结合定义一与定义二，我们不难得出发布与部署管理具体的工作内容包含：对相关的变更进行组合，统一发布，避免冲突、提高效率；提供将服务交付件发布到生产环境的发布通道；提供持续集成与持续部署流水线，流水线贯穿开发、测试、类生产和生产环境，在各个环境使用的交付件是同一个，不二次构建。

因为变更与发布是需要经过评审、授权的，对于敏捷的程度有了一定的限制，需要如何处理呢？在一些组织里，会有限制地给服务授权免审批发布部署的权利，前提是该服务满足一定的条件，一旦发生自动化部署失败的情况，则收回权限，严重时甚至会禁止其在一定的时间段进行线上变更，避免单一服务为了追求速度，破坏了生产环境整体的稳定性。

【知识管理】即对服务生命周期中产生的数据、信息、知识和智慧（DIKW模型）进行管理，确保具备合适的知识的人在合适的时间实施和维护商业服务、辅助决策。

关于DIKW模型，我想试着用一个例子来说明一下。DIKW分别是Data（数据）、Information（信息）、Knowledge（知识）和Wisdom（智慧）的简写，从拥有数据到拥有智慧的过程是人对事物认知逐渐深入的过程。以太阳从东边升起为例：

• Data：2019年11月9日，太阳早上6点36分从东边升起
• Information：一个太阳每天早上都会从东边升起
• Knowledge：因为地球自转，并且围绕着太阳公转，所以太阳每天早上都从东边升起
• Wisdom：因为万有引力，行星自转并且围绕恒星公转，所以行星上有昼夜四季之分

这个例子不一定合适，但能够体现——【越是靠近智慧，对事物的认知则越深入透彻】：数据是当下客观所见、信息是根据客观所见总结出的规律、知识则更近一步回答了为什么会有这样的规律、智慧则具有更广阔的适用范围，更靠近“道”。

现在我们有ONES协作平台，通过搜集数据、总结规律、追问原因、提炼智慧，产生DIKW并集中归档到平台上。

变更管理、服务资产和配置管理以及发布与部署管理归到服务转换比较好理解，可是知识管理为什么也归到服务转换里呢？

7. 服务运营

服务运营涉及5个流程（事件管理、故障管理、问题管理、请求实现、访问管理）和4个职能（服务台、技术管理、IT运营管理、应用管理）。

【事件管理】指对企业业务系统日常的信息、告警和异常情况进行跟踪和处理。

在ITIL中将事件分为三类：信息、告警和异常。

信息的例子：SA执行了一个关机的命令的操作（例如：企业微信SA这边有一个日常信息提醒群正好有提供这类信息）、给某台机器进行了维护新增加了几块硬盘、工作记录（现在正在开发的“更符合SA需求的CMDB”中有一项“记录集”的需求，提供记录集功能是为了满足SA对机器、配件、耗材的入库、使用、维护工作进行记录，并自动与库存系统进行联动的需求，在这里SA主动创建的一条条的记录就是信息）。

告警与异常的分界有点模糊，比如说机器故障，既可以当作异常看待，亦可以视作告警（如果配置了机器宕机的监控告警）。

事件管理所做的就是将这些正常的、不正常的信息整合在一起，搜集的大量的事件除了发送给必要的相关人、或者用于审计外，还有一个很容易联想到用途，即与故障管理结合，提供某个故障发生前所发生的事件集合，结合机器学习相关的技术辅助故障排查。

【故障管理】（或译作事故管理）指对IT服务未计划的服务中断或服务质量下降这类“突发事件”进行管理，尽快把异常的服务恢复正常，减小对客户的影响。

在Google的SRE Book中，将SRE的工作划分为三大类：有计划的变更操作（上线新服务、新特性、例行维护等）、故障处理、开发提高工作效率的工具。我们假设运维部门以SRE为目标，希望通过践行SRE的软件工程原则，把SRE的三大类工作分别做到极致，那么除了参考SRE Book外，前两类工作正好可以参考ITIL中直接与前两类工作对应的流程：服务转换中的变更管理流程、服务运营中的故障管理流程。

回想以前所经历过的故障处理，结合现在ITIL中对该流程活动的描述，在故障管理中需要关注的地方：事件定级、事件分类、事件处理流程、SLA算法、事件通报、事件升级、根因分类、责任部件。

目前运维部门的故障主要来源于两个渠道：客服和监控告警，前者是我们的服务台，接受外部用户报障并记录在客服Bug保障系统，后者是内部的运维服务，在检测到异常时将异常信息通知到运维人员，运维人员再将事件记录在ONES上。目前事件都有被记录，并得到处理，未来也许会研发一个统一的事故管理系统，作为事故处理的统一入口，以便更好地对事故进行管理。

【问题管理】指的是对造成故障的原因的管理。

故障管理负责快速恢复服务，造成故障的根因不一定被修复，系统中还可能发生相同的问题，这个造成故障的根因的生命周期由问题管理流程负责。

该流程中需要关注的地方有：问题定级、SLA（对于不同级别的问题的解决期限承诺）、问题处理规范（处理问题时的一些原则要求）、共性问题管理、质量回溯（反复出现的问题需要特别关注）。

开发直接面向客户、用户的服务团队相对于开发面向内部用户的服务的团队来说问题管理的意识一般会更强一些，差异点表现在：是否对问题进行记录、是否对问题的类型、级别等必要信息进行记录。

问题管理对应公司敏捷协作平台提供的项目缺陷管理功能，它支持问题定级、问题分析、缺陷列表导入导出、问题状态流转、处理过程评论记录等，用户体验还蛮不错的。

【请求实现】即实现来自用户的请求，用户的请求内容一般包括三类内容：询问与服务相关的信息、建议；申请进行某个标准的变更；申请开通访问某项服务的权限。

现在运维部门内部有许多实现内部用户请求的平台，例如实现用户创建数据库实例的DB平台、交付用户主机的CMDB平台，在此基础上，将来也许会首先开发一个供内部用户提交服务请求的平台（或者称之为工单系统），这些服务请求根据所请求的服务类型被分发到对应的服务组，像这类标准而非紧急的服务请求，应该以更具计划性的方式来进行，理想的实现方式是内部客户提前一定时间提出服务请求，提供服务的一方安排固定的时间段统一处理，在预先承诺的时间内完成服务请求即可（比如，当天上午12点提交的申请，当天下午16点完成，12点以后提交的申请在第二个工作日的16点前完成），标准而非紧急的变更申请亦然。

【访问管理】的目的是提供给授权的用户访问服务的权利，并且能够组织非授权用户的访问，可以看作操作级别的安全管理，同样也会考虑数据的保密性、完整性、可用性。（比如：线上环境的机器都需要通过堡垒机登陆、业务使用释迦运维平台上的服务时需要申请对应的权限，登陆ELK查看服务的日志也需要具有对应服务的权限...）

------分割线（接下来的部分为服务运营中的涉及的4个【职能】）-----

【职能】是一组人员组成的【团队】以及他们使用的相关的【工具】，用来完成一个或多个流程或者活动

【服务台】是组织提供的面向用户的单一联系点，客户遇到问题时直接联系服务台工作人员，服务台的工作人员创建工单，并推进工单的解决，工单的解决以客户最终满意为标准。ITIL中对于服务台的种类按照区域、能力进行了划分，分别是：本地服务台、中心化服务台和虚拟服务台。公司服务台，并且他们使用“客服报Bug系统”对用户反馈的问题进行了记录。

【技术管理】包括提供IT基础架构技术支持和管理的所有人员。目的是确保需要的资源、技术能够被用来计划、执行和维护一个稳定的技术架构。

不久前公司成立了技术管理委员会，其职责有五个方面：营造技术氛围、发展员工技术能力、整合优化技术架构、管理重大项目、调研核心技术并与外部进行合作。其中的“整合优化技术架构”与这里的技术管理所进行的大概是类似的工作。

【IT运营管理】是IT服务上的内部功能，它负责执行管理和IT服务和支持IT基础架构所需要的日常活动。目标是维持IT服务提供商日常流程和活动的稳定性，监控并改造当前的服务质量和解决已经发生的所有IT运营故障。

还记得现在所学习的不是【流程】，而是【职能】，职能指的是【人】和【工具】。从IT运营管理的定义中可以看出他可能涉及的流程有服务可用性管理、故障管理——监控到发生内部系统故障，服务器宕机等问题，IT运营管理这一职能中的工作人员这时候会联系技术团队解决问题，将必要的情况反馈给用户，并在问题解决后将结果同步给用户。

【应用管理】包括提供技术经验和应用管理的人员。与技术管理类似，不同的是它关注【软件应用】而非【基础架构】。目的是有效地识别应用软件的功能性需求和非功能性需求，以更好地支持客户的商业业务流程。

8. 持续性服务改进

持续性服务改进指的通过持续地对服务和流程进行度量、改进，保持服务对客户的价值以及组织提供服务的效率。

持续性服务改进模型包含以下6个步骤：

1. 了解企业的商业目标，并设立愿景，IT服务的战略必须与企业的商业战略保持一致；
2. 根据对企业目前业务、组织、人员、流程和技术的分析来为企业的现状设立基准；
3. 根据企业的愿景来设立具体的目标和可管理的框架；
4. 细化服务持续性改进计划并对现有流程进行必要的改进；
5. 确认服务度量方法和指标，以确保达到既定的里程碑；
6. 确保服务改进的变更在企业中实施，保证服务的持续性改进。

这6个步骤要求IT部门根据企业的商业目标思考自身的目标、分析现状、思考如何衡量自己是否达到目标，类似于OKR，同时还包含了质量改进的理念。

持续性服务改进模块包含3个流程：七步改进流程、服务度量和服务报表。

【七步改进流程】：

1. 定义你所要度量的是什么
2. 定义什么是能够度量的
3. 收集数据
4. 处理数据
5. 分析数据
6. 呈现和使用信息
7. 实施改进活动

相关的方法：

DMAIC：生产制造业中经常被使用的“六西格玛”服务管理流程对于服务质量改进也有一个方法——DMAIC（定义、测量、分析、改善、控制），其工作内容与七部改进流程大同小异。

Pareto分析法：是一种在测量和分析阶段使用的用于分析质量缺陷原因的方法（80/20法则的具体应用，基于先验假设：较多的问题集中在较少的原因上）。

【服务度量】是服务质量管理的衡量标准，一般的，有如下四个基本原因去监控和度量数据：

1. 校验以前的决定是否正确
2. 指导行为去满足设定的目标
3. 由实际的证据去证明行为的正确性
4. 在适当的点进行干预和改进行为

对于度量，可以划分为三类：流程度量、服务度量和技术度量。

【服务报表】是服务提供者对服务质量数据的采集和监控工具。被采集的数据可以包括：每月被服务的客户的问题请求量、变更请求量、日常的内部审计请求量、服务器性能、数据库性能、应用性能、网络性能、存储外设性能和违背服务级别协议量等。

根据报表数据，我们可以分析过去的失败，总结经验教训。在执行所提到的流程中，就能得出与该流程相关的报表，支持持续性服务改进。比如：每月被服务的客户的问题请求量、变更请求量、违背服务级别协议量三份报表是分别与故障管理流程、变更管理流程以及服务级别管理相对应的。

9. 总结

【学习的媒介】我学习的主要资源是书籍，以及百科词条。通过百科词条以及网上前人写的介绍，我了解了ITIL整体的“画像”，有了一个整体且表面的理解；《基于ITIL的服务管理基础篇》一书对于大部分流程有中等程度的介绍，因为其中的“事故管理”、“问题管理”、“变更管理”和“配置管理”这几部分与目前运维部的工作联系最紧密，我比较仔细地阅读了这几部分的内容，因而对这几部分的印象比较深。

【学习的过程】 我尽可能地用自己的语言描述其中涉及的每一个流程概念，有时记录由该概念所引发的简单的想法，若实在没什么感触，想象不出来具体会做什么事情，那么我就暂且引用书中的定义，然后进入下一个部分。

【关于做笔记】在【连续学习多个新概念】的场景下，学一个概念，然后马上做笔记把它记录下来，这种做法效果不佳。如果加上这样的一步（甚至只进行这一步）效果会好得多，即——”连续学习多个概念【一段时间后】，然后【脱离资料】在笔记本上写下现在自己对那些概念的理解”，如果脱离了参考材料没有办法写出个四五六七来，那么就回去看材料，过一段时间再继续。

【学习的效果】在前面我提到自己学习ITIL的原因——“查看相关资料后，我产生了“原来有许多事情可以通过流程来解决“这样的念头，对ITIL中定义的流程、以及它们如何配合从而实践ITSM非常感兴趣，因此决定花一段时间进行学习。”这个效果当然是没有达到了，因为ITIL是实践的学问，没有具体的实践，从书本上学习到的知识只是记问之学。

那些我最开始努力想记住的概念就随它们去吧，它们并不是自己此次ITIL之旅中所获最大的收获——具体就是认识到我们的工作中可为之处、可依之法有许多。定好目标最为关键，只要目标定好了，然后踏踏实实地一步一步向前，并且这个过程中不忘抬头看路，即使不能最终抵达目的地，也不会偏差太远，这也是ITIL中服务持续性改进中所传达的质量改进理念。

10. 参考资料

1. 《基于ITIL的服务管理基础篇》
2. 关于ITIL V3＆ITIL 2011，你需要知道这些！
3. ITIL WIKI词条
4. 《ITIL与DEVOPS 服务管理与案例资产详解》