什么是IT问题管理 综合指南

问题是多重事件的原因或潜在原因，问题可能来自影响许多用户的重大事件，或者来自重复发生的事件。此外，在用户受到影响之前，可以在基础设施诊断系统中确定问题。

事件会妨碍业务生产力，而提供快速解决方案有助于确保业务操作的无缝连续性。然而，当多个事件同时发生或同一事件多次发生时，通过提供的解决方案或反复提供相同的解决方案来继续前进是不可行的。

IT®问题管理是一种程序化的方法，通过深入挖掘事件，找到问题的根源和修复方法，确保最小的事件从IT基础设施操作中出现，并通过适当的现有问题文档和提供解决方案，降低事件的严重性。

问题管理是一种系统的方法来确定事件的原因和管理所有问题的生命周期。IT®问题管理过程的目标是最小化事件的影响，并消除重复发生的事件。虽然IT®没有说明任何具体的技术来执行问题管理，它建议遵循三个阶段：

• 

  问题识别

• 

  问题控制

• 

  错误控制

这些阶段将在稍后的指南中详细讨论。

反应性管理处理当前影响用户的事件，而前瞻性问题管理则处理将来可能出现的问题(如果不考虑这些问题)。

一个合理的问题管理流程有可能显著减少事故罚单的流入，为IT服务台的工作人员节省大量的时间和精力。这一优势还会带来其他好处，比如减少平均修复时间(MTTR)、提高客户满意度、健壮的已知错误数据库以及降低IT服务和问题的成本。此外，实践主动问题管理的组织很可能从在问题扰乱业务流程之前识别和消除问题中发现巨大的价值。

问题管理作为IT®实践，在整个服务价值链中与其他IT®实践一起使用时最有用。在各种IT实践之间交换信息，即事件管理、变更管理、IT资产管理、知识管理和持续服务改进。各方之间交换的信息通过IT®实践积累价值，进而构建理想的it服务管理流程。

在进一步讨论之前，以下定义将有助于理解本指南的上下文。

• 应变方法：恢复服务并确保业务连续性的临时解决方案。变通方法可以减少事件或问题的影响。
• 根本原因分析(RCA)：根本原因是问题的根本问题。RCA是帮助发现问题根源的调查技术。
• 已知误差：以前发生过的问题，有解决方法或已知的根本原因。
• 已知错误数据库(KEDB)：通过使用事件管理和问题管理记录已知错误创建的数据库。

在本指南中，我们将详细研究问题管理的每个方面，提供您在企业中如何实现问题管理所需的所有知识。

在IT®中，术语“事件”和“问题”似乎是同义词，但它们在实现理想服务质量方面所起的作用是截然不同的。了解事件管理和问题管理相互作用的地方以及它们之间的差异非常重要，尤其是事件结束和问题开始的地方。

事故管理

意外事件是指整个服务或其中一个组件的意外中断。让我们看一个场景来更好地理解它。15分钟后有个重要会议，要打印一份报告。不幸的是，部门打印机坏了。一张罚单很快就会被提起，以修补一个变通方案，并打印出报告。这是一个意外。

事件管理流程是指处理事件并尽快恢复服务。在我们的场景中，服务台工作人员快速将笔记本电脑连接到临近部门的打印机，以帮助用户及时准备好会议报告。因此，事件管理的目标是确保使用变通方法或解决方案尽快解决中断或事件。

问题管理

问题管理不是关于恢复服务或故障排除，而是确定和消除原因。当出现具有公共问题的重复事件，或者发生影响许多用户的重大事件时，服务台将记录一个问题。在我们的场景中，部门中唯一的打印机坏了，该部门中的所有用户都受到了影响，服务台人员将其记录为问题，以查找原因和解决方案。当提供了一个解决方案时，可以关闭一个事件，但是会出现一个问题来永久地修复打印机，这样这个问题就不会再次发生。

回到我们的场景，打印机问题将通过RCA找到永久的修复，并在业务继续进行解决方案的同时作为问题工单进行跟踪。如果问题管理团队无法找到解决方案，则将工作区记录下来，并将问题添加到KEDB中。通过这种方式，问题管理不仅仅是通过找到根本原因来消除事件，还可以确定最可行的解决方案，从而将中断降到最低。有时，尽管知道根本原因，但最可行的解决方案是实现一个变通方案，并将其记录为已知错误。

