返回本章节索引       阅读下一章

1问题管理

1.1问题管理的目标

问题管理的目标是最小化事故的不利影响以及由于IT基础设施中的错误造成的业务上的问题，阻止与这些错误相关的事故的重复发生。为了达到这个目标，问题管理寻求找到事故的根本原因，采取行动改善或纠正这种状况。

问题管理流程具有主动和被动两个方面。被动的问题管理关注于解决问题以响应一个或多个事故。主动问题管理关注于在事故首次出现前就能识别和解决问题以及知名错误。

1.2问题管理的范围

问题控制、错误控制以及主动问题管理都属于问题管理流程的范围。较为正式的定义是，问题是一个或多个事故未知的底层原因，知名错误是已经成功诊断出来的问题，并且为之定义了临时措施。

问题管理流程的输入是：

1. 来自事故管理的事故详细信息
2. 来自配置管理数据库的详细配置信息
3. 任何定义的临时措施（来自事故管理）

问题管理的主要活动包括：

1. 问题控制
2. 错误控制
3. 问题的主动预防
4. 识别问题趋势
5. 从问题管理数据中获得管理信息
6. 完成主要问题的评估

问题管理流程的输出：

1. 知名错误
2. 变更请求（RFC）
3. 更新后的问题记录（包括解决方案和/或任何可用的临时措施）
4. 关闭问题记录（对于解决的问题）
5. 与问题和知名错误匹配的事故的响应
6. 管理信息

1.3基本概念

在事故的早期阶段，能够得到相应的而且容易应用的建议，对于组织有效地解决事故的能力来说，这是最重要的。服务台接收到的事故，对于支持员工很少是初见的或是神秘的。相似地，处于二线或三线的支持员工中的专家也已经解决了许多困难和原始事故和问题。花费在这些解决方案上的资源的最好使用方式就是将它制作成文档，这样一线的员工就可以应用它们了。

问题管理流程试图降低影响业务的事故和问题的数量及危害，因此，问题管理的部分职责是确保以前的信息被记录在档，这样对一线及其它二线支持员工就已经是准备好可用的了。它不是简单地记录文档的问题，它要求：

1. 信息应该建立索引，以便根据来自新事故的简单的线索就能容易地查找；
2. 进行例行检查，以确保持续的文档记录与变更相一致：
   • 技术
   • 可用的外部解决方案
   • 业务实践和需求
   • 内部技巧
   • 重复事故的频度和影响
   • 阐明内部最佳实践
3. 进行详细评估的流程；
4. 训练员工使用信息，理解可用信息的深度和作用，以及怎样访问和理解信息，在提供反馈方面，信息的相关性和易于使用；
5. 存贮信息的知识库－典型地基于集成的服务管理工具，使得在登录后或者在事故处理流程的初始分析阶段就能使用知识。

一般地使用“专家系统”软件来发挥问题管理流程的作用。然而，重要的是包括专家知识，让使用系统的员工根据反馈来更新：

1. 被识别的问题和知名错误；
2. 分析他们遇到的事故（被动问题管理）；
3. 按时间段分析事故（主动问题管理）；
4. 分析IT基础架构；
5. 提供知识库；
6. 引进新产品时的开发人员和提供商。

一般情况下，问题是多个展现出共同特征的事故的结果。有时问题也可以根据单个明显的事故来识别，由单个错误引起，虽然原因未知，但影响明显。

知名错误是对问题的根本原因成功诊断后识别的，后续将开发一个临时措施。

IT基础架构的结构化分析、来自支持软件的报告以及用户组会议有助于问题和知名错误的识别。这就是主动问题管理。

问题控制重点在于将问题转化为知名错误，错误控制重点在于通过变更管理流程结构化地解决知名错误。

1.3.1事故管理和问题管理的不同

问题管理不同于事故管理，它的主要目标是事故底层原因的检测，提供后续的解决方案，阻止事故的发生。在许多情况下，这个目标可能与事故管理的目标有直接的冲突，因为事故管理的目标是尽可能快的为客户恢复服务，经常通过临时措施，而不是通过彻底地解决。因此在这个方面，找到解决方案的速度是次要的。底层问题的调查需要花费时间，这样会推迟服务的恢复，但阻止了事故的重复发生。

1.3.2问题控制

问题控制流程关注于以有效地方式处理问题。问题控制的目标是识别根本原因，诸如存在错误的配置项，向服务台提供可用的关于临时措施的信息和建议。

问题控制流程很相似于，且高度依赖于事故控制流程的质量。事故控制重点在于解决事故，提供临时措施，对特定的事故临时修复。如果对于一个或一组事故，识别出了问题，可用的临时措施和临时修复应该由问题控制流程记录在问题记录中。问题控制流程也对问题建议最佳的可用临时措施。

因为问题控制关注于阻止事故的重复发生，因此流程的方法应该被仔细地管理和规划。管理和规划的程度要高于事故控制，因为它的目标只是尽快地恢复正常的服务。优先权应该分配组那些可能引起严重业务中断的问题的解决。

