• 首页
• ITIL 电子书
• 关于作者

服务支持度量标准

发布管理

第 8 章

作为 ITIL 的关键组成部分，在经过修订的最近几期 ITIL 出版物中，发布管理得到了全面修订。以前，发布管理只是与管理 IT 环境内的软件版本有关。现在，发布管理的应用范围则更为广泛，正如《服务支持》一书 “发布管理”那一章中的摘要所述：

许多服务提供商和供应商可能会在分布式环境中发布软件和硬件。良好的资源规划和管理对于成功地封装产品以及将其分发给客户是必要的。发布管理从历史角度看待对 IT 服务所作的变更，并应该能够确保从整体（包括技术方面和非技术方面）上对发布作出判断。(9.1.“发布管理”的目标)

术语“发布”用于描述一组经过授权的对 IT 服务所作的变更。发布是由其执行的 RFC（变更请求）定义的。发布通常含有许多故障修复以及服务改进。发布内含实施经过批准的变更所需的全新的或已经改进的软件和硬件。（9.3.1. 发布）

发布管理现已是 ITIL 的关键组成部分。与其他 ITIL 流程一样，发布管理也有两种度量标准：关键性能指标 (KPI) 和管理报告。首先我们按 ITIL 所列大纲来讨论 KPI：

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

不出所料，上述 KPI 中的一些包含与变更管理中类似的度量标准。这种情况是无法避免的，因为发布管理和变更管理是密切相关的。然而，我们还应看到，两者之间还有一些主要差别。

按计划并在预算限度内构建和实施发布（但应注意隔离那些不受发布管理控制或管理的故障，如应用程序开发延迟）。若要使该 KPI 可行，有必要将其表述为“在上个历月并在预算限度内构建和实施的发布的数量。”

原来的表述并没说明 KPI 涵盖的时段。“历月”只是用以举例说明需要特别注意测定期限。您还必须对“不受发布管理控制或管理”进行明确定义，以确保其准确性并减少混淆。

实际上，此 KPI 可用作快速检查指定时段内成功发布的清单。同样，这还是一个重要的 KPI，但是应在作出报告时将每个成功的发布放在一行之内。报告通常应包括拟定的发布日期/时间、实际的发布日期/时间、发布索引号、发布所有者以及未受控注释。若要从报告中充分受益，可将其与以下列出了失败发布的报告进行比较。对于此 KPI，成功率越高越好。

• 业务取向指标 — 对于许多业务经理，尤其是那些在特定时段内收到发布的业务经理，这是一份“必读”的报告。请准备好与业务经理就已确信“不受发布管理控制或管理”的发布所导致的问题进行讨论，并对发生与发布成功与否相关的争议做好心理准备。

极少（理想情况是不会）由于出现不可接受的错误而必须取消发布（但请注意软件发布无需完全不出错；即使存在错误也可继续发布，前提是错误很小并在容错限度内）。如上所述，此 KPI 可与上一个 KPI 一起使用。此 KPI 越低而前一个越高，总体性能就越好。尽力区分已知错误（已确定其解决方案并查明其根本原因的错误）和造成意外事故的错误之间的差异，不管这些错误有多么微不足道。应通过“故障管理”流程管理造成意外事故的错误。始终要对由于不可接受的错误而造成的故障进行分析，同时对每个错误都作出报告，说明为确保在将来发布中不再重蹈覆辙而采取的任何应对措施。

• 业务取向指标 — 甚至在发布此 KPI 之前，所有已失败的发布的状态就很可能已经公布并经过了讨论。然而，这仍然不失为一种可与业务经理进行讨论的关键报告，业务经理能够提供有关意外错误对业务影响的详细信息。将此种报告视为用以促进工作而非分清责任的手段是很重要的。