尽管不同，事件管理和问题管理是相辅相成的，并且是紧密结合的。事件管理确保业务操作的连续性，而问题管理则负责潜在的问题和问题。

什么是反应性问题管理？

反应性问题管理对出现的事件作出反应，然后继续问题管理过程。本质上，反应性问题管理方法的目标是找到并消除已知错误的根本原因，并且只在问题出现为重大或重复发生的事件时才处理它。

什么是主动问题管理？

前瞻性问题管理通过查看过去的事件、网络监控数据日志和其他信息源来查找IT系统中的问题、故障和已知错误，然后在它们作为事件出现之前永久地解决它们。此过程是持续服务改进的一部分。主动问题管理还旨在解决KEDB下的所有已知错误(如果可行的话)。

这两种类型的问题管理都遵循同样的问题解决阶段:问题识别、问题控制和错误控制。唯一的区别是识别问题的方法。尽管如此，这两个流程都为服务管理提供了独特的优势，并且需要独特的资源才能发挥作用。

刚接触问题管理的组织应该把精力集中在实现反应性问题管理过程上。明智的做法是，利用现有服务台员工解决问题的才能，当他们不忙于处理日常事务时;在这样做的过程中，他们在实施前摄性问题管理之前获得了宝贵的经验。

随着组织的服务交付的成熟，它应该过渡到一个主动的问题管理过程。这种转换应该由一个具有良好分析技能的团队来执行，该团队在IT基础设施和支持组织的工具和技术方面非常精通。

然而，许多组织并没有经历这种转变，因为很难量化主动性问题管理的好处，它可以被看作是解决潜在的问题，而不是实际的问题。然而，一些世界上最有效的组织实践了积极的问题管理，并从中发现了巨大的好处。

在建立问题管理的过程中，组织可能会遇到一些障碍。组织可能没有分配给问题管理团队的资源，或者它可能已经有一种非正统的管理问题的方法，并且不愿意改变。有时候，这可能只是一个与成本相关的拒绝请求。

因此，在问题管理过程中包括所有的涉众，并表达它如何为组织的不同方面提供价值是至关重要的。这些好处包括：

• 通过适当的文档消除组织服务中的错误。
• 通过识别和解决薄弱环节，优化服务设计，确保最有效和高效的服务交付路径。
• 通过为事件提供永久的解决方案，而不是在工作区中停止，从而提高服务故障的首次时间固定率。
• 减少在关键时刻影响多个用户或单个用户的事件的影响。
• 防止大多数事件和问题长期困扰组织，提高用户的生产力。
• 增强用户对组织的IT服务的信心。
• 通过系统地维护一个KEDB，减少从故障中恢复所需的时间。
• 通过一次性修复来防止重复发生的事件，节省宝贵的服务台工作来解决它们。
• 通过从解决的问题中学习，鼓励IT服务随着组织的发展而成熟。
• 通过技术意识和有价值的见解在组织内开发IT人才。

问题管理团队的角色与现有的组织结构直接相关。组织的年龄、文化、技术和世界各地的地点数量都会影响问题管理团队的组成。在小型的IT组织中，团队的职责可能会被合并，或者在大型的跨国公司中，他们可能是专门化的。

不管怎样，it团队的便利性和灵活性决定了如何定制一种安排，以确保按照IT®建议有效地解决问题。了解组织的总体战略是开始组建团队的一个很好的起点。此外，重要的是要警惕组织准备用于问题管理团队开发的资源。

随着组织技术的发展，团队的角色和职责应该扩展、分化和成熟，否则在服务交付过程中可能出现责任混乱。

问题管理团队的一般角色和职责如下所示。

正如组织为其客户创造价值一样，IT服务管理通过最佳实践为其用户创造价值，并间接地帮助为组织创造价值。要创建这个值，必须有一个具有定义的输入和输出的流程。当IT -ready服务台就位后，问题流程的流线型流程如下：

根据IT®，您可以使用任何您认为适合您的组织的技术来实现问题管理流程。实施的技术应该具有支持IT®问题管理的三个阶段的功能。

这三个阶段是：

问题识别