在事故控制中的活动包括：

1. 问题识别和记录；
2. 问题分类；
3. 问题调查和诊断；

1.3.3错误控制

错误控制包括的流程是，在变更管理流程的控制下，能过成功地实施变更，使知名错误得以消除。错误控制的目标是发现错误、监控错误、在成本合理且可行的时候排除错误。

错误控制是开发（包括应用开发、功能扩展和维护）和生产环境的桥梁。在开发阶段产生的软件错误会影响生产运营，在开发和维护环境识别的知名错误会被移交到生产环境。

错误控制中的活动包括：

1. 错误鉴定和记录；
2. 错误评估；
3. 记录错误的解决（方案调查、提出变更请求）；
4. 关闭错误；
5. 监控问题和错误的解决进展。

在实践中，问题管理的每个流程要求仔细的管理和控制，不同的操作对象应用在不同的流程中。

1.3.4主动问题管理

主动问题管理中各项活动的目的是，在事故发生前识别和解决问题。这些活动有：

趋势分析；

定位支持行动；

向组织提供信息；

通过将IT部门的作用从被动地解决大量事故，重定位到阻止事故，它将向客户提供更好的服务，使得IT支持部门的资源得到更有效地利用。

1.3.5主要问题评价

通过对主要问题进行事后的评价，有助于服务的提升。

1.4问题管理的益处

采取正式的方法进行问题管理带来以下益处：

• 提升IT服务质量

问题管理有助于形成迅速提高IT服务质量良性循环。高质量可靠的服务有益于IT的业务用户、有益于生产力的提高、有益于IT服务提供者的士气。

• 事故数量下降

问题管理是降低造成业务中断的事故数量的利器。

• 永久的解决方案

随着问题和知名错误被解决，它们的数量及影响会逐步减少。

• 提高了组织的知识

问题管理流程基础于从过去的经验获得知识的概念。这些流程提供了历史数据来识别趋势，阻止错误的出现，降低错误的影响，从而提高了用户生产力。

• 提高服务台第一时间修复率

在客户打进电话时，服务台通过存贮在知识库中事故解决方案和临时措施，在第一时间在服务台解决事故。

相反地，没有实施问题管理流程的成本可能包括：

1. 一个纯粹的被动支持的组织，只有在客户的服务被中断时才面对问题；
2. 面对重复发生的事故，IT用户部门会对IT支持部门的服务质量失去信任；
3. 因为相似的事故不得不反复地被解决，而没有提供结构化的解决方案，所以成为一个高成本、缺乏员工积极性、无效率的支持部门。

1.5规划与实施

1.5.1时机和规划

时机和规划是很重要的，因为：

1. 良好的问题管理在很程度上依赖已经实施且有效的事故管理流程。因此，与事故管理流程并行或在它之后实施问题管理是明智的；
2. 如果缺乏资源，建议首先实施问题和错误控制（被动问题管理）。当这些活动成熟时，资源可以直接转向主动问题管理。主动问题管理的质量非常依赖成功地实施了服务监控活动以及因此获得的基础数据；
3. 较小规模的组织通过聚集于日常的“前十名”事故实现被动问题管理。这被证明有有效的，因为经验表明20%的问题引起了80%的服务降低。

1.5.2关键成功因素

考虑要点包括：

1. 有效的事故自动登记、有效的事故分类，是问题管理成功的基础；
2. 设置可完成的目标，利用既有员工解决问题的才能是个关键的活动。考虑“兼职”问题管理，让员工看到随着问题的解决，他们远离每天“救火”的压力；
3. 考虑事故管理和问题管理间潜在的冲突，在两个流程间进行良好的协调是必要的。同时两者又都有可能彼此帮助的配合。参与两个流程的支持职员应该意识到平衡两者的活动的重要性；

1.5.3风险

问题管理的益处会被以下因素减弱：

1. 没有良好的事故控制流程，这样就缺乏关于事故的详细信息（这对正确的问题识别是必要的）；
2. 不能够将事故记录与问题/错误记录连接起来，意味着失去了许多潜在的益处。在从被动支持向更有规划和主动支持转移方面，这是关键的功能；
3. 缺乏管理，因此支持职员（通常也参与在被事故控制流动中）不能分配充分的时间在结构化的问题解决活动中；
4. 削弱服务台的角色。问题管理职员应该仅从授权的发起者那里接受支持请求。如果流程处理来自许多发起者的请求就会出现困难，因为相同原因的多个事故报告可能会被以不同的方式来解释；
5. 不能留出时间来建立和维护知识库将限制问题管理的益处；
6. 没有能力准确地判断事故和问题的业务影响，导致对业务而言关键的事故和问题没有给予正确的优先级。

1.6问题控制的活动

