文档更改服务管理实践 - 04 问题

由 superadmin 于 2024/12/25, 15:38 最后修改

从版本< 12.1 >

由superadmin编辑
在2021/12/17, 17:30上

到版本

由superadmin编辑
在2021/12/17, 17:27上

< >

修改评论上传新附件1639733225356-658.png

Raw
已渲染

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

标题

...	...	@@ -1,1 +1,0 @@
1		-ITIL 4 问题管理实践指南

父

...	...	@@ -1,1 +1,0 @@
1		-ITIL 4 信息安全管理实践.WebHome

Content

@@ -1,858
          +1,0 @@
--**申明：**
--
--本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众
--多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信
--公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
--
--
--请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
--
--
--本文档翻译工作参与人员：
--
--翻译：孔彦波
--
--审校：刘雨龙
--
--
--总审：长河
--
--审核：王庆、李坤
--
--统筹：常宏
--
--
--
------
--
--= **1. 关于本文件** =
--
--本文档提供问题管理实践实用指南，分为五个主要部分，涵盖：
--
--* 本实践的一般信息
--* 本实践相关的流程和活动及其在服务价值链中的作用
--* 参与本实践的组织和人员
--* 支持实践的信息和技术
--* 对本实践的合作伙伴和供应商的考虑
--
--
--== **1.1 ITIL4资格认证计划** ==
--
--本文件中所选内容可作为以下教学大纲的一部分进行考查：
--
--* ITIL专家创建、交付和支持
--
--详情请参阅教学大纲文件。
--
--
--
------
--
--= **2. 一般信息** =
--
--
--== **2.1** **目的和描述** ==
--
--**关键信息**
--
--问题管理实践的目的是通过查明事件的实际和潜在原因，以及管理临时解决方案和已知错误，减少事件发生的可能性及其影响。
--
--没有完美的服务。每个服务都存在可能导致事件的错误或缺陷。错误可能源于服务管理四维模型中的任何一个维度。例如，第三方合同中的错误与组件故障一样可能导致事件。许多错误在服务上线之前就能被识别出来，然后在设计、开发或测试期间得到解决。但是，有一些仍未被发现，将存在生产环境中，它们可能会导致事件产生。为了管理生产环境中出现的错误，组织开发了问题管理实践。该实践旨在识别和分析组织产品中的错误，以最大程度地减少其对所提供服务的负面影响。
--
--
--== **2.2 术语和概念** ==
--
--可能导致（或已经导致）事件的错误称为问题。
--
--
--**定义：问题**
--
--一个或多个事件的原因或潜在原因。
--
--问题管理实践有三个不同的阶段，如图2.1中所示。
--
--(% style="text-align:center" %)
--[[image:1639732499315-764.png]]
--
--图2.1 问题管理实践的三个阶段
--
--
--=== **2.2.1 问题识别** ===
--
--有两种主要方法来识别问题。第一种方法是调查已经发生的事件的原因。这种方法先要了解症状，再了解原因。它目的是防止事件再次发生，也可能有助于解决处于解决中的事件。这称为被动问题管理，因为它是对事件的被动反应。
--
--第二种方法是在问题导致事件发生之前识别到它，评估相关风险，并优化响应，以最小化事件发生的可能性和/或影响。这称为主动问题管理，基于有关问题的信息，尤其是在生产环境中可能存在的问题。这些信息来源可能包括：
--
--* 供应商告知其产品中的漏洞
--* 开发人员、设计人员或测试人员在使用下一版本时发现生产版本中的错误
--* 用户和专家社区分享其他组织的经验
--* 基础设施的监控发现系统性能中的偏差，但这些偏差还不属于事件
--* 技术审计和其他评估
--
--问题管理实践总是被动的对问题作出反应：它不能防止问题的第一次出现。主动与被动的区别是指问题调查与事件之间的关系：
--
--* 主动问题管理有助于预防事件第一次发生
--* 被动问题管理有助于预防事件再次发生，并可能有助于解决进行中的事件
--
--
--
--=== **2.2.2 问题控制** ===
--
--问题识别使得问题被登记形成问题记录。可能形成一系列待分析问题列表。已记录的问题将根据其最初的分类和优先级进行分析。问题完成分析之后，问题初始分类很可能会发生改变，特别是基于事件（症状）信息登记的问题。
--
--
--**定义**
--
--**任务优先级**是一个任务相较于其他任务的重要性。具有更高优先级的任务应优先被处理。优先级基于待办事项中所有任务的情况来定义。无法为待办事项中所有的任务分配资源时，通过**优先级排序**选择优先要处理的任务。
--
--问题控制专注于问题的分析。在被动问题管理中，问题分析可使用关于产品架构和配置的信息来识别可能导致相关事件的配置项（CI）。分析不限于配置项，还包括其它因素，例如：用户行为、人为错误和规程错误等。
--
--主动问题管理通常从更好地掌握配置项和服务管理四维模型中所有维度开始，这些组件可能导致事件。例如，如果供应商将其软件中的漏洞告知组织，则问题控制的任务将是掌握组织使用该软件的情况，以便评估与漏洞相关的风险以及对所提供服务的潜在影响。
--
--对问题完成分析后，将为其分配为“ 已知错误”状态。
--
--
--**定义：已知错误**
--
--已经分析过但尚未解决的问题。
--
--
--**问题优先级**
--
--问题很多属于低紧急度。服务团队有一些更紧迫的任务需要完成，使得紧急度低的问题在待办事项中总处于保持的状况。但是，确保对识别到的问题进行分析和解决是非常重要的。从中长期的角度来看，问题既影响所提供的服务的质量，也影响服务提供者的工作量。
--
--问题优先级划分有许多简单的准则：
--
--* 评估问题的影响度和紧急度（以及调查和解决的时间限制），评估结果可用于确定优先级和其他重要的考虑因素，例如，预估完成工作所需的时间
--* 只有存在资源冲突时才需要确定优先级。当有足够的资源在有限的时间内处理每一项任务时，优先级排序不是必须的
--* 应该使用包含其他任务（计划内的和计划外）的统一待办事项来计划问题处理
--* 优先级排序是为团队内部成员分配任务的一种工具。如果问题由多个团队处理，则可根据每个团队的资源可用性、目标完成时间以及预计处理时间来确定优先级。
--* 资源可用性和预计处理时间由团队定义。目标完成时间取决于问题的影响，当问题被确定并初步分类时，它可能被定义。随着问题分析过程中发现新的信息，问题的影响，预计完成（解决）时间可能会发生变化
--* 可视化工具（例如，看板和精益原则，限制进行中任务数量）有助于有效的优先级排序
--
--这些规则适用于服务提供者的专业团队执行的所有类型的工作（计划的和计划外的）。重要的是，在所有实践中涉及组织服务管理活动的每个人都应该同意并遵循它们。
--
--这些规则适用于服务提供商的专家团队执行的所有类型的工作(计划的和计划外的)。重要的是，在所有实践中，参与组织服务管理活动的每个人应达成一致，并遵循它们。
--
--问题分析过程中可能会发现错误已经从组织的环境中消除，或者它们不会影响所提供的服务。根据上面的示例，组织可能未使用该软件易受攻击的版本，或者漏洞可能不会影响组织的服务。在这些情况下，问题记录经过分析后可以设置为已关闭。在其他情况下，它可能保持处理状态，并启动错误控制。
--
--问题控制其他的重要输出可能是解决事件的建议。通常，了解导致事件的原因有助于，为处理事件提出更有效的解决方案，包括临时解决方案。
--
--
--**定义：临时解决方案**
--
--减少或消除尚未获得永久解决方案的事件或问题的影响的解决方案。一些临时解决方案可以降低事件发生的可能性。
--
--请注意，从问题分析得出的临时解决方案通常不会减少发生事件的可能性，而是，有助于在事件发生时，更快、更好地解决事件。有助于防止事件再次发生的临时解决方案通常在错误控制阶段被找到。
--
--
--=== **2.2.3 错误控制** ===
--
--对问题进行分析后（如，产品中的错误对组织自身服务的影响已经被评估），应该对其进行控制。仅当满足以下条件之一时，问题记录才可能关闭：
--
--* 问题被解决：与问题相关事件的风险被移除，或降低到可接受的水平。
--* 问题不再影响组织。
--
--请注意，尽管“ 已知错误”是问题的状态，但是某些组织更喜欢使用独立的记录来进行问题控制和错误控制。在这些情况下，当问题分析完成时，问题记录可能被关闭，并且随后的活动可能被登记到相关的已知错误记录中。上述关闭条件适用于已知错误，无论它们是否是问题。
--
--如果许多已知错误无法得到有效解决，并且它们会继续影响服务，那么它们将长期处于未关闭状态。在这些情况下，组织可能集中精力，最大程度地提高事件处理的效果和效率（有时达到完全自动检测和解决的水平），但问题记录应保持未关闭状态，并定期进行审查。
--
--如果解决问题的成本高于处理已知错误或有效事件管理的成本时，则上述错误控制方法是有效的。这通常用于与第三方组件相关的典型问题，尤其是在第三方无响应或组件不受支持的情况下。相反，如果组件可用于改进并可以进行改进时（特别是在组织自己控制下的软件），则应迅速消除已知错误。
--
--已知错误是组织技术债务的一部分，应在合理可行的情况下予以消除。
--
--
--**定义：技术债务**
--
--选择临时解决方案，而不是需要花费更长的时间的系统性解决方案。
--
--错误控制确保组织拥有与其产品相关的已知错误有足够的最新信息，包括它们的状态及对服务的影响。
--
--错误控制对问题解决方案进行了优化，使其成本、负面影响、正面影响相平衡。
--
--定期检查已知错误有助于识别环境中的变化（例如，业务影响、永久解决方案的可用性和相关成本，以及资源可用性等），这些变化可能会导致对错误的重新评估，并启动错误的解决。
--
--错误控制的关键输出是改进措施和变更请求，它们启动问题的解决。某些解决方案修复了配置项和其他产品组件中的错误。其他的可能会引入永久的变通方法：对产品配置的更改不会修复错误，但可以将事件发生的可能性降到最低，相关的问题记录可能会被关闭。保持错误相关知识的可用性是很重要的，这些知识对于将来的服务设计以及规划可能非常有价值。
--
--永久性变通方法通常用于组织无法修复的组件（旧系统、第三方提供的工程基础结构等）。但是，使用永久性变通方法来防止事件会增加组织的技术债务。因此，应尽可能避免使用。
--
--总而言之，表2.1中列出了消减问题的可能类型。
--
--
--表 2.1 问题消减的方法
--
-- [[image:1639732688979-363.png]]
--
--
--=== **2.2.4** **问题模型** ===
--
--不同的问题来源和类型可能需要不同的方法来识别和控制问题。例如，以下类型问题中的一种或多种可能对问题管理实践需要特殊的处理方法。这些问题包括以下方面：
--
--* 软件
--* 硬件
--* 程序
--* 第三方组件
--* 消费者的资源
--* 数据
--* 数据与敏感信息相关
--* 高度规范的服务和系统
--
--为了优化这些问题和其他类型问题的处理与解决，服务提供者通常定义问题模型。问题模型有助于有效地管理问题，由于应用程序相关的经过验证和测试的方法，通常可以得到更好的结果。
--
--
--**定义模型**
--
--一种管理特定类型问题的可重复方法。
--
--问题模型的创建和使用对于问题管理实践中的活动很重要。它们将在第3节中进行介绍。
--
--
--
--== **2.3 范围** ==
--
--问题管理实践的范围包括：
--
--* 问题的识别与分析，包括已知错误的分析与控制
--* 启动变更以消除或减少问题的影响
--* 向干系人提供有关问题信息
--* 监控错误和持续改进解决方法
--
--有一些活动和责任范围不包括在问题管理实践中，尽管它们仍然与问题密切相关。表2.2中列出了这些内容，以及对可以找到它们的实践的引用。重要的是要记住，ITIL实践只是价值流的背景中使用的工具的集合，应根据情况需要将它们组合在一起。
--
--表2.2 与其他实践指南中描述的问题管理实践相关的活动
--
--|**实现价值**|**实践指南**
--|事件解决|事件管理
--|(% rowspan="4" %)控制和实现为解决问题而启动的变更|变更启动部署管理
--|基础设施和平台管理发布管理
--|软件开发和管理
--|  其他做法
--|风险评估和控制|风险管理
--|(% rowspan="3" %)检测和控制产品在部署到运行环境之前的错误|部署管理服务设计
--|服务验证和测试
--|软件开发和管理
--|沟通事件的解决方法给用户|服务台
--
--
--== **2.4 实践成功因素** ==
--
--**定义：实践成功因素**
--
--达成实践目标所必须的一系列复杂功能组件
--
--实践成功因素（PSF）不仅是一个任务或活动，还包含所有服务管理思维模型组件。实践中PSF的活动和资源的性质可能有所不同，但它们共同确保了实践有效。
--
--问题管理实践包含以下成功因素（PSF）：
--
--* 识别并了解问题及其对服务的影响
--* 优化问题解决和消解措施。
--
--
--=== **2.4.1** **识别并理解问题及其对服务的影响** ===
--
--组织应该掌握其产品中的存在错误。因为，它们可能导致事件并影响服务质量和客户满意度。问题管理实践确保问题被识别，从而有助于持续改进的产品和服务。如果是主动执行而不是被动执行，这将更加有效。
--
--
--=== **2.4.2** **优化问题解决和消解措施** ===
--
--发现问题后，应有效和高效地进行处理。修复（消除）组织产品中的所有问题几乎是不可能的，但是，对于组织及其客户而言，没有解决方案的问题识别，其价值就会大大降低。应该为问题消解定义一种平衡的方法，即一种考虑相关成本，风险和对服务质量的影响的方法。
--
--
--
--== **2.5** **关键指标** ==
--
--ITIL实践的绩效应在每种实践所贡献的价值流的背景下进行评估。与任何工具的表现一样，该实践的表现只能在其应用范围内评估。但是工具的设计和质量会有很大差异，这些差异定义了不同用途下的潜力或能力。有关度量、绩效（KPI）和其他有助于实现这一目标的其他技术，请参见《度量和报告实践指南》。
--
--问题管理实践的关键指标已映射到其PSF。 它们可以用作价值流中的KPI，以评估实践对这些价值流的有效性和效率的贡献。 表2.3中给出了一些关键指标的示例。
--
--表2.3 实践成功因素的关键指标示例
--
-- [[image:1639732840425-688.png]]
--
--将度量指标正确汇总到复杂的指标中，才更易于将数据用于正在进行的价值流管理，更利于问题管理实践的定期评估和持续改进。这并没有单一的最佳解决方案。度量标准将基于组织的整体服务战略和优先级，以及实践贡献的价值流的目标。
--
--
--
--
------
--
--= **3. 价值流和流程** =
--
--
--== **3.1 价值流贡献** ==
--
--与任何其他ITIL 管理实践一样，问题管理实践也有助于实现多个价值流。请谨记单一实践不会形成价值流。问题管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是：
--
--* 交付和支持
--* 改进
--
--问题管理实践对服务价值链的贡献如下图片3.1 所示：
--
--(% style="text-align:center" %)
--[[image:1639732920116-788.png]]
--
--图3.1 问题管理实践对价值链的贡献的热图活动
--
--
--
--== **3.2 流程** ==
--
--每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
--
--
--**定义：流程**
--
--一组相互关联或交互的活动，可将输入转化为输出。一个流程接受一个或多个已定义的输入并将其转换为输出。流程根据活动的顺序与依赖性定义次序。
--
--问题管理活动分为四个过程：
--
--* 主动问题识别
--* 被动式问题标识
--* 问题控制
--* 错误控制
--
--
--=== **3.2.1** **主动问题识别** ===
--
--该流程包括表3.1中列出的活动，并将输入转换为输出。
--
--表3.1 主动问题标识流程的输入活动和输出
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--来自供应商和供应商的错误信息
--
--有关专家团队提交的潜在错误的信息
--)))|(% rowspan="4" %)(((
--评审的提交信息
--
--问题登记
--
--问题的初步分类和分派
--
--
--)))|(% rowspan="4" %)问题记录反馈给问题发起者
--|外部用户和专业团体提交的有关潜在错误的信息
--|用户提交的有关潜在错误的信息监控数据
--|服务配置数据
--
--图3.2 显示了流程的工作流程图。
--
--
--(% style="text-align:center" %)
--[[image:1639733001742-715.png]]
--
--图3.2 主动问题识别流程的工作流程
--
--主动问题用于识别到组织产品中存在的，来源于事件记录以外的潜在错误。可以考虑将问题的主动标识和控制作为风险管理的一种形式执行，即重点关注组织产品中的漏洞，它包括对漏洞和相关风险的识别、评估和分析。
--
--表3.2 中列出了组织产品相关错误可能的信息来源。
--
--表3.2 主动识别问题的信息来源
--
--[[image:1639733031760-434.png]]
--
--
--主动的风险管理活动应尽可能的专注于对组织及其客户具有最大潜在影响的关键系统和组件。
--
--然而，其他系统中错误的迹象不应被忽视。在为提高可用性而设计的复杂技术环境中，导致事件可能有多种原因，这些原因通常是各类因素组合后产生的结果。非核心系统中，看似不重要的错误可能导致严重事件。主动问题识别应包括对已识别漏洞的发生概率和影响进行仔细评估。
--
--表3.3提供了流程活动的示例。
--
--表3.3 主动问题识别过程的活动
--
--[[image:1639733057971-341.png]]
--
--表3.3 主动问题识别过程的活动
--
--
--谁可以登记问题？
--
--有几种方法可以分配问题登记的职责。一种方法是鼓励每一位专家提出并登记问题。这将增加改进的数量，并提高组织产品中错误的可见性。
--
--但是，这可能会显著增加登记问题的数量，没有人关注这些问题，或者这些问题被错误地分类了。为防止这种情况发生，一些组织更愿意让一个或多个角色负责对潜在问题的初始筛选并进行登记。只要角色中的人员拥有所需的资源，并且可以使来自各种来源的流程信息一致且透明地进行，此方法就有效。
--
--
--=== **3.2.2** **被动问题识别** ===
--
--该流程包括表3.4中列出的活动，并将输入转换为输出。
--
--表3.4 被动问题识别过程的输入，活动和输出
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--有关持续事件的信息
--
--事件记录和报告监控数据
--
--服务配置数据
--
--服务级别协议（SLA）
--)))|(((
--问题登记
--
--问题初步分类与分派
--)))|问题记录
--
--被动问题识别过程的工作流程图如下图3.3所示：
--
--(% style="text-align:center" %)
--[[image:1639733098725-460.png]]
--
--
--被动问题识别使用过去或正在发生事件的相关信息来调查其原因。可能问题是在诊断分析发生中事件的性质遇到难题而触发的。在这种情况下，问题识别和控制可能很紧急，事件管理和问题管理实践在同一个价值流中，同时，它们需要相同（或重叠）的资源，包括团队，工具和过程。
--
--基于对过去事件的分析时，问题的识别可能包括：基于各种角度的统计分析、影响分析和趋势分析。这是为了识别具有可能的共同原因或其他相关性的一组事件。
--
--过程随触发点不同而略有差异。表3.5中说明了这些差异。
--
--表3.5  被动问题识别过程的活动
--
--|**活动**|**由进行中的事件触发**|**由事件记录分析触发**
--|问题登记|(((
--处理该事件的团队确定需要进行问题调查。在某些情况下，问题记录与一个或多个事件记录相关联，以便于跟踪调查。当多个地点的多个事件由不同的团队处理时，需要进行协同进行问题调查，或者由专门的团队进行问题调查时，这一点可能尤为重要
--
--在其他情况下，处理该事件的团队可以继续调查事件的原因，并在事件解决后记录问题。这个问题可能仍然需要登记，特别是导致事件的原因在事件解决过程中没有得到消除，可能导致新的事件发生
--)))|(((
--负责系统、服务或生产的专家团队会定期检查与其职责范围相关的事件记录。如果他们经过分析发现了问题，并进行问题记录的登记。这些情况可能包括：
--
--* 类似事件频发
--* 在目标解析时间之后解决的事件的高百分比
--* 重大事件
--* 可用性低于目标
--)))
--|问题初步分类与分派|(((
--登记问题过程中，进行问题的初步分类。通常包括以下这些内容（如果已知或合理假设）：
--
--* 描述
--* 关联的配置项和或配置项类
--* 预估事件的影响和概率
--* 相关和可能受影响的服务
--* 对组织和客户的影响
--
--如果问题是在诊断分析之前进行登记，则问题将被分配给适当的专家组。
--
--如果问题在诊断分析之后登记，则信息应用包括所做的步骤、结果和问题的当前状态。如果在登记时问题还没有得到解决，则将其分配给适当的组。
--
--
--)))|(((
--登记问题过程中，进行问题的初步分类。通常包括以下这些内容（如果已知或合理假设）：
--
--* 描述
--* 相关事件及其解决方案
--* 关联的配置项和或配置项类
--* 估计未来事件的影响和概率
--* 相关和可能受影响的服务
--* 对组织和客户的影响
--* 估计的事件影响和概率
--
--根据初步的分类，将问题分派到一个负责相关的配置、服务或产品的专家组
--
--
--)))
--
--
--=== **3.2.3** **问题控制** ===
--
--该流程专注于问题的调查。它包括表3.6中所示的活动，并将输入转换为输出。
--
--表3.6 问题控制过程的输入活动和输出
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--问题记录
--
--服务配置数据
--
--配置项、产品和服务等技术信息
--
--事件记录
--
--监控数据
--)))|(((
--问题调查
--
--已知错误沟通
--)))|(((
--问题记录
--
--已知错误
--
--事件解决方案
--)))
--
--图3.4显示了问题控制流程的工作流程图。
--
--图3.4 问题控制流程的工作流程
--
--
--(% style="text-align:center" %)
--[[image:1639733148807-930.png]]
--
--表3.7提供了流程活动的示例。
--
--表3.7 问题控制流程的活动
--
--[[image:1639733190223-917.png]]
--
--组织使用各种分析技术进行问题调查。这些可能包括：
--
--* 根本因分析技术，例如5 Whys分析法、K&F分析以及故障分析树
--* 影响分析技术，例如组件失效影响分析、业务影响分析
--* 风险分析技术。
--
--记住以下一点很重要。单一根源的情况在复杂的、不断发展的环境中具有非常有限的适用性。事件常常是由不可预料的因素经过预料之外的组合后导致的。因此，对问题的调查（尤其是在被动问题管理中）不应仅限于确定事件的一项可能原因。问题调查应始终考虑整个服务管理四维模型。可以在补充ITIL出版物中找到有关使用特定技术进行问题调查的进一步指南。
--
--
--=== **3.2.4** **错误控制** ===
--
--这一过程的重点是监测和控制已知错误（已分析但尚未解决的问题）的状况及其解决方案。它有助于确保已知错误对服务的负面影响得以掌握并使其最小化；有关事件的解决方案是有效的；已知错误的缓解方法是有效的，可行且高效的。
--
--该流程包括表3.8中所示的活动，并将输入转换为输出。
--
--表3.8 错误控制的输入活动和输出流程
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--问题记录
--
--服务配置数据
--
--配置项、产品和服务等技术信息
--
--事件记录
--
--监控数据
--
--知识管理数据
--)))|(((
--问题解决方案开发
--
--问题解决启动
--
--已知错误监控和检查
--
--问题关闭
--)))|(((
--问题记录
--
--问题型号
--
--变更请求
--
--改进计划
--
--问题解决方案
--)))
--
--图3.5显示了流程的工作流程图。
--
--图3.5 错误控制的工作流程
--
--(% style="text-align:center" %)
--[[image:1639733225356-658.png]]
--
--
--表3.9提供了流程活动的示例。
--
--
--表3.9 错误控制的活动流程
--
--|**活动**|**描述**
--|问题解决方案开发|团队（根据问题调查进行分配或重新分配）寻找解决问题的方法。这包括定义消解方法（请参见表2.1）和所选方法中的实际解决方案开发。如果没有针对问题的可行解决方案，则会记录支持信息，并且定期评审错误。
--|启动问题解决|(((
--在大多数情况下，问题需要通过变更解决。负责的团队按照组织初始化和实现变更的程序，提交变更请求。
--
--在其他情况下，所需的操作不归类为变更，可以按照其他过程来启动和执行。无论哪种方式，团队都会启动已定义（如果需要的话，已批准）问题解决所需的操作。可能需要以相关理由支持（包括财务、风险、合规性、技术和其他注意事项）。
--)))
--|已知错误监控和评审|(((
--**如果已知错误的解决方案得到批准**
--
--使用预先商定的标准控制和确认解决方案的实施。这通常由发起解决方案的团队，或其他预先约定的角色，如由问题经理来完成。
--
--对于被动识别的问题，可以根据事件动态的变化（解决或预防相关事件）来完成。对于主动识别的问题，解决控制基于已发起变更是否成功，并可能包括一段时间来监控可能受到错误影响的服务。如果问题的解决方案没有得到确认，团队则返回到该过程的问题解决方案开发步骤。
--
--**如果找不到针对已知错误的可行解决方案**
--
--指定专家团队对已知错误进行监控。这通常是负责与已知错误关联的配置项、服务或产品的团队。该团队按照消解策略中定义的方式的监控已知错误的状况。监控的参数可能包括：
--
--* 相关事件的动态
--* 事件解决方案的有效性
--* 问题解决的有效性
--* 解决问题所需资源状态的变化（预算，供应商，专家的更新，新的基础结构等）。
--
--团队应定期进行问题审查（根据商定的消解方法），或基于监控结果进行问题审查。
--
--如果评审确认消解方法有效且是最新的（问题存在，最新影响评估，事件解决方案有效，问题变通方案有效且没有可行的问题修复程序方案可用），那么继续进行已知错误的监控。
--
--如果消解方法变得无效，则启动问题解决方案开发活动来审查和重新定义消解方法。这可能包括开发和实现一个问题解决方案或更新相关事件的事件解决方案。
--
--如果问题不再存在（例如，已通过计划的软件或硬件更新或通过停用受影响的配置项将其移出），则启动问题关闭。
--
--如果问题出现了一个新状况，建议修改或创建问题模型，并将问题模型将作为问题评审活动的一部分进行记录和交流。
--
--基于监控数据更新问题记录。
--)))
--|问题关闭|(((
--负责问题的团队（或专家）记录问题评审结果并正式关闭问题记录。
--
--如果确认解决，则团队记录解决控制结果并正式关闭问题记录。已关闭问题记录应作为组织的知识库的一部分，尤其是如果有类似的
--
--问题可能会再次发生。
--)))
--
--问题管理活动由服务提供者执行，如表3.3、3.5、3.7和3.9中所述。他们可能涉及供应商和合作伙伴，甚至有时还涉及客户和用户。这些活动可以利用工具和技术支持开展（有时甚至是全自动化或很高程度的自动化）。这些将在以下部分中进行阐述。
--
--
--
--
------
--
--= **4. 组织和人员** =
--
--
--== **4.1** **角色，能力和责任** ==
--
--实践指南没有描述实践管理的角色，例如实践负责人，实践主管或实践教练。相反，他们专注于每个实践的专家角色。组织不同，每个角色的结构和命名也可能不同，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不应被视为推荐性的。请记住角色不是职务。一个人可以担任多个角色，一个角色也可以分配给多个人。
--
--角色是关联到流程和活动中来描述的。每个角色都具有基于表4.1中所示的模型的能力概况特征。
--
--表4.1 能力代码和描述
--
--|能力代码|能力概况（活动和技能）
--|L|**领导者 **决策、授权、监督其他活动，激励团队，提供动力以及评估结果
--|A|**管理员** 分配任务并确定优先级，保留记录，持续报告并启动基本的改进
--|C|**协调员/沟通者** 多方协调，维护干系人之间的沟通，并负责有关认知的宣传活动
--|M|**方法和技术专家** 设计和实施技术工作，编织规范文档，提供流程、工作分析和持续改进的咨询
--|T|**技术专家** 提供技术（IT）专业知识，并执行基于专业知识的任务
--
--在组织中可以设定两个实践特定的角色：问题经理和问题协调人。这些角色通常在问题数量很多的组织中引入。在其他组织中，问题管理活动由负责与问题关联配置项的服务或产品的个人或团队协调。，可能是资源所有者，服务负责人或产品负责人。
--
--
--=== **4.1.1** **问题经理角色** ===
--
--在定义专门的问题经理角色的情况下，通常将其分配给专家，这些专家结合了组织产品（架构，配置和相互依赖性）的丰富知识以及扎实的分析技能（协调团队合作并提供出色风险管理的能力和权威）。该角色的能力概要是TMAC。角色通常负责管理和协调问题管理流程中的专家活动，包括：
--
--* 根据提交的信息进行和协调问题登记
--* 问题的初步分类
--* 与负责事件解决和变更实施的团队协调沟通
--* 开发和交流问题模型（如适用）
--* 协调已知错误监视和评审
--* 问题规范的关闭
--
--
--=== **4.1.2 问题协调人角色** ===
--
--在较复杂的组织中，问题管理实践的某些职责可以委托给问题协调人。问题协调人专注规范的问题管理，例如，对提交的关于可能出现的问题的信息评审、问题评审和问题关闭。
--
--表4.2中列出了问题管理活动中可能涉及的其他角色的示例，以及相关的能力概况和特定技能。
--
--表4.2 负责问题管理活动的角色示例
--
--|**活动**|**负责角色**|**能力类型**|**特点技能**
--|(% colspan="4" %)(((
--主动问题识别流程
--
--
--)))
--|(% rowspan="5" %)评审提交的信息|CI 所有者|(% rowspan="5" %)T|(% rowspan="5" %)对产品的深入了解，包括架构和配置
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|(% rowspan="5" %)问题登记|CI 所有者|(% rowspan="5" %)TA|(% rowspan="5" %)了解登记工具和程序
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|(% rowspan="5" %)问题初步分类与分派|CI 所有者|(% rowspan="5" %)TAC|(% rowspan="5" %)熟悉产品，服务架构和业务影响，了解团队中的职责和能力
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|(% colspan="4" %)被动问题标识流程
--|(% rowspan="5" %)问题登记|CI 所有者|(% rowspan="5" %)TA|(% rowspan="5" %)了解注册工具和程序
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|(% rowspan="5" %)问题初步分类与分派|CI 所有者|(% rowspan="5" %)TAC|(% rowspan="5" %)熟悉产品，服务架构和业务影响，了解团队中的职责和能力
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|(% colspan="4" %)问题控制流程
--|(% rowspan="7" %)问题调查|CI 所有者|(% rowspan="7" %)CT|(% rowspan="7" %)(((
--熟悉产品、服务架构和业务影响
--
--熟悉诊断、调查和分析方法和工具
--)))
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|供应商
--|技术专家
--|(% rowspan="4" %)已知错误沟通|CI 所有者|(% rowspan="4" %)TC|(% rowspan="4" %)了解利益相关者和责任，了解沟通工具和程序
--|事件经理
--|问题协调人
--|问题经理
--|(% colspan="4" %)错误控制流程
--|(% rowspan="5" %)问题解决方案开发|CI 所有者|(% rowspan="5" %)TMC|(% rowspan="5" %)(((
--良好的产品和服务架构、配置和技术细节知识
--
--创造力
--
--系统思维
--)))
--|问题协调人
--|问题经理
--|(((
--产品负责人
--
--服务负责人
--
--供应商
--)))
--|技术专家
--|(% rowspan="6" %)问题解决启动|CI 所有者|(% rowspan="6" %)CT|(% rowspan="6" %)无需特定技能
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|技术专家
--|(% rowspan="6" %)已知错误监控和评审|CI 所有者|(% rowspan="6" %)TAC|(% rowspan="6" %)熟悉产品和服务架构及业务影响
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--|技术专家
--|(% rowspan="5" %)问题关闭|CI 所有者|(% rowspan="5" %)TCA|(% rowspan="5" %)熟悉产品、服务架构和业务影响
--|问题协调人
--|问题经理
--|产品负责人
--|服务负责人
--
--
--== **4.2** **组织结构和团队** ==
--
--尽管问题管理的角色有时与正式职称相关联，但问题管理实践的专用组织结构却很少见。这对于具有复杂官僚机构和大量需要管理的问题的组织来说是典型的。许多组织发现组建临时团队调查影响度高的问题和/或开发解决方案很有用。
--
--在以产品为中心的组织中，通常不采用问题管理工作的头衔和角色。相反，这种实践被集成到产品开发和管理团队的日常活动中。它在任何可能的地方都是自动化的。
--
--
--
------
--
--= **5. 信息和技术** =
--
--
--== **5.1 信息交流** ==
--
--问题管理实践的有效性取决于所使用信息的质量。该信息包括但不限于以下信息：
--
--* 产品和服务及其架构和设计，包括配置信息
--* 客户和用户
--* 合作伙伴和供应商，包括有关它们提供的服务的合同和SLA信息
--* 正在进行和发生的事件
--* 计划的，正在进行的和发生的变更
--* 第三方的产品和组件，包括漏洞和事件。
--
--这些信息可能以各种形式出现。实践的关键输入和输出在第3节中列出。
--
--
--
--== **5.2 自动化和工具** ==
--
--在大多数情况下，问题管理实践可以从自动化中受益匪浅。在可行且有效的情况下，可能涉及表5.1中概述的解决方案。
--
--表5.1 问题管理活动的自动化解决方案
--
--|(% rowspan="2" %)**活动流程**|(% rowspan="2" %)**自动化手段**|(% rowspan="2" %)**关键功能**|(% rowspan="2" %)**对实践的效果**
--|
--|(% colspan="4" %)(((
--主动问题识别流程
--
--
--)))|
--|评审提交的信息|监控和事态管理工具，用户门户和其他用户接口，工作流程管理和协作工具|收集和概述来自各种来源的信息，包括数据分析和协作团队|高|
--|问题登记|工作流程管理和协作工具|与其他服务管理数据集成的问题记录的管理|高|
--|问题初步分类与分派|工作流程管理和协作工具以及配置管理工具|将问题管理记录与其他服务管理记录、待办项管理、沟通和协同支持集成在一起|高|
--|(% colspan="2" %)被动问题标识流程| | |
--|(% rowspan="2" %)问题登记|(% rowspan="2" %)(((
--工作流程管理和协作工具
--
--
--)))|(% rowspan="2" %)基于机器学习的问题识别基于对过去和正在发生的事件的分析，将问题管理记录与其他服务管理数据集成在一起的|(% rowspan="2" %)高|
--|
--|问题初步分类和分配|工作流程管理和协作工具以及配置管理工具|将问题管理记录
--与其他服务管理数据、待办项管理、沟通、协同支持和CI影响评估集成在一起|高|
--|(% colspan="4" %)问题管理流程|
--|问题调查|诊断和分析工具，以及配置管理工具|依赖关系分析假设分析，因果分析和建模|高|
--|已知错误沟通|工作流程管理和协作工具|沟通与协作支持|中|
--|(% colspan="4" %)错误控制管理流程|
--|问题解决方案开发|诊断和分析工具，配置管理工具和设计工具|解决方案设计和验证|中到非常高，取决于在解决方案架构|
--|问题解决初始化|工作流程管理和协作工具|沟通与协作支持|中|
--|已知错误监控和评审|监控和事态管理工具，工作流程管理和协作工具以及自动化测试工具|收集和概述来自各种来源，数据分析以及团队协作验证的信息，以确定存在已知错误和解决方法|中到高|
--|问题关闭|工作流程管理和协作工具|沟通和协作支持，自动发布到协作工具中|中|
--
--
--
--
------
--
--= **6. 合作伙伴和供应商** =
--
--组织完全使用自己资源提供服务的这种情况很少。大多数(不是全部)依赖于其他服务。这些通常:是由第三方提供的(请参阅ITIL Foundation：ITIL 4 Edition的2.4节服务关系的模型)。在实践指南中，针对服务设计、架构管理和供应商管理引入了支持服务的依赖关系。所有问题管理流程中都使用了有关对第三方服务的依赖性的信息。
--
--问题管理实践通常会发现组织使用的第三方产品中的错误。解决这些错误的可能性以及解决方案的有效性，取决于多种因素，包括：
--
--* 解决方案的架构
--* 供应商的灵活性
--* 供应商与组织的服务关系的重要性
--* 合同条款和条件
--
--了解组织如何依赖第三方组件，以及如何与包括问题管理实践在内的许多活动的主要供应商和合作伙伴建立有效，高效的协作至关重要。
--
--问题模型应定义第三方如何参与问题控制，以及组织如何确保有效的协作。这取决于产品，服务和价值流的架构和设计解决方案。通常，在为问题选择了正确的模型之后，需要在问题和错误控制过程中进一步考虑第三方依赖关系。
--
--当组织的目标是确保快速和有效的问题管理时，他们通常试图与合作伙伴和供应商达成紧密合作，消除沟通，协作和决策制定方面的正式官僚障碍（有关更多信息，请参见供应商管理实践指南）。
--
--
--
--
------
--
--= **7. 重要提醒** =
--
--实践指南的大部分内容都可以作为组织在建立和培养自己实践时提供可参考的建议。实践指南为组织提供了解决问题的框架，而不是答案本身。使用实践指南时，组织应始终遵循ITIL指导原则：
--
--* 专注于价值
--* 从你现在的位置开始
--* 基于反馈迭代推进
--* 协作并提升可视化程度
--* 通盘思考和工作
--* 保持简单实用
--* 优化和自动化。
--
--有关指导原则及其应用程序的更多信息，请参见ITIL 4基础版中的第4.3节
--
--
--
------
--
--= **8. 致谢** =
--
--AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
--
--
--== **8.1** **作者** ==
--
--Barry Corless, Roman Jouravlev, Andrew Vermes.
--
--
--== **8.2** **审稿人** ==
--
--James Ainsworth，Akshay Anand，Sofi Fahlberg，Michael G.Hall，Steve Harrop，Piia Karvonen，Anton Lykov，PaulaMättänen，Caspar Miller，Christian F.Nissen，Mark O'Loughlin，Tatiana Orlova，Elina Pirjanti，Stuart Rance。
--
--

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司