问题识别阶段在管理工具中识别和记录问题。与服务管理的多种实践(包括事件管理、资产管理、CMDB和变更管理)相关联的服务台工具，在此阶段为组织提供了优势。

虽然服务台工作人员通常会根据事件的激增报告问题，但积极处理问题的办法是：

• 分析事件趋势，利用网络监控系统，并利用其他诊断软件。
• 从可能发生的事件中发现风险。
• 评估从合作伙伴和供应商处收到的信息。
• 评估来自内部软件开发人员、工程师和测试团队的信息。

根据组织的结构、领域和文化，可以有更多的模式来识别问题。然而，重要的是要有一个系统来处理问题，识别问题，确定问题的优先级，并记录问题，以便进行进一步的调查和诊断。

问题控制

问题管理是一项协作工作，因此要使结果有效，多个部门和涉众应该参与到问题控制阶段。

问题控制包括确定优先级、调查、分析和记录已知错误和解决方法等活动。有许多技术可以帮助确定问题的优先级和分析问题。一个好的经验法则是，首先处理那些解决后可以显著抑制服务中断的问题。

可行性是解决问题时要注意的另一个方面。永久地解决一个问题可能比解决一个变通方法需要更多的资源。快速的成本效益分析可以确定您是否应该继续进行永久修复。

工作区被记录在问题记录中。通常情况下，如果问题持续的时间较长，建议采用快速解决方案。这种变通方法甚至可以成为事件管理解决方案的一部分;然而，问题管理团队应该审查解决方案，并在必要时细化解决方案。正如您所看到的，有效的事件解决方案可以成为某些问题的永久解决方案。

错误控制

此阶段管理来自KEDB的已知错误，方法是定期检查可能的永久修复(如果它们通过了成本-收益分析)。

一旦分析了问题，就会将其记录为已知错误。对这些已知的错误定期进行重新评估，以考虑它们所造成的影响，并测试变通方法的有效性。

一个集成的服务交付最佳实践系统可以改进业务服务和IT服务功能。有效的问题管理流程与其他几个IT®流程进行交互。

与问题管理相互作用的过程简述如下：

事故管理

事件管理是组织中记录、分类、确定优先级、分配和解决问题的系统过程。事件管理的目标是尽快重新启动中断的服务;通常，这意味着一种变通方法被安排来代替永久的解决方案。此实践中的每个活动都以粒度的形式记录下来，并推给问题管理团队，由问题管理团队发起RCA以开发永久解决方案。您可以看到，尽管问题管理是它自己的过程，但它依赖于健壮的事件管理过程。

变更管理

变更管理的目标是增加组织中实现的任何变更的成功率。变更是指对组织的IT基础设施、流程、服务、产品、应用程序、供应商或任何其他隐式或显式地影响组织的服务交付的内容所做的任何修改。

根据IT框架，问题管理的职责是找到问题解决方案的根本原因，并通过变更控制实际实现解决方案。由于实现更改涉及在多个业务单元中管理风险，因此需要有自己的流程来进行有效的处理。然而，问题管理团队应该参与变更的实施后评审，以确保问题解决方案和与之相关的已实施变更之间的一致性。

IT资产管理

IT资产管理是管理组织中资产的生命周期的实践。其活动包括从资产中获取最大价值、控制资产成本和管理资产风险。这些风险可以是遵从性、供应商选择、使用策略和处理实践方面的风险。

当组织使用的硬件和软件资产出现问题时，资产管理和问题管理的实践可能会交叉。当问题的根本原因似乎来自产品或服务时，IT资产管理的详细库存记录加速了问题的解决过程。除此之外，IT资产管理还帮助问题管理研究事件的影响，检查实现解决方案的效果，并在需要时通过RCA提供信息。

让我们通过一个场景来看待事物。

Zylker是印度一家发展迅速的库存摄影供应商。孟买的一位经理在从新德里的SQL server生成月度报告时遇到了麻烦。事件已经被提出，服务台的工作人员已经通知了新德里的技术人员。作为临时解决方案，报告在本地生成并发送，以确保业务连续性。

Zylker的前瞻性问题管理团队决定对过去六个月发生的事件进行趋势分析。他们在新德里发现了多起与服务器有关的事件。这导致他们启动一个问题工单，并使用所有记录事件的累积数据进行调查分析。