实际上，由于计算机设备和通信线路的偶然出错，发生事故是不可避免的。许多其它事故不是由随机产生的故障引起的，而是由组织日益复杂的IT基础架构某处错误造成的。即使可预料的计算或通信设备故障也会由于提供商的产品中的错误，导致无法接受的影响。

被动问题控制关注于识别事故真正的底层原因，以阻止将来的重复发生。在问题控制流程中有三个阶段：

1. 问题的识别和记录；
2. 问题的分类－根据对业务的影响；
3. 问题的调查和诊断。

当检测到根本原因时，就开始错误控制流程。

1.6.1问题识别和记录

问题识别发生在：

1. 在事故的初始支持和分类阶段，不能够找到匹配的既有问题和知名错误；
2. 事故数据的分析揭示了重复发生的事故；
3. 事故数据的分析揭示了还存在没有与能够与既有的问题和知名错误匹配的事故；
4. IT基础架构的分析表明存在可能导致事故的问题；
5. 重大或明显的事故（对客户的服务具有严重的不利影响）发生，需要找到结构化的解决方案。

注意有些问题可能在问题管理小组之外被某个识别，如在能力管理中。无论如何，所有的问题应该通知问题管理流程被记录。可用性管理流程的许多方面关注于IT基础架构中的问题和事故的检测和避免，这两个领域的配合对提高服务质量具有重大的价值。

• 要点

问题管理要求效力和资源，因此是昂贵的。组织要能够判定对某些类型的未能匹配的事故付出努力和成本是划算的－例如能够快速解决，影响较小或重复发生的可能性很小的事故。在这种情况下，可以在CMDB中引入虚构的问题记录，关联到所有有联系的事故、知名错误、变更请求以及配置项。

问题记录需要记录在数据库（理想情况下是CMDB），这一点类似于事故记录。它们通常不包括某些不适用的标准事故数据（如用户数据）。然而问题记录应该连接到所有相关的事故记录。事故的解决方案和临时措施应该被记录在相关的问题记录中，以便另外相关的事故发生时能够访问。

问题识别的流程如上图所示，包括基本的问题分类。受影响的配置项的数据应该准确地追加到这个基本分类数据中。理想情况下，这些配置可被单独修改的最低层的项目－例如，应用代码块或硬件组件。然而在问题识别阶段对于有问题的配置项的识别达到这个层次经常是不可能的。

1.6.2问题的分级

当问题被识别时，需要较大的努力来检测和恢复断定存在故障的配置项。因此意识到问题对既有服务水平的影响是很重要的。这个流程被称为“分级”（classification）。在实践中，支持努力被分配到连接到单个事故的小面积的问题上。

问题分级的步骤类似于事故分级的步骤，这些步骤决定：

1. 类别
2. 影响
3. 紧急程度
4. 优先级

问题被归类到相关的组或域（例如硬件、软件、支持软件以及相应的其它种类）。这些组能够与机构的职责匹配，或者以用户和客户为基础归类，是将问题分配给支持职员的基础。附录A给出一个简单但对问题归类有效的结构。

新问题的识别应该在受其影响的对象（也就是它对业务的影响）分析之后。登记在CMDB中的IT基础架构中的组件间的关系有助于判断问题的影响。

组织应该根据它们的业务需要设计自己的影响代码系统。影响代码对于有效地分配支持力度是最有用的机制。更进一步包括优先级、从属影响，提供了全面的控制机制。

当判断问题的影响时，登记在CMDB中的IT基础架构中组件间的关系是个极大的帮助。通过查询CMDB，可能识别事故涉及到IT基础架构中的配置项，以及同样的或依赖的配置项。

紧急程度是指问题或错误的解决所能承受的延迟程度，它不应该与优先级混淆。优先级指明一系列项目－无论是事故、问题、变更或错误－应该被解决的相应次序。这会受到风险的考虑和资源可用性的影响，但更主要地是由紧急程度和影响的组合来决定。尽管较低的业务影响，但要求紧急解决的事情经常要放在较高的潜在业务影响但较低的紧急程度的事情之前处理。

为每个方面分配数字值有帮助的，由此衍生出数字优先级，但是，对于所有的服务管理，这样的数字是凭人的直觉和业务意识来修改的。然而，对每个问题的紧急程度和影响赋予1－4的数值，对它们求和给出相应的优先级，是一个简单而实用的起点。那样做了，组织应该精密地监控和检查计算出的优先级，监控对应需求的功能。影响紧急程度的方面如：

1. 临时修复的可用性；
2. 存在临时措施；
3. 计划推迟解决的可能性；
4. 对业务未来影响的意识，如支持月末处理的设备需求。

每个事故、问题和变更将都会对业务服务和紧急程度有影响：

1. 影响－描述了业务受到破坏的可能；
2. 紧急程度－表明了可用来转移或降低影响的时间。

• 要点

