配置通常被认为是 ITIL 服务管理的核心，因为其他所有流程均需要使用配置管理数据库 (CMDB)。因此，CMDB 的准确性和及时更新至关重要。考虑到 CMDB 的重要性，发现配置管理具有管理报告和 KPI 就不足为奇了。在查看推荐的度量标准之前，我们应该提醒自己配置项 (CI) 是 CMDB 中的一项。首先，我们先从管理信息谈起：

配置审核的结果。
已检测到的所有未注册或未准确注册 CI 的信息和纠正措施。
按 CI 的种类、类型和状态（也可能按位置或其他 CI 属性）细分的注册 CI 数量和 CI 版本的有关信息。
增长和容量信息。
CI/CMDB 和 DSL（留存软件库）的变化率信息。
因配置管理活动造成的配置管理工作的任何工作积压或任何延迟的详细信息以及提出的补救措施。
配置管理人员配备原则。
其他 IT 服务人员在上班时间之外完成的授权工作量。
效率/效益复查、增长复查和配置管理系统审核的结果以及解决实际或潜在问题的建议。
按数据类型（例如，服务、服务器、路由器、集线器、软件许可证、台式机等）分类的 CI 数量的有关数据和分析。
CI（或资产）值。
按业务部门、支持小组或服务分类的 CI 位置。

第 8 章
作为 ITIL 的关键组成部分，在经过修订的最近几期 ITIL 出版物中，发布管理得到了全面修订。以前，发布管理只是与管理 IT 环境内的软件版本有关。现在，发布管理的应用范围则更为广泛，正如《服务支持》一书 “发布管理”那一章中的摘要所述：
许多服务提供商和供应商可能会在分布式环境中发布软件和硬件。良好的资源规划和管理对于成功地封装产品以及将其分发给客户是必要的。发布管理从历史角度看待对 IT 服务所作的变更，并应该能够确保从整体（包括技术方面和非技术方面）上对发布作出判断。(9.1.“发布管理”的目标)

术语“发布”用于描述一组经过授权的对 IT 服务所作的变更。发布是由其执行的 RFC（变更请求）定义的。发布通常含有许多故障修复以及服务改进。发布内含实施经过批准的变更所需的全新的或已经改进的软件和硬件。（9.3.1. 发布）
发布管理现已是 ITIL 的关键组成部分。与其他 ITIL 流程一样，发布管理也有两种度量标准：关键性能指标 (KPI) 和管理报告。首先我们按 ITIL 所列大纲来讨论 KPI：

按计划并在预算限度内构建和实施发布（但应注意隔离那些不受发布管理控制或管理的故障，如应用程序开发延迟）。
极少（理想情况是不会）由于出现不可接受的错误而必须取消发布（但请注意软件发布无需完全不出错 ；即使存在错误也可继续发布，前提是错误很小并在容错限度内）。
极少出现结构性故障。
安全精密地管理 DSL（留存软件库）。
DSL 中不存在未通过质量检查的软件以及对从 DSL 中提取的任何软件进行返工的迹象。
DSL 大小符合空间要求，并及时而精密地管理 DSL。
符合与所购软件有关的所有正当限制。
将发布准确地分发到远程站点。
在所有站点包括远程站点上准时实施发布。
不会在任何站点出现未经授权恢复使用以前版本的迹象。
不会在任何站点出现使用未授权软件的迹象。
不会出现为那些实际上未在任何特定地点使用过的软件支付许可费或进行维护。
在构建发布的过程中不会出现存在无用副本的迹象（例如，在一个版本的副本够用时，构建远程站点的多个版本）。
准确及时地在 CMDB（配置管理数据库）内记录所有构建、分发以及实施活动。
对所有发布活动、所有已采取的必要的纠正措施或后续操作以及任何流程改进进行检查。
拟定的发布组成与实际的组成一致（这证明发布的计划工作良好）。
“发布管理”所需的 IT 和人力资源应符合正在实施的合理促进计划的要求。

第 7 章
与故障管理一样，ITIL 建议对变更管理分两级进行监视。第一个监视级别是管理报告，这与故障管理相同。第二个级别稍有不同，因为 ITIL 在此交叉引用了英国标准学会的出版物“IT 服务管理实施规范 (PD0005)”。第二个级别的重点是详细的“变更管理”报告。切记这两个级别“变更管理”的主要目标都是：
“变更管理”流程的目标是确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响降到最低，并因此改进公司的日常运作。

第 6 章
《ITIL 服务支持》中的“故障管理”一节讨论从两个方面进行测定和监视：管理信息和比照“服务级别”的性能优劣。首先我们来看管理信息，然后再来讨论“服务级别”。

对于管理信息，请记住 ITIL 的故障管理目标：
“故障管理的目标就是尽量减少由 IT 基础设施出现问题而导致的事故和故障对业务产生的负面影响，并防止与这些错误相关的事故再度出现。”“为了达到此目标，故障管理寻求找到引发事故的根源，并随后采取措施改善或纠正此情况。”

《ITIL 服务支持》一书中的“事故管理”一节将监视和测定称为关键性能指标 (KPI)。关于 KPI，ITIL 表述如下：
“若要判断流程的性能，应该设定定义明确且具有可测定对象的目标 — 也称为关键性能指标 (KPI)”。
当查看 ITIL 列举的例子时，切记这些例子是与事故管理而非服务台本身相关。对于“事故管理”流程的效果和效率，ITIL 将以下列度量标准为例：