新德里的技术人员发现，SQL server使用多种类型的协议来连接数据存储设施，包括iSCSI和Fibre Channel。由于这两种协议都在以太网网络上运行，因此对于本地块交换机是否配置用于大数据包数据传输存在疑问。技术人员从IT资产管理团队接收数据，并验证开关不是罪魁祸首。有证据表明，在本地生成报告不是问题。

广域网(WAN)是下一个需要分析的对象，因为一位来自孟买的经理在生成月度报告时遇到了麻烦。技术人员由于有网络问题的经验，对每月末的流量有怀疑，所以他们在公司的路由器和交换机上安装软件，分析通过它们的流量，并统计汇总信息。

该软件生成的图形和图表显示所使用的顶级协议，以及每个协议在一个月内消耗的带宽。这显示了在月末生成月度报告的同时，有大量的带宽使用。经过仔细的检查，我们发现完整映像备份与月度报告的备份时间差不多，这导致广域网路上出现了严重的瓶颈。

现在问题的根本原因已经确定了，技术人员提出了一个更改工单，重新安排映像备份到业务开始前的凌晨时间，从而平衡网络中的流量。

以下是在这个场景中执行的步骤的概述：

所有IT®实践与其他IT®实践有着错综复杂的关系。随着您的问题管理在服务交付方面的成熟，请确保改进它与其他实践的交互方式，以实现健康的、面向业务的服务交付。

一个好的服务台工具可以强制执行问题管理过程，但是用于调查和诊断的技术应该根据组织的不同而有所不同。建议根据组织的需要灵活使用调查技术，而不是过于规定。

因为问题可以以任何形状或大小出现，所以不可能每次都坚持使用一种技术来找到解决方案;相反，使用技术的组合将产生最好的结果。一个简单的局域网连接问题可以通过一个快速的头脑风暴会议来解决，但是一个网络或VoIP问题可能需要更深入的研究。

这里有一些您可以在组织的问题管理过程中实践的技术。

集思广益找到解决方法

通过在部门之间建立对话，您可以获得各种不同的观点和新信息，从而产生许多潜在的解决方案。

为了有一个富有成效的头脑风暴会议，你需要一个主持人。版主处理以下事项：

• 引导会议的方向
• 记录所获得的见解
• 强调应采取的措施
• 跟踪讨论的交付物
• 避免耗时的会议

当使用石川分析和五个为什么的方法等协作解决问题的技术时，头脑风暴会议的效率更高。

Kepner-Tregoe方法

Kepner-Tregoe (K-T)方法是一种解决问题和决策的技术，由于它的逐步解决问题的逻辑方法，在许多领域使用。它非常适合在主动和被动的问题管理中解决复杂的问题。

该方法遵循四个过程：

• 情境评估：情境的评估与澄清
• 问题分析：因果联系
• 决策分析：权衡备选方案
• 潜在问题分析：预测未来

然而，问题分析是唯一涉及IT®问题管理的部分，它由五个步骤组成。

定义问题

确定真正的问题是什么本身就是一个问题。由于问题管理本质上是一项协作工作，对问题进行全面的定义可以消除任何参与成员可能持有的先入之见，从而节省大量时间。

例如，如果组织在服务器上的自动数据备份失败，可以将问题定义为：

服务器备份失败

这个定义确实描述了偏离正常情况，但它需要更多的问题和信息。一个好的定义模型应该是明确的、容易理解的。

为消除歧义，上述定义可更新为：

11月15日服务器#34-C上的数据备份失败

这个定义提供了更多的清晰度，并使员工从多余的问题中解放出来。然而，这一定义还可以进一步完善。假设数据备份失败的原因可以归结为某个事件，例如应用新补丁;那么，最初的问题分析无疑会导致这一事件的发生。

为了节省时间和精力，我们将定义更新为：

11月15日，在工程师Noah应用了3.124补丁之后，服务器34-C上的数据备份失败

这个详细的定义没有多余的问题，并且提供了大量关于问题所在的信息。这些花在初始定义上的额外时间节省了宝贵的时间和精力，为分析提供了逻辑方向，并消除了关于问题的任何先入为主的概念。

描述的问题

下一步是对问题进行详细的描述。K-T方法提供了在任何问题上需要提出的问题，以帮助识别可能的原因。