在最早的时机为所有问题分配影响代码。当这项工作完成后，重要的是在详细调查开始前，使所有问题归属到被管理的职员分配流程。被分配的人负责问题的解决，成为协调问题解决活动的中心。根据影响计划工作量，重要问题要立即引起注意。对低影响的问题可以允许超出特定的时间限制。

影响分析流程遭遇一个重大的约束：它只反映当时的看法。虽然一个问题被正确地分配了低影响代码，但接下来属于该问题的事故数量陡然上升可能要求这个问题需要立即引起注意。需要设置事故限制来解决这个困难。如图3所示，问题管理流程被设计要维护与问题（和知名错误）记录匹配的事故的数量。问题和错误控制系统周期性扫描这个数值，将它与预先定义的限制值比较。当数量等于或超出这个限制，这样的问题/知名错误应该被升级到立即注意。然而，注意数量并不总是等于重要：当你发现订单不能输入超过$999,999.99的值，即使这样的情况只有0.5%，也必须被看做是关键的问题。

1.6.3问题调查和诊断

问题调查流程类似于事故调查流程－但是这两个流程的基本目标明显不同。事故管理的目的是迅速恢复服务，而问题管理的目的是诊断出底层原因。调查活动应该包括与该问题相关事故可用的临时措施，它登记在事故记录数据库。问题管理活动还包括更改问题记录中推荐的临时措施，以支持事故控制。

诊断结果经常表明问题的原因不是登记的配置项（硬件、软件、文档或程序）的错误，而是过程上的。例如，发布的程序版本不正确。这种情况下，问题以适当的分类代码来关闭，但不会达到有知名错误的状态。为了确保这类问题有章可循，采取措施解决它们，考虑为这种过失过程创建虚构的配置项，作为一个知名错误重新分级问题，或产生变更请求。

诊断揭示了原因是登记的配置项的错误，这时应该自动将问题的状态转成知名错误，由错误控制系统和过程接管。

正如前面所指出的，问题调查的目标经常会与事故解决的目标相冲突。例如，问题调查可能要求详细的诊断数据，这些数据只有在事故出现时才能得到，而获得这些数据可能会明显地推迟正常服务的恢复。确保将事故控制与计算机操作或网络控制功能紧密联系，对于此类的活动给予适当的时间平衡。

1.6.4问题分析的方法

一些文献对于结构化问题分析和诊断提供了许多方法。这样的文献有：

1. Kepner and Tregoe (参见附录B) 
2. Ishikawa diagrams (参见附录C)
3. 头脑风暴会话
4. 流程图方法 

问题管理应该选择最适合本组织目的的方法。

1.6.5问题控制的要点

以下是在问题控制中值得记住的要点：

1. 事故分类是向问题定义发展的第一步，因此问题管理应该与事故管理紧密关联，考虑建立公用的事故和问题分类。对于报告的事故以及最终检测的原因应该给予适当的分类，事故分类应该用“客户术语”，而检测的原因归类用“IT术语”来表达。
2. 如果可能的话，建立具有不同经验的人的小组，例如问题管理，在调查的时候，大家尽可能从不同的角度来参与。
3. 为了参与的支持专家能够有效地执行他们的任务，确保他们有合适的工具和诊断协助工具。
4. 如果问题不是由系统组件中的错误引起的，而是由于没有对用户培训引起的，解决并关闭问题记录。另外，创建新的配置项记录－在这个例子中是“培训问题”－按照通常的方法将问题转化为知名错误。确保检测的原因反映实际状况，例如，缺乏用户知识培训。
5. 在事故或问题控制流程的诊断过程中，要求IT基础架构中的所有产品的文档可用，以支持职员在处理过程中作为参考。这些文档包括：
   • 应用系统
   • 系统软件
   • 内部工具程序
   • 网络硬件和软件
   • 全局配置/网络图表
6. 除了产品信息，具有有效的过程来收集诊断以解决问题也是必要的。支持职员熟悉这些过程特别重要，因为在事故处理的过程中不适当的使用会推迟正常IT服务的恢复。因此需要这些过程来支持和加强流程的需求－这些过程可能包括适当的培训、认证等。
7. 支持专家会经常同时参与事故管理流程和问题管理流程，切记这两个流程的目标不同（快速解决对结构化解决），在这两个流程中，将专家的时间按固定的百分比分配证明是有用的，可能是事故管理占80%，问题管理占20%。这可以防止支持专家完全陷入被动事故管理。
8. 在事故和问题的诊断过程中，问题管理职员也要求精确地记录最近的变更，因为这些可能是问题的原因。

1.7错误控制的活动

错误控制包括了成功地纠正知名错误的流程。其目标是变更IT组件，消除影响IT基础架构中知名错误，防止事故的重复发生。

许多IT部门关注于生产环境和开发环境的错误控制，它直接与变更管理流程接口。图4示例了错误控制的三个阶段。监控和跟踪阶段包括全部的问题/错误生命周期。

1.7.1错误识别和记录

当有故障的配置项（引起或可能引起事故的配置项）被检测到就识别了错误。当问题的根本原因被发现就被赋予知名错误的状态，同时开发临时措施。