事故总数。
事故得到解决或得以规避的平均时间（按影响代码划分）。
在约定响应时间内已处理事故所占的百分比（如通过影响代码可在 SLA 中指定事故响应时间目标）。
每个事故的平均成本。
在没有求助于其他支持人员的情况下，由服务台查明的事故所占的百分比。
每个服务台工作站处理的事故数量。
无需进行访问而远程解决的事故数量和百分比。

第 4 章
既然具备了基本条件，我们就可以转而关注监视和测定，因为它们与 ITIL 服务支持流程的每一步都是相关的。对于大多数流程，ITIL 出版物都有说明需要测定和监视内容的章节。这些小节并未标准化，具有不同的标题，如“关键性能指标”、“报告和复查”以及“测定和报告”。在此我们首先将查看 ITIL 推荐的每个流程。然后，在必要时将提出与这些流程尤其是与业务取向领域相关的其他建议。

ITIL 出版物中所描述的许多度量标准都是指总体总数和平均数。这些数据适于快速查看，但在试图据其确定工作量和实际值的情况下可能会极易令人误解。

接下来看一个例子。服务台一天内收到的事故总数为 1,960 起，而允许发生事故的上限为 2,600 起。每小时的平均事故数为 151 起，而每小时允许发生事故的上限为 200 起。从上述数据看起来一切都很正常。但客户一直对服务质量表示不满。从图 5 中可以看出客户不满意的原因：

服务台的工作人员每小时能够处理的最大事故数量为 200 起，但如图所示，在上午 7 点和 11 点以及下午 4 点和 5 点之间，他们每小时遇到的事故数量大于 200 起。怪不得客户不满意。这个简单的例子说明了仅看总数和平均数是不保险的，同时也说明了对总体的把握为何如此重要。

ITIL 推荐的监视和测定最佳惯例往往包括百分比，这也同样令人误解。例如，99.8 % …

第 3 章
不论是为了定向、介入、证明还是验证而进行测定，您都应该遵循下列的简单过程：

第 2 章
进行监视或测定应该总是事出有因。您应该不断思考“为什么要进行测定？”或“为什么要整理数据？”监视和测定的理由主要有四个：

定向：这包括进行监视和测定，以便为活动设定方向，以达到既定的目标。这是进行监视和测定最一般的理由。例如，服务水平协议 (SLA) 用于设定目标度量标准，而 IT 部门的测定是对照这些目标进行的。这些目标为 IT 部门指明了方向。

介入：通过进行监视和测定来确定介入点，包括后续变更和纠正措施。例如，可对网络进行监视，并确定网速很慢。结果是 IT 人员将进行调查，这会导致对其进行改动以提高网络性能。可能还会为进行调查执行特殊的监视，以跟踪改动的效果。此外，通常只有在改动期间才会基于这些度量标准进行监视。不过，为了进行定向并确保性能在将来不会恶化，可能必须持续地进行测定。

证明：利用实际的征兆或证据证明某一行为过程是必要的。例如，在进行大宗采购之前必须预测投资回报。进行可行性证明通常需要预测趋势、制定财务计划和/或建立财务模型。在通常情况下，我们首先要证明某一项目的可行性，其次验证其交付成果。

验证：进行监视和测定以验证先前作出的决策是否正确。例如，实施配置（资产）管理的理由可能是将购置资产的费用降低 10%。这需要利用测定工具跟踪和监视项目的节约效果，以便验证是否实现了 10% 的节约目标。项目完成后，就不再需要测定以进行验证了。

进行监视和测定的四个主要理由引出了两个关键问题：“为什么要进行监视和测定？”和“何时停止？”若要回答上述问题，您必须确定是上述哪个原因导致需要进行或停止测定和监视。在大多数情况下，我们会在无需进行测定之后再持续一段时间。在每次报告时都应考虑“我们是否仍然需要进行监视和测定？”

第 1 章
信息技术 (IT) 小组一般精于收集大量数据。然而，对于作出与业务相关的决策，收集来的数据并不总是得到了充分地利用。大多数情况恰恰相反。例如，许多 IT 部门测定和监视在服务台发生的所有事件，却仍可能未注意到一台关键服务器已经接近满负荷运转。为什么会出现这种情况？这是因为服务台技术可以自动收集有关服务台性能的大量数据，而测定服务器容量方面的增长则需要进行其他工作和干预。

对于已受过 ITIL 培训、阅读过 ITIL 书籍或参加过 ITIL 讨论会或集训的人来说，ITIL 所带来的好处往往是显而易见的。通过推介对公司不同部门具有重要意义的内容，以及传达《ITIL 服务交付和服务支持》中概括的目标，本系列的前两册的重点集中在 ITIL 高级概念上，这些概念有助于 ITIL 专家培养公司内部非 ITIL 专家的约束感。

在本系列的第三册中，将通过重点讨论《ITIL 服务支持》一书中介绍的监视和测定最佳惯例来继续探讨 ITIL 高级概念，包括以下内容：

事故管理
故障管理
变更管理
发布管理
配置管理
《ITIL 服务支持》一书的各节详列了管理功能区域的人员需要思考的度量标准。本书总共列出了 80 个推荐的测定方法，以便用于监视和测定这些流程的性能。

在本书中将通过引用 ITIL 定义、用清晰而简明的术语进行表述，以及向 IT 经理和业务经理建议如何充分利用数据来复查每个 ITIL 度量标准。通过重点强调这些关键指标，可以帮助您向 IT 部门内负责管理相关功能区域的人员阐明 ITIL 最佳惯例的价值。

本书还将继续介绍 ITIL 推荐的度量标准，并介绍“业务取向指标”。这些关键的度量标准用于拓展 ITIL …