下面的问题有助于描述任何问题的四个部分：

• 有什么问题？
• 问题发生在哪里？
• 问题是什么时候发生的？
• 问题发生到什么程度？

每一个问题都需要两种类型的答案：

例如：“出了什么问题？”或“问题在哪里？”

并且

可能但不是：例如，“问题可能在哪里但不是？”

这个练习有助于比较和突出业务流程中偏离正常性能的原因、位置、时间和方式。

建立可能的原因

在前一个步骤中对正常性能和偏差性能进行比较有助于找出问题的可能原因。把所有的信息放在一张表里，可以帮助进行比较。

当信息被收集在一起时，新的可能的原因变得明显起来。在我们的例题中，根本原因可以归结为：

由三级工程师知识传递不足而引起的程序错误。

无论是什么问题，都可以通过相关的比较，对可能的原因进行合理的分析。

测试最可能的原因

倒数第二步是列出可能的原因，并在得出结论之前进行测试。每一个可能的原因都应遵循这个问题：

如果……是这个问题的根本原因，它是否解释了这个问题是什么，这个问题可能是什么，但不是？

同样，将所有信息填充到一个表中也是有益的。

查明真正原因

最后一步是消除所有不可能的原因，并为最可能的原因提供证据。有了这些验证，就可以提出问题的解决方案了。如果没有可能的根本原因的证据，就不应该尝试解决问题。

石川分析，或者鱼骨图分析

石川分析使用鱼骨框架来列举问题的因果关系，并可与头脑风暴会议和五个为什么的方法结合使用。使用石川图执行RCA的简单性不应该欺骗您它处理复杂问题的能力。

要开始分析，定义问题并将其用作鱼骨的头部。绘制脊柱并添加问题可能源自肋骨到鱼骨的类别。

通常，从服务管理的四个维度开始分类是最容易的:合作伙伴、流程、人员和技术。但是，这些类别可以是与您的问题、环境、组织或行业相关的任何内容。

一旦这些类别形成了鱼骨的肋骨，就开始给每个类别附加可能的原因。每个可能的原因也可以扩展到详细说明发生的原因。这可能导致一个复杂的图表，包含4到5个层次的原因和影响，然后深入到问题的根本原因。

建议将密集的肋骨分割成所需的额外肋骨。或者，将空的排骨与其他合适的排骨相结合，使鱼骨保持干净，易于阅读。另外，您应该确保这些肋骨是由原因造成的，而不仅仅是问题的症状。

这个分析同样是一个协作的工作，并且需要一个主持人以一种有效的方式指导头脑风暴会议。每个参与者都有机会参与进来，提供对问题的全面看法。

柏列特图分析

帕累托法则是一种观察，大约80%的结果来自大约20%的原因。这一观察适用于广泛的主题，包括问题管理。

当试图减少组织中发生的事件的数量时，在开始解决问题之前应用Pareto分析是非常有效的。Pareto分析优先考虑事件的原因，并帮助管理基于其影响和概率的问题。

这种分析是通过从一个帕累托表生成一个帕累托图来进行的。帕累托表由所有问题的分类的累计计数组成。帕累托图是一种条形图，显示了各种问题分类的频率的累积百分比。

创建一个帕累托图，遵循以下步骤：

• 从服务台工具中收集问题工单数据。
• 根据不同的属性将数据重新建模到不同的类别中。
• 创建一个Pareto表，找出在一段时间内每个分类中出现问题的频率。
• 计算每个类别中出现问题的频率。
• 按递减顺序生成累积频率百分比。
• 将数据绘制在图上，以创建一个帕累托图。

最重要的步骤是将数据重新建模为一组可计数的分类和属性。

此图表有助于确定应该首先解决的问题，以显著减少服务中断。这一分析补充了石川和Kepner-Tregoe方法，提供了一种方法来确定问题类别的优先级，而其他方法则分析问题的根本原因。

重要的是要记住80/20规则指出了可能的原因，有时可能是不正确的。

5个技术

对于RCA来说，五个为什么是一个简单的技术。它定义了一个问题语句，然后反复询问原因，直到发现问题的根本原因。“为什么”的数量不需要限制在5个以内，但可以根据问题和情况而定。

“五个为什么”技术补充了石川法、帕累托分析法和K-T法等其他解决问题的技术。