极少出现结构性故障。利用此 KPI 进行测定之前，您应确定多少才是“极少”。是零？还是不超过 1%？理想的 KPI 目标为零，但是无论您确立的 KPI 是什么，都必须充分调查所有的结构性故障。上一个用以处理“意外错误”的 KPI 中所述的大多数标准在此同样适用。

• 业务取向指标 — 上一个与“意外错误”有关的 KPI 的讨论在此同样适用。

安全精密地管理 DSL（留存软件库）。与上述 KPI 相比，此 KPI 完全不同。无法通过基线数据对其进行测定，除非对 DSL 进行了研究、复查和审核。实际上，您只需进行审核、复查并将 DSL 中的软件发布与基础设施上安装的软件进行比较，即可确保 DSL 的精密管理。

复查安全性要困难得多。虽然如此，还是应该利用口令控制对 DSL 的所有访问。因此，好的出发点就是检查口令流量。安全性复查最好由独立的安全分析员而不是 IT 分析员来执行。通常在 IT 管理部门需要时才进行此种复查，而且其频率也不高。如果发现了安全问题或误差，那就必须立即采取措施，以便从发布管理中消除弱点并防止其再度出现。

• 业务取向指标 — 这完全取决于业务群体与 DSL 之间的关系。如果业务经理“拥有”DSL 中的任何软件，那就将其完全纳入复查范围内。此外，如果有必要对业务经理进行调查，以验证其软件版本号，那就一定要与其进行商讨。

DSL 中不存在未通过质量检查的软件以及对从 DSL 中提取的任何软件进行返工的迹象。与上一个 KPI 相同，还是无法通过基准数据对其进行测定。需要对 DSL 进行研究、复查和审核。只有通过审核、复查并将 DSL 中的软件与基础设施上安装的软件进行比较才能证明其质量和完整性。 审核复查最好由独立的分析员而非 DSL 的“维护人员”执行。在 IT 管理部门需要时才进行此种复查，而且其频率也不高。如果发现了任何质量或完整性问题，那就应该立即采取措施，以便以便从发布管理中消除弱点并防止其再度出现。

• 业务取向指标 — 这也完全取决于业务群体与 DSL 的关系。如果业务经理“拥有” DSL 中的任何软件，那就将其完全纳入复查范围内。此外，如果有必要对业务经理进行调查，以验证其软件版本号，那就一定要与其进行商讨。

DSL 大小符合空间要求，并及时而精密地管理 DSL。这一重要的 KPI 依赖于 ITIL “容量管理”流程获得信息和支持。通过对当前数据库占用的空间与升级当前软件所需的额外空间，以及打算添加的软件需要占用的空间进行加法运算，即可测定 DSL 的空间需求。然后，将此结果与 DSL 的可用空间大小进行比较。如果看起来不足以容纳新软件，那就必须采取措施以扩展 DSL 的空间，或删除 DSL 中的某些过时或冗余的软件。如果由于空间不足而无法添加软件，那就无法达到此 KPI。

应定期及时并精密地管理 DSL，而且必须将所有操作记录在事务处理日志中。此 KPI 涉及到 DSL 以及事务处理日志的审核。如果发现管理的疏漏或误差，那么这就表明尚未达到此 KPI。如果出现了时间安排或误差问题，那就必须立即采取措施，以便从发布管理中消除弱点并防止其再度出现。

• 业务取向指标 — 同样，这也完全取决于业务群体与 DSL 的关系。如果业务经理“拥有”DSL 中的任何软件，那就将其完全纳入检查范围内。此外，如果有必要对业务经理进行调查，以验证其软件版本号，那就一定要与其进行商讨。

符合与所购软件有关的所有正当限制。此 KPI 极为重要。如果不能达标，公司可能会遭到诉讼。此 KPI 通常与软件许可限制、软件更新以及软件的有效期限有关。您应详细列记所有软件的合同协议，同时进行核查和限定，以确保不会违法。在扩大现有软件的使用范围或升级现有软件时尤其要慎重行事。