流入错误控制系统的知名错误有两个来源，一个是生产系统中的问题控制子系统，另一个是相应的开发环境。在生产操作中发现的错误，就如在问题控制活动调查和诊断中所描述的，被识别和记录。在这种情况下，问题记录形成了知名错误记录的基础（事实上，它确实只是状态的改变）。

知名错误的第二来源是开发活动。例如，新应用或打包发布的实施可能包括了在开发阶段形成的已知但未解决的错误。当应用或发布包实施时，来自于开发的知名错误相关的数据应该对生产环境的管理人员可用。

许多IT部门参与过这样一系列事件。问题管理系统应该记录所有解决活动，向支持职员提供监控与跟踪工具。也应该提供全面的审计记录，从事故到问题、到知名错误、到变更请求或重大变更实施。

1.7.2错误评估

问题管理职员协同专业职员，对解决错误的方法进行初始的评估。如果必要，接下他们根据变更管理过程，完成变更请求。变更请求的优先组根据错误在业务上的紧急程度和影响来决定。变更请求的标识符应该被包括在知名错误记录中，以便维护一个完全的审计路径，或者将两者连接。

错误解决的最终进程－影响分析、需要执行的解决步骤的详细评估、配置项错误的改正、变更的测试－要在变更管理的控制下执行。在极端情况下，紧急的解决方案，进行授权执行是必要的。

• 第三方产品中的错误

卖方维护的产品中的问题可能被问题管理或专家支持小组识别，应该向卖方支持的负责人报告。应该监控卖方支持，确保在合理的时间内收到对问题报告的响应。

在设置了软件维护的目标－诸如修复的合理和最长时间，以及IT基础架构相关的可靠性和可服务性－应该在合同或许可条件中明确，应该由第三方发起补救措施，以免受到抱怨。当购买软件时，特别是在业务上具有竞争的情况下，明确维护目标的可能性应该具备。注意解决软件错误的必要的变更归属于变更管理，与内部产品一样。

• 软件环境中的错误控制

在生产环境和开发环境中的问题和错误控制流程在本质上是一样的。前面对生产环境中的问题管理所描述的支持工具，也适合于开发环境中所要求的。图5显示了在生产和开发环境中的错误控制间的循环关系。协同集成的问题管理系统促进这种情况的处理。

在生产运营期间发现的错误导致变更求的积累，发布策略（参见发布管理）允许最终创建一个发布协同授权的变更修正系统中的错误。开发职员应该注意与打包发布相关的所有知名错误和问题，当知名错误被改正后要求被删除，加入到修订的错误数据库（或CMDB）。

当完成新的发布，这个修订的错误数据库替换以前版本的数据库作生产版本。当新的错误在生产运营中被发现，重复这个周期。

1.7.3记录错误解决方案

每个知名错误的解决过程应该记录在问题管理系统。与所有知名错误相关的配置项数据、症状、解决方案或防止措施保存在知名错误数据库是很关键的。这些数据对于事故匹配、在将来的诊断解决事故以及防止事故方面提供指导、提供管理信息等方面都是有用的。

1.7.4关闭错误

在成功地实施变更解决错误后，相应的知名错误记录被关闭，同时任何相关的事故或问题记录也一起被关闭。可以考虑在事故、知名错误和问题记录中插入一个中间状态“关闭但未进行实施后评价（Closed pending PIR）”，确保修正已经实际起作用。实施后评价（Post-Implementation Review,PIR）能确认最终关闭前解决的效果。

对于事故，除了打电话给用户确保他们已经满意就没有别的了，对于严重的问题和知名错误，要求进行正式的评价。

1.7.5监控问题/错误的解决

变更管理负责处理变更请求，同时错误控制负责监控解决知名错误的进展。在整个的解决过程中，问题管理应该从解决问题和错误的变更管理进展中获得日常报告。

问题管理应该监控问题和知名错误对用户服务的持续影响。在影响变得严重的事件中，问题管理应该升级问题，可能要咨询变更咨询委员会提升变更请求的优先级，在适当的时候实施紧急变更。

问题解决的进展应该结合SLA一起被监控。典型地，SLA规定在每个测量间隔内（一般为四周）在每个严重级别上不应该有特定数量的突出错误。如果在某个严重级别上问题或错误的数量达到预先定义的限制，可能引起与SLA的不一致，就必须升级。

1.7.6错误控制的要点

在错误控制中切记以下要点：