使用前面的服务器中数据备份失败的例子，让我们应用“五个为什么”技术。

上述迭代过程揭示了标准化格式的缺乏，从而导致了数据备份失败的问题。

对于我们的目的，上面的例子是一个简单的方法执行。在真实的场景中，下一个问题取决于前一个问题的答案，因此必须与对问题所在领域有详细知识的涉众协作。

通过采用部分K-T方法和五个“为什么”技术，例如在用返回问题验证每个答案之前，为每个答案提供证据，您可以确保在问题解决过程中进行精确的分析。

其他技术

除了这五种主要的技术外，还有许多其他的技术，每一种都有其独特的优点。总的来说，问题调查是使用适合情况的技术组合来进行的。在问题管理社区中流行的其他一些技术包括时间测试、故障树分析、故障隔离方法、假设测试和痛苦值分析。随着组织问题管理过程的成熟，花时间学习许多技术是值得的。

虽然我们已经讨论了实践问题管理的过程和各种方法，但是在实际操作时需要记住一些事情。这些注意事项将帮助您避免问题管理过程中的小问题。

注意事项：

• 广播事件和问题之间的确切区别：IT®流程只有在事件管理和问题管理之间有明确的、公认的界限时才有效，因此要为您的组织制定一个适用的界限。
• 承认问题经理是非技术性的角色：问题管理者是将整个团队凝聚在一起的粘合剂。该过程的技术部分将由专家执行，但是问题管理器使其成为可能。
• 建立问题管理工作的目标：朝着短期和长期目标前进，这样你的注意力就不会轻易减弱。例如，短期目标类似于解决扰乱业务的十大问题，长期目标类似于提高支持成本节约。
• 永远寻求永久的解决方案，而不是临时的：要认识到问题管理的真正好处，要始终寻求永久的解决方案，即使这是一个永久的变通方法。
• 欢迎那些挑战现状的人：要感激那些质疑事物存在状态的成员。这可能是导致积极改进您的组织系统的火花。

不该做的事：

• 从一开始就努力做到完美：问题管理是一种学习经验，对每个组织都是独特的。从一开始就试图做到完美，只会让你自己走向失败。没有人会在开始弹吉他的第一天就成为摇滚明星。
• 用反应性和前瞻性的方法使自己复杂化：开始的时候要放松。有些问题的严重性是不容忽视的，有些问题需要通过分析才能发现。
• 将问题管理作为一个单独的过程进行度量：IT®流程作为一个整体被设计为相互协作，使您的IT服务交付更易于管理。问题管理的好的和坏的结果都可以来自于事件管理、变更管理，甚至项目管理。

关键性能指标(kpi)应该为用户、技术人员和涉众提供价值。虽然这些度量标准可以作为自我检查的工具，但是建议将问题管理过程的度量标准限制在7或8个以内，因为太多的度量标准可能会对过程本身产生偏差。在底层可能会有问题，但是不同的度量一起工作可能会得出不同的结论。

KPI可以根据组织的工作方式而变化，因此对于所有组织来说，没有一个适用的指标列表。为了确定应该监视哪些kpi，应该要求涉众参与并决定哪些是有益的。

下面是问题管理过程中最适用的KPI。

组织更容易利用软件来制定他们的问题管理过程，而不是试图从头开始开发它。市场上有许多声称是问题管理的最佳解决方案;至少，问题管理软件应该具有下面列出的功能。

IT®的问题管理框架为每个组织在问题诊断和解决的道路上提供了指导。问题管理及其实践对于所有组织都是灵活的，无论大小、地理分布、行业和每天使用的技术。

具有健壮的事件管理的组织应该通过实现用于记录和管理问题以及维护KEDB的单独通道来实现基本的问题管理设置。随着问题管理团队的经验随着组织的增长而增长，过程也应该成熟起来。

对于一个已经在进行问题管理的组织来说，它的目标应该是将事件减少到历史最低点。这可以通过问题管理的积极方法来实现。

实现问题管理过程的一个简单的第一步是使用服务台工具和正确的模块，以确保全面的IT服务台操作和工单、事件和问题的集中控制。在您的组织中拥有一个简化的问题管理过程是一个长期的项目，它将随着您的业务增长和IT基础设施的扩展而得到回报。