• 业务取向指标 — 确保业务经理能够意识到那些尚未符合的法律限制，在业务经理已违反法则（可能是无意为之）时要尤其注意。例如：业务经理承诺只为将某软件安装在十个工作站支付许可费，但却有十个以上的员工常常同时使用该软件。在这种情况下，您应通知业务经理软件的使用是不合法的。此外，您可能还得通知某些非 IT 部门，如合同管理和采购等部门。

将发布准确地分发到远程站点。可通过审核对此 KPI 进行测定。然而，定期检查事故和故障数据库，以找到软件分发出错的证据却是更为常用的方法。此外，也要在变更管理中查看 RFC。您可能会发现由于软件分发不准确而请求变更的 RFC。例如，用户请求的是本应已安装完毕的升级或功能。如果发现发布的分发出错，那就表明尚未达到此 KPI。

• 业务取向指标 — 业务经理往往不会意识到应该将软件（版本/发布级别）在其部门内部进行安装。请确保业务经理在软件分发过程中能够随时得到通知。

在所有站点包括远程站点上准时实施发布。此 KPI 易于监视，因为发布不是准时的就是滞后的。滞后的发布表明尚未达到此 KPI 的标准。然而，应指出推迟发布的原因，并且应该采取行动以便防止将来重蹈覆辙。。您应定期（如每月）向所有 IT 管理部门提交一份“滞后发布”的报告，以便其进行检查和提出意见。

• 业务取向指标 — 业务经理将会希望得到一份“滞后发布”报告的副本。他们还很可能会在推迟发布时通知您，以便随时了解所有发布的进度。

不会在任何站点出现未经授权恢复使用以前版本的迹象。此 KPI 的测定需要进行审核和复查。您可能能够利用“搜索与查找”实用程序检测已降级的软件。除此之外，您可以在复查事故或故障数据库时找到已降级的软件。您还应在“变更管理”流程中复查 RFC，以了解用户是否因降级的软件而提出了变更请求。例如，用户请求的是本应已安装完毕的升级或功能。任何未授权的降级行为均表明尚未达到此 KPI。

• 业务取向指标 — 询问在业务经理的管辖范围内是否出现了故障。此外，可能还需要向安全官员或部门报告已发现的故障。

不会在任何站点出现使用未授权软件的迹象。此 KPI 的测定也需要进行审核和复查。首先要确定到底什么是“未授权的软件”，以及使用或执行未授权的软件会招致何种处罚。然后要确保所有 IT 和业务经理彻底理解了“未授权的软件”的定义以及相关处罚。您可以利用“搜索与查找”实用程序或通过复查事故或故障数据库检测未授权的软件。如果发现有人使用未授权的软件，那就表明尚未达到此 KPI。

• 业务取向指标 — 如果您在业务经理的管辖范围内发现有人正在使用未授权的软件，那就必须对其进行询问。未授权的软件在安装其他软件的新版本时可能会造成严重的问题。更重要的是，未授权的软件是病毒以及其他计算机软件入侵的潜在入口。因此，可能需要将使用未授权的软件的情况向安全部门或公司审计员报告。

不会出现为那些实际上未在任何特定地点使用过的软件支付许可费或进行维护。此 KPI 可视为一种“不错的管理手段”。需要拟定定期审核计划以确定人们使用各种软件所在的地点。这并不是指确定是否有人在使用软件，而是指确定使用该软件必要的许可数量。

例如，您的部门可能有 40 位员工，且所有人都已获许可在其工作站上安装同一软件。但由于部门政策有所变化，实际上只有十名员工有权使用该软件。通过减少许可数量并将软件从不再通过其使用该软件的工作站上删除可降低许可和维护开销。

您可以利用实用软件检测未使用的软件，也可以通过复查事故或故障数据库进行查找。此 KPI 与其他 KPI 略有不同，因为环境可能会发生变化，如上例所示。