1. 不是所有的知名错误需要被解决。组织能够决定允许保留知名错误－例如，因为解决的成本太高、技术上不可能或要求太多的时间来解决。实践中，错误控制关注于选择合理的投资来解决问题；
2. 准备变更请求是错误控制的责任之一。解决方法经常是技术上的调整，但不要忘记，变更请求也可能需要包括对过程、工作方法和/或组织结构的修正；
3. 对于日常的硬件故障，考虑根据特定的设备或设备分类创建标准的错误记录。使用这些来维持对故障鉴定的快速指导－尽管多数信息（例如故障和宕机间的平均时间）来自于事故数据；
4. 许多硬件故障的纠正在事故控制下执行，并不通过错误控制和变更管理。然而对硬件规格的任何改变应该从属于正常的变更管理过程；
5. 理想情况下，应该在生产和开发环境中的事故、问题和错误控制中使用公用工具。如果因为在开发环境使用特定的CASE工具而使这不可能，那么设计和开发一个可行的转移机制是必要的；
6. In practice, the level of detail usually required for development Configuration Management often precludes a viable shared system. The key thing is to share the data, especially in terms of passing to the live environment information on Problems, Known Errors and ongoing Changes that are being handed over with any new or changed software.

1.8主动问题管理

迄今为止在问题和错误控制中所描述的活动主要是被动的。主动问题管理活动涉及到在事故出现前识别和解决问题和知名错误，这样最小化对服务的不利影响，最小化业务相关的成本。

问题防止的范围从单个问题的防止到策略的决定。后者可能要求较大的开销来实施，例如投资优化网络。问题防止也包括向客户提供信息以消除将来请求帮助的需求。问题分析集中在为问题解决人员提供改进的建议，例如，在线技术工具的提供减少了解决问题花费的时间，因此使电话时间的长度明显减短。

主动问题管理流程中的主要活动是趋势分析和定位防止措施。

1.8.1趋势分析

事故和问题的分析报告为采取主动措施提高服务质量提供信息。其目标是识别IT基础架构中“脆弱”的组件，调查其脆弱的原因－在这里“脆弱”是相对于如果配置项出错对业务的影响而言的。

事故和问题分析能够识别：

1. 趋势，诸如特定问题类型变更后出现的情况；
2. 特定类型的初期故障；
3. 特定类型或某个配置项重复出现的问题；
4. 客户对培训的需求或对更好文档的需求；

事故和问题的分类，以及积极的分析可以揭露趋势，识别出需要进一步调查的特定（或潜在）的问题区域。例如，分析可能指出与最近安装的客户－服务器系统相关的事故是个问题区域，对客户业务的负面影响增长最快。

分析－例如对来自系统管理工具的事件的分析，对文献的分析，对来自用户组的讨论和反馈的分析－也能够揭示可能的问题，需要进一步的调查。组织与重要客户的讨论会或进行客户调查也能识别趋势和（潜在的）问题区域。

问题管理数据的分析可以揭示：

1. 在一个平台出现的问题可能在另一个平台出现－例如，在一个中型系统上的网络软件的问题也可以是主机系统上的明显的问题；
2. 存在重复出现的问题－例如，如果因为同样的故障，三个路由器被连续替换，它可能表明这种路由器类型不合适，应该用另一种类型替换，或者当or when a software application is involved then complete redevelopment might be necessary which would be classed as a major Change.

1.8.2定位防止措施

趋势分析能够识别IT基础架构中的故障，接下来正如在问题和错误控制中所描述的能够被分析和纠正。趋势分析也能够识别需要支持人员注意的问题区域。按照组织的财务成本来表达，可以做出有意义的比较。

为了将不足的资源最有效地用于服务支持（从中获得最大的业务利益），调查哪个问题区域最需要支持人员注意是值得的。对于主动问题管理，这是个典型的任务。为了能够估计特定问题区域的事故对业务的影响，事实证明引入事故的“pain factor”这个概念作为衡量是很有用的。使用这个概念，对每个事故分类给予一个pain value作为公式的基础，用于记帐，例如：

1. 事故的数量
2. 受影响的客户数量
3. 解决事故的持续时间和相关的成本
4. 业务成本－这可能是所有因素中最重要的

这个方法避免将精力集中放在这样一组事故上，相对而言数量较大，而对提供的服务水平没有较高的影响；相反地，将精力放在调查一小组而更有益的事故上，它可能对组织的业务有很高的影响。

在需要注意的问题区域被识别后，问题管理应该启动适当的措施。这些措施包括：

1. 提出变更请求
2. 提供关于测试、过程、培训和文档的反馈
3. 启动客户教育和培训
4. 启动服务支持职员教育和培训
5. 确保问题管理和事故管理过程相连接
6. 改进流程或过程

1.8.3主动问题管理的要点

下面的要点值得注意：

1. 当积累了充分的历史数据，在配置项的强壮度方面的趋势分析才会有增值；
2. 来自许多厂商的操作系统的操作报告提供了系统中固有问题的信息。这些报告应该经常检查，以便在问题出现前识别潜在的硬件问题。理想情况下，提供商职员应该做这项工作（可能通过远程的方式），但是在任何事件中，还是由问题管理负责确保完成这项工作。这些报告能够用于在硬件配置项实际出现故障前，引发对它们的修复和替换；
3. 主动问题管理不必作为一个全职的任务，对于较小的IT服务组织，每半年分配一个支持专家两周的时间来分析事故和问题数据，再花两周的时间启动变更请求，这就足够了。

