问题经理确定根本原因并消除重复性问题

用例概览

角色：问题经理，负责确定系统原因，协调调查，并防止服务重复中断

要完成的工作：将重复性事件连接到单个问题记录，建立并记录根本原因，并推动永久修复或明确的风险决策

起点：事件历史、服务数据或操作趋势表示重复出现相同或相关的中断

成功结果：问题具有受支持的根本原因分析，相关事件和补救记录可以跟踪，受影响的用户已批准指导，并且变更后的证据表明重复或影响已经减少。

使用此场景确定是否理解和控制了重复出现的问题。对于创建和关联记录、更新问题分析、记录解决方法、创建变更请求、接受风险、重新打开问题和关闭问题的步骤，使用相关帮助主题。

检测值得调查的模式

从共享基础条件的证据开始，而不仅仅是事件的数量。比较症状、错误签名、受影响的服务和配置项目 (CI)、时间、最近更改、用户群、解决方法和服务恢复后的重复。相似的措辞可以描述不同的原因，而不同措辞的事件可以源自相同的失败。

使用问题仪表板查找趋势、未处理工作、违反服务级别协议 (SLA)、未分配的记录、解决时间和解决代码模式。将仪表板信息视为调查潜在客户，而不是事件共享原因的证明。有关仪表板度量的详细信息，请参阅适用于 IT 服务的问题管理器仪表板。

在不延迟恢复的情况下确定问题

事件管理为每个活动中断恢复服务。问题管理会调查并消除系统原因。将这些结果分开：事件可以通过解决方法解决，而其相关问题保持开放，问题不应该仅仅因为最近的事件停止影响用户而关闭。

创建或选择一个在适当范围内描述重复病情的问题。确认主题、描述、类别、子类别、受影响的服务和 CI、影响、紧迫性、优先级、所有者和调查状态。关联支持事件和其他相关问题、变更请求、发布或 Knowledge 文章，以便调查人员区分证据和巧合。

避免为每个事件创建一个问题，或者为不相关的故障创建一个广泛的问题。仅在可用证据支持关系时使用关联，例如“原因”和“相似”。

如果启用了“关联类似问题”主动操作，它可以根据语义相似性自动关联问题记录。类似关联不会建立“原因”关系。在使用它们作为共享根本原因的证据之前，检查自动关联的问题。

要手动关联记录，请打开问题。在“关联”选项卡上，单击关联，然后选择记录类型和关系类型，例如原因或相似。删除关联不会删除关联的记录。解决独立于链接，可以关闭多个相关记录，因此在单击解决之前查看选定记录。

有关创建和关联问题、解决问题、接受风险和重新打开问题的步骤，请参阅管理 IT 服务的问题。要直接从事件创建问题，请参阅管理 IT 服务事件。

调查并确定根本原因

根据事件时间线、日志、遥测、配置和资产数据、最近更改、已知错误、Knowledge 文章和主题专业知识构建可测试的解释。尽可能安全地重现故障。比较受影响和不受影响的情况，质疑相互竞争的解释，并记录哪些证据证实或否定了每个假设。

记录原因链，而不是重复症状。解释失败的条件、它产生观察到的影响的原因、受影响的范围以及问题可以重复出现的条件。引用支持结论的记录或测试。标记未解决的假设并分配后续工作，而不是将推理作为事实。

在不影响调查质量的情况下跟踪配置的根本原因重大事件。标准问题 SLA 会跟踪关键和高优先级问题的根本原因完成时间，但贵组织的策略会有所不同。完成重大事件并不证明分析是正确的。请参阅适用于 IT 服务的问题的 SLA 策略。

通过解决方法或已知错误减少影响

当安全的临时方法减少中断时，记录其适用性、先决条件、步骤、限制、风险和验证结果，以及问题的解决方法信息。使指导对事件履行者可用，以便他们可以在永久修复待处理时一致地恢复服务。

当已确认的根本原因和可重复使用的解决方法必须在问题记录之外可用时，创建或更新有关已知错误的 Knowledge 文章。删除特定于记录的敏感详细信息，通过配置的审核流程路由文章，并验证预期的支持受众可以找到它。解决方法控制症状或影响；它不会消除根本原因。

如果不存在安全的解决方法，请明确表示并加强监控、升级、通信和恢复准备。使用 Knowledge 文章向目标受众提供经过验证的临时解决方法。请参阅IT 服务中关键工作流。

通过受控更改消除原因

在充分证据支持根本原因和补救措施后，从问题创建并关联变更请求。包括受影响的范围、原因证据、建议的修复、实施要求、测试计划、回滚方法、计划约束和验证条件。在变更通过风险评估、批准、计划、实施和验证进行时，保持问题悬而未决。

变更结果必须测试原因索赔。请确认目标条件如预期改变，服务运行状况保持可接受，不需要回滚或回滚成功，并且没有出现重大副作用。如果重复出现的故障继续存在，成功实施的更改是不够的。

当永久解决方案不可行时，只有在适当的利益相关者了解剩余影响、可能性、当前控制、所有权和审查条件后，才使用接受风险。记录触发监控或重新打开的理由和条件。风险接受是受控制的决策，而不是不完整分析的替代。有关变更请求和风险接受步骤，请参阅管理 IT 服务问题。

验证减少重复和结束

观察适合原始重复模式的时间段和数量。比较补救前后的事件频率、受影响的用户或事务、错误率、停机时间、解决方法的使用、支持工作和服务级别结果。在将改进归因于修复之前，请考虑季节性、流量、发布和报告变化。

仅在记录包含支持的根本原因、解决方案信息、关联事件和补救措施、验证证据、剩余风险和可重用 Knowledge 时关闭问题。根据贵组织的流程解决相关关联，同时保留历史。在问题重复出现、原因解释被推翻或新证据更改所需操作时，重新打开问题。

当经过验证的补救或明确的风险决策导致可跟踪地减少重复或影响时，问题管理就是成功的。仅关闭问题、发布文章或完成更改不会显示重复性问题已消除。

将 AI 用作帮助，而不是证据

配置后，Einstein 可以从事件中起草问题，Agentforce 操作可以汇总问题、检查属性、查找相关记录、提出解决方案并起草根本原因或解决方案汇总。在保存或操作之前，请查看生成的字段和关联。

生成的汇总和建议的修复不是经过验证的根本原因证据。根据日志、记录、测试、受信任的 Knowledge 来源和主题专家，确认每个重要声明。保留语义匹配、似是而非的假设和已证明原因之间的区别。见使用 Einstein 自动创建事件问题、AI 问题管理操作和 IT 问题主动操作。

确认问题管理准备就绪

在更广泛地部署此流程之前，请确认问题管理及其字段验证、优先级矩阵、记录布局、关联、仪表板和 SLA 支持您的流程。此外，请确认配置了所需的 Knowledge、变更管理和配置管理数据库 (CMDB) 组件。Einstein、Agentforce 和主动操作是需要单独设置和权限的可选功能。

分配适当的问题经理或问题履行者权限集小组。还要分配接受风险、重新打开问题、关联事件、变更请求和发布与问题以及解决关联所需的权限。请参阅设置 IT 服务问题管理和 IT 服务问题管理权限集。

在更广泛地部署之前，请验证配置。确认授权用户可以找到问题记录和仪表板，检查分析和解决字段，并查看相关事件和其他关联。确认适当的变更请求和风险操作对记录的状态可用，以及任何配置的 Knowledge 和 AI 帮助。在测试时，退出任何创建、编辑、调查问卷、生成、批准或关闭流，无需保存更改。