• 业务取向指标 — 尽管可能能够利用技术手段确定软件使用情况（或未使用的情况），但业务经理对减少许可数量必须表示同意。因此，当发现未经许可使用软件的情况时，要在减少许可数量之前与相应的业务经理进行协商。此外，还应让业务经理每年对其员工获得的软件许可进行复查，并确定他们是否仍然需要所有许可。

在构建发布的过程中不会出现存在无用副本的迹象（例如，在一个版本的副本够用时，构建远程站点的多个版本）。这是一个更难以测定的 KPI，因为这需要进行发布工作的 IT 员工确定并报告无用的副本。有时，在安装发布之前出现副本的迹象并不明显。要鼓励员工报告任何出现副本的情况，以便能更加有效地进行将来的发布。当发布时间、实施开销都超出预期的限度时，也能发现无用的副本。

在此并不需要定期进行审核和复查，但应该在发布完成之后对其进行评估的过程中识别无用的副本。确定无用的副本之后，应采取措施改进“发布管理”流程以避免再度出现无用副本。只要存在无用的副本就表明未达到此 KPI。

• 业务取向指标 — 发布过程中最终用户参与程度越高，他们发现副本的可能性就越大。最终用户与业务经理都可以通过识别和报告任何无用的副本尽一份力。例如，最终用户和业务经理可能会发现总是有人要求他们一再做同样的事情。。在构建发布的过程中无论如何都必须通知业务经理有关任何副本的情况。

准确即时地在 CMDB（配置管理数据库）内记录所有构建、分发以及实施活动。首先，您必须定义并记载“准确性”及“适时性”的含义，否则将无法对此 KPI 进行测定。然后，确定识别故障的方式。对于“准确性”，配置管理团队负责审核 CMDB，并且应该报告在 CMDB 中由发布管理导致的错误所造成的误差。 “适时性”的测定则更加困难。适时性与 CMDB 对象由于发布而改变后对其进行更新所需的时间有关。通过对 CMDB 进行审核可发现某些适时性故障。其他适时性故障则可以通过复查故障和故障数据库或从服务台中发现。例如，服务台正在处理事故，但由于发布管理未及时更新 CMDB 而导致 CMDB 与客户位置的实际配置仍然是相同的。

ITIL 规定准确的 CMDB 是 IT 服务管理的重要组成部分。达不到此 KPI 将会造成严重的后果，因此必须采取措施以维护 CMDB 的准确性。

• 业务取向指标 — 将 CMDB 中存在误差的情况通知给业务经理，尤其是那些使用 CMDB 的业务经理，如财务管理部门、合同管理部门以及采购部门。此外，您还应通知业务经理让他们不要使用不准确的 CMDB，因为他们可能会受到由不准确或过时的 CMDB（如指定给事故的错误的优先级）导致的低劣服务的影响。请与业务经理商讨以确定谁需要有关 CMDB 误差的反馈。

对所有发布活动、所有已采取的必要的纠正措施或后续操作以及任何流程改进进行检查。此 KPI 的表述不是很清楚。是事后检查还是所有事后检查的结果反映出未出现发布问题？毫无疑问，应对每次发布进行事后检查。如果无法进行事后检查，那就至少应对所有出现故障或失败的发布进行事后检查。如果没作出事后检查报告，那就表明未达到 KPI。此外，还应进行核查以确保所有必要的纠正措施和后续操作以及任何流程改进工作都已正确执行。如果没有进行核查，那就表明未达到 KPI。通过事后检查还可为本节所述的许多其他 KPI 提供数据。

• 业务取向指标 — 业务经理不必查看所有事后检查的结果。但必须向业务经理发送事后检查报告的副本，从中可看出安装在其业务范围内的版本的问题。