1.8.4主要问题回顾

当每个主要问题的解决完成后，问题管理应该完成主要问题的回顾。解决过程中参与的适当的人一起来回顾，确定：

1. 哪些做得正确；
2. 哪些做得错误；
3. 哪些能够下次做得更好；
4. 怎样防止问题再次发生。

1.9向支持部门提供信息

问题管理提供有关识别的问题、知名错误和发出的变更请求的信息。这些信息可以是随机的或周期性的。这些信息和报告经常是为了在管理中监控问题管理流程的质量。然而，提供给业务和IT管理的报告也有助于组织内的决策支持。除此之外，报告也可以传递给其它流程和服务台。

1.9.1提供管理信息

管理信息应该使了解组织花费在调查、诊断和解决问题及知名错误上的努力和资源。除此，了解到问题处理的进展和结果也是很重要的。度量方式必要仔细地选择，只有通过仔细和有目的的度量才能形成关于流程质量的意见。

1.9.2将信息分级

临时措施、永久修正或关于解决进展的简要信息应该分级给报告问题的人。这些信息也必须分级给其它客户，因为影响许多人的问题可能仅由一个人报告。

传播这些信息是服务台的基本任务。问题管理应该为此向服务台提供充分的信息和支持。通过将这些信息输入到既有的服务管理工具和数据库，问题管理能够发布相应的信息给服务台和支持部门。

为了有效地传播信息，问题管理流程应该访问配置管理信息，诸如，谁在使用什么，什么时候使用，他们处在什么位置，加上所有必要的联系人明细。问题管理要求的某些明细能够从事故管理流程的电话记录中的获得，然而，对于问题管理，在问题出现前，使用约定的联系地图和正式的沟通渠道经常是更有效果。这种类型的信息也经常在协商（或重协商）SLA的时候获得。另一个来源是日常服务回顾，它是服务水平管理的一部分。

1.10度量

通过维护来自事故控制和问题/错误控制的信息，从而可能得到表示服务质量和流程效率的度量标准。

1.10.1问题/错误控制报告

关于这方面的管理信息包括：

1. 提出的RFC的数量以及这些RFC在涉及到的服务的可用性和可靠性方面的影响；
2. 根据问题类型划分，每个部门或厂商花费在调查和诊断上的时间；
3. 在根本问题被关闭或知名错误被确认前，事故发生的数量和影响；
4. 在问题管理中，被动的支持效果与计划的支持效果的比率；
5. 解决问题的资源规划：
   • 人
   • 其它使用的资源
   • 成本（相对于预算）
6. 所采取行动的简单描述

关于IT基础架构中不牢固的组件的信息、违背与业务协定的服务水平的信息以及与厂商定的服务水平信息都涉及到可用性管理。问题出现的频度和持续时间是相对于服务水平的效率的度量标准。要求的信息包括：

1. 根据以下方面划分的问题和错误的数量：
   • 状态
   • 服务
   • 影响
   • 分类
   • 用户组
2. 关闭问题上花费的全部时间；
3. 重大问题花费的时间；
4. 从产生问题记录开始，到关闭问题或确认知名错误，花费的平均时间和最长时间，可以根据影响代码和支持组（包括提供商）划分；
5. 任何临时解决行动；
6. 重大问题期望的解决时间；

定期审计

流程要求要求对所有操作和过程进行定期审计。审计的目的是确认问题管理和支持小组执行了预定义的过程。审计应该分析主要的问题回顾，检查：

1. 根据协定的计划产生和分析报告；
2. 具有代表性的事故例子，校验相关的问题已经被正确地识别和记录；
3. 具有代表性的问题例子，校验问题被正确诊断，而且是在规定的时期内；
4. 具有代表性的知名错误的例子，校验知名错误已经被授权的对配置的变更所清除，并且在规定的时期内；
5. 升级的限制被坚持执行；
6. 文档被正确地维护－由问题管理职员更新，被接收的人执行；
7. 管理报告有规律地生成，并且有明确的目的；
8. 对于趋势分析表明的迹象，采取了防止措施；
9. 职员培训记录。

1.10.2度量的要点

下面是有关度量的要点：

1. 在制定规范期间，为流程定义想要达到的效果的度量。计划在问题管理运营开始的时候使用它们作为控制，以评估效果，并客观地估计趋势。如果可能的话，提前或都在运营开始的前几周设置实际的目标。如果可能，还可以从当前支持活动中获得统计数据，作为设置目标的基础。这些有助于以后鉴定引入问题管理后所增加的益处；
2. 不要设置不可衡量的目标；
3. 当购买支持工具时，在产品评估和系统设计阶段，拿相应的度量来估计，尽量获得能够提供必要统计的工具；
4. 对于关键效果标准，开发生产报表的过程。问题管理应该有规律地（如一月一次）将实际达到的效果与所有设置的目标比较回顾。记录每次回顾的结果，以用于审计。如果目标必须降低，要确认原因是目标太高，而实际运营太差。问题管理运营中的任何不足应该被回溯，使之在源头恢复正常；
5. 规划设立正式的流程效果和效率的回顾，特别注意客户的需求。确保运营中的流程能够满足所有支持需求；
6. 规划逐步设置更困难的目标，这要与引入问题管理流程预期的益处一起考虑；
7. 监视成功的问题管理系统对职员工作量的影响，经验表明有效的流程，特别是再加上有效的变更管理和发布质量控制，迅速地降低了事故和问题的影响范围。事故数量的降低，以及由此来的支持请求的减少，导致了职员人数的下降。新的应用和新的用户会增加问题和事故，因此，问题管理应该被告知任何影响工作量的预期的变更，以便做出规划，这不仅关系到职员水平和职员数量，而且关系到其它资源，如数据库和其它IT能力；
8. 有时候要在另外的揭示了问题的服务管理流程中执行审计，确保相关的详细信息传递到问题管理，以进行必要的纠正行动。

1.11问题管理中的角色

流程往往跨越组织内的不同功能，因此对于必须执行的流程中的活动，定义相关联的责任是重要的。为了保持灵活性，建议使用角色这个概念。角色被定义为责任、活动和授权的集合，在本章，定义了流程中相应角色很简要的例子。

角色被分配给组织内的人或组，根据角色和组织的情况，这种分配可以全职或兼职。

1.11.1问题管理员

问题管理负责所有的问题管理活动，具有以下明确的责任：

1. 开发和维护问题控制流程；
2. 回顾问题控制流程的效率和效果；
3. 制作管理信息；
4. 管理问题支持职员；
5. 为支持工作分配资源；
6. 监控错误控制的效果，并给出改良建议；
7. 开发和维护问题和错误控制系统；
8. 回顾主动问题管理活动的效率和效果。

建议服务台管理和问题管理员的角色不要组合在一起，因为这两个角色存在利益冲突。

1.11.2问题支持

问题支持有被动和主动两方面的责任，如下：

• 被动责任

1. 识别问题（例如通过分析事故数据）；
2. 根据影响调查问题，直到解决或错误被识别；
3. 对清楚的错误，提出变更请求；
4. 监控知名错误解决的进展；
5. 对未解决的问题/知名错误，向事故管理职员建议与之相关事故的最佳的可用临时措施；
6. 帮助处理主要事故，识别根本原因；

• 主动责任

1. 识别趋势和潜在的问题源（通过回顾事故和问题分析）；
2. 提出变更请求防止问题的重复发生；
3. 防止问题跨越多个系统出现。

1.12附录

1.12.1附录A、问题/错误分类的代码结构例子

1.12.2附录B：Kepner&Tregoe分析

Charles Kepner 和 Benjamin Tregoe开发了一个分析问题很有用的方法。他们讲，问题分析应该是一个系统化的问题解决流程，应该最大化地利用知识和经验。他们将问题分析划分为下面五个阶段：

1. 定义问题
2. 描述问题的识别、位置、时间和大小
3. 确立可能的原因
4. 测试最可能的原因
5. 核实真正的原因

根据时间和可用的信息，这些阶段实现的规模可大可小。即使在只有有限的信息可用，或者时间压力很大，采取结构化的方法来分析问题，提高成功的机会也是值得的。

• 定义问题

因为调查是基础问题的定义，因此定义必须精确地陈述已经出现的与协定的服务水平的偏差。

经常在问题定义期间，最可能的问题原因已经显示。注意不要直接给出结论，这可能从开始就将调查引导到错误的方向。

在实践中，因为复杂的IT基础架构以及不清晰的服务水平协议，问题定义经常是一个困难的任务。

• 描述问题

以下方面用于描述问题，也就是问题“是”什么：

1. 识别－哪一部分不能很好地起作用？问题是什么？
2. 位置－问题出现在哪儿？
3. 时间－问题从什么时候开始出现？问题出现的频率怎样？
4. 大小－问题的大小怎样？多少部分受到影响？

“是”的状况取决于这些问题的答案。下一步是调查在相似的环境中哪些相似的部分还在正确地起作用。据此，问题的答案可以描述为“哪些部分表现同样的问题但还在起作用？”

然后可能在两个环境中有效地调查相应的不同点，而且，过去的变更（可能是引起不同的原因）会被识别出来。

• 确立可能的原因

上面提到的不同点列表以及变更最可能含有问题的原因，因此可能的原因可以从列表中提取出来。

• 测试最可能的原因

每个可能的原因需要被评定，确定是否是问题所有症状的原因。

• 校验真正的原因

剩下的可能的原因必须被核实是问题的源泉。只要以一种方式来证明这点就行－例如，通过实施变更或替换部件。解决这个被快速而简单核实的原因。