拟定的发布组成与实际的组成一致（这证明发布的计划工作良好）。理想状态下，所作的计划应该是极其周密的，以确保拟定的发布组成与实际组成一致。然而，往往会出现一些意外情况，而正是从这些异常情况中我们可以学会如何改进计划工作。这就是即使没有提及实施改进计划工作的策略这也是一个重要的 KPI 的原因。所有发布都结束后，需要确定拟定的组成是否与实际的发布组成相一致。可在事后检查的过程中查明组成的一致性。如果拟定的发布组成与实际组成不符，那就表明未达到此 KPI。

• 业务取向指标 — 如果变更顾问委员会 (CAB) 包括业务经理，他们将会对此 KPI 感兴趣，尤其是在出现不一致的时候。任何业务经理都会关注在其管辖范围内遇到的与拟定组成不一致的组成部分。

“发布管理”所需的 IT 和人力资源应符合正在实施的合理促进计划的要求。这又是一个“计划”KPI，其目的在于确保“发布管理”流程中所需的全部资源都已到位。因为很难判断 KPI 的“好坏”，所以您可能需要制定一个标准，如在缺少资源时最多推迟 5% 的发布。无论制定了何种度量标准，未能达标都表明达不到该 KPI。

切记在计划中进行评估是过犹不及的。例如，如果您估计完成某项任务需要 100 个小时，而实际上只花了 25 个小时，这可能会导致需要该员工做其他工作时遭到不必要的拒绝。您应在每次发布的整个生命周期内对其进行严密监视，并尽快向 IT 管理人员汇报资源问题。可在每次发布结束时对计划进行评估，以复查打算使用的资源与实际所用资源的对比情况。这是一个关键的 KPI，因为发布延迟的常见原因就在于资源规划不完善。必须解释清楚所有资源缺乏的情况，并采取措施以确保将来的发布计划工作会得到改善。

• 业务取向指标 — 业务经理通常会关注由不当的资源规划导致推迟其发布的情况，但他们通常对可用以促进其发布实施的计划漠不关心。因为大多数业务经理都完全了解资源规划，所以要为其将要提出的大量问题做好准备。此外，还要为其将要提出的对较早完成的项目的疑问做好准备。依此类推，当有迹象表明新高速公路比预定计划早九个月开放时，您的第一反应是“计划工作做的好”还是“公路建设承包商营私舞弊”？无论情况如何，您都必须向业务经理提供所有资源差异的细节。

与这些 KPI 相关的主题有两个：审核与事后检查。两者都是确保周期性持续改进发布管理的重要活动。不过，进行这两种活动时要慎重行事。如果您利用审核或事后检查评价员工或其行为，那么这些工具将很快失去其效力。最后一点 — 这种情况下的“审核”是用来查看准确性与适时性，而不是用来进行业务或法律审计。（许可管理是一个例外。）

现在我们来讨论管理信息度量标准。这些度量标准主要与发布管理的总体性能有关。ITIL 推荐的管理信息度量标准如下：

• 每个报告周期内的主要和次要发布数。
• 在现场由新发布造成的故障数，只需在新发布的前几个月对这些故障进行测定，这些故障是按根本原因（例如“错误的文件版本”或“缺少文件”）分类的。
• 在新发布中推出的新的、已经改动以及删除的对象数，例如，模块数与程序数。
• 在约定的时限内完成的发布数；这需要利用核心发布管理功能为软件分发及其他常规任务预定条款（服务级别或 SLA）。

在讨论了大量的 KPI 之后，仅发现少数度量标准可用于管理报告并不奇怪：

每个报告周期内的主要和次要发布数。不幸的是，利用此度量标准无法为我们提供大量有关报告内容的详细信息。内容是在报告期间完成的发布吗？内容是在报告期间开始进行的发布吗？内容是在建的发布吗？或此种报告含有上述各种信息？理想状态下，定期报告中应包括上述全部内容。该报告可按状态分为三个部分：已完成的、已开始的和当前的（在建）。每一部分又可分为两部分：主要和次要。应将此种报告提交给所有 IT 管理人员，因为这使得 IT 管理人员能够跟踪与其或其职员有关的所有发布。

• 业务取向指标 — 这是一份对业务经理很重要的报告，业务经理可以利用该报告跟踪影响其业务的发布。提交此种报告将减少业务经理提出与其发布状态有关的问题的数量。所有其发布被推迟的业务经理都会提出问题。

在现场由新发布造成的故障数，只需在新发布的前几个月对这些故障进行测定，这些故障是按根本原因（例如“错误的文件版本”或“缺少文件”）分类的。此度量标准非常明确，并可将其扩展以涵盖用户所报告的归咎于新发布的所有新事故。理想状态下，不应再发生任何新故障或事故。但实际上仍会发生许多故障或事故，即使对于成功发布，情况亦是如此。无限接近理想状态的唯一方法就是调查所有新故障和事故，然后采取适当措施以避免其在将来的发布中再度出现。该度量标准建议将“根本原因”作为故障的分类依据。同样，“种类”则可用于事故的分类。应按其中出现故障和事故的发布查找所有与其相应的故障和事故，如按发布索引号进行查找。最后，应纠正发现的所有故障和事故，以避免其在将来的发布中再度出现。应定期作出此种报告并将其提交给所有 IT 管理人员。

• 业务分配指标 — 对于所有业务经理而言，这是一份“必读”的报告。他们需要了解所有因发布而产生的故障或事故。毕竟业务经理很可能最后才能知道所发生的故障。他们也将会关注正在采取的用以避免同样的故障和事故在以后再度出现的任何纠正措施。

在新发布中推出的新的、已经改动以及删除的对象数 — 例如，模块数与程序数。此度量标准只是一个按一系列分步种类划分的数量指标。因为利用新的、已经改动或删除的对象无法获取有关影响或工作量的数据，所以其用处不大。不过，通过与 KPI 和其他管理信息一起使用，此度量标准可用以测定特定时段内的活动量。列出编号的对象效果会更好。应将此种报告提交给所有 IT 管理人员。

• 业务取向指标 — 大多数业务经理都不太在意此种报告，但某些特殊的业务经理却会关注，如那些在业务开发部门、合同管理部门、采购部门以及作为变更顾问委员会 (CAB) 成员的的业务经理。您应确定哪些业务经理需要查看此种报告并对其提交报告。

在约定的时限内完成的发布数；这需要利用核心发布管理功能为软件分发及其他常规任务预定条款（服务级别或 SLA）。起初可能很难区分此管理度量标准与本节第一个说明了“按计划构建并实施的发布”的 KPI。事实上，看来从失败的发布中得到的教训可能比从成功的发布中得到的要多。经过仔细检查后，可以发现正是引入了 SLA 才使得此度量标准不同于第一个 KPI。例如，您可以在 SLA 中制定条款，规定 95％ 的发布必须在约定的时限内得以实施。这样一来，此种报告就会变得重要起来，因为此种报告可反映发布管理的总体性能。总之，要树立实施成功发布的目标、确定报告周期，然后将此报告提交给所有 IT 管理人员。

• 业务取向指标 — 如果在已签定的 SLA 中有用以限定成功并及时实施的发布的条款，那就必须将此种报告提交给所有业务经理，或至少将其提交给那些已签定了 SLA 的业务经理。

现在我们已经讨论了很多用以进行发布管理的 KPI 和管理信息的度量标准。您可能会感到在每个报告周期内都要作出所有这些种类的报告很困难或很费时。但要想到 ITIL 只是一个框架。您可以选择那些对自己公司最具意义的 KPI 和度量标准并只针对它们进行报告。最后，切记 IT 的成功取决于有效的变更管理和发布管理，所以不要忽视度量标准的作用，并且要不断地寻求新的方式以改进变更管理和发布管理工作。

> > 第 9 章 - 配置管理