問題マネージャーによる根本原因の特定と繰り返し発生する問題の削除

一目でわかる使用事例

人格: 全身的な原因の特定、調査の調整、サービスの定期的な中断の防止を担当する問題マネージャー

実行すべき作業: 定期的なインシデントを 1 つの問題レコードに関連付け、根本原因を確立して文書化し、永続的な修正または明示的なリスクの判断を促す

開始点: インシデント履歴、サービスデータ、または運用トレンドは、同じ中断または関連する中断が繰り返し発生していることを示します。

成功: 問題の根本原因分析がサポートされ、関連するインシデントと修復レコードを追跡可能で、影響を受けるユーザーがガイダンスを承認し、変更後の証拠で再発または影響が減少したことが示されています。

このシナリオを使用して、繰り返し発生する問題を把握して制御しているかどうかを判断します。関連するヘルプトピックを使用して、レコードの作成と関連付け、問題分析の更新、回避策の文書化、変更要求の作成、リスクの受け入れ、問題の再オープン、クローズの手順を確認します。

調査する価値のあるパターンの検出

インシデント数のみではなく、共通の根本状態の証拠から開始します。症状、エラー署名、影響を受けるサービスと設定項目 (CI)、タイミング、最近の変更、ユーザー母集団、解決策、サービス復元後の繰り返しを比較します。同様の表現では異なる原因を説明できますが、異なる表現のインシデントは同じ失敗から発生する可能性があります。

問題ダッシュボードを使用して、トレンド、進行中の作業、サービスレベル契約 (SLA) 違反、未割り当てのレコード、解決時間、解決コードパターンを見つけます。ダッシュボード情報は、インシデントが原因を共有している証拠ではなく、調査リードとして扱います。ダッシュボード総計値についての詳細は、「Problem Manager Dashboard for IT Services (IT サービスの問題マネージャーダッシュボード)」を参照してください。

回復を遅らせずに問題を確立する

インシデント管理では、アクティブな中断ごとにサービスが復元されます。問題管理では、全身的な原因を調査して削除します。インシデントは関連する問題が未解決のまま回避策で解決できますが、最新のインシデントがユーザーに影響しなくなったからといって問題をクローズすべきではありません。

適切な範囲で繰り返し発生する条件を説明する問題を 1 つ作成または選択します。件名、説明、カテゴリ、サブカテゴリ、影響を受けるサービスと CI、影響、緊急度、優先度、所有者、調査状況を確認します。調査担当者が証拠と偶然を区別できるように、サポート・インシデントやその他の関連する問題、変更要求、リリース、Knowledge記事を関連づけます。

インシデントごとに 1 つの問題を作成したり、関連のない障害に対して広範な問題を 1 つ作成したりすることは避けてください。[原因] や [類似] などの関連付けは、使用可能な証拠でリレーションがサポートされている場合にのみ使用します。

[類似問題を関連付け] プロアクティブアクションが有効になっている場合、セマンティック類似性に基づいて問題レコードを自動的に関連付けることができます。類似する関連付けでは、[原因] リレーションは確立されません。共通の根本原因の証拠として使用する前に、自動的に関連付けられた問題を確認します。

レコードを手動で関連付けるには、問題を開きます。[関連付け] タブで、[関連付け] をクリックし、[原因] や [類似] などのレコードタイプとリレーションタイプを選択します。関連付けを削除しても、関連付けられたレコードは削除されません。[解決] はリンクとは異なり、複数の関連レコードを閉じることができるため、[解決] をクリックする前に選択したレコードを確認します。

問題の作成と関連付け、問題の解決、リスクの受け入れ、問題の再開の手順については、「IT サービスの問題の管理」を参照してください。インシデントから直接問題を作成するには、「Manage Incidents for IT Services (IT サービスのインシデントの管理)」を参照してください。

根本原因の調査と確立

インシデントのタイムライン、ログ、テレメトリー、構成および納入商品データ、最近の変更、既知のエラー、Knowledge記事、専門分野の専門知識からテスト可能な説明を作成します。可能な場合は、障害を安全に再現します。影響を受ける状態と影響を受けない状態を比較し、競合する説明に異議を唱え、各仮説を確認したり却下したりする証拠を記録します。

症状を繰り返すのではなく、原因チェーンを文書化します。失敗した状態、観測された影響が生じた理由、影響を受けた範囲、問題が再発する可能性のある条件を説明します。結論を支持するレコードまたはテストを引用する。推測を事実として提示するのではなく、未解決の仮定をマークしてフォローアップ作業を割り当てます。

調査品質を損なうことなく、設定された根本原因マイルストーンを追跡します。標準の問題 SLA では、重大問題と優先度高の問題の根本原因完了時間を追跡しますが、組織のポリシーは異なる可能性があります。マイルストーンを完了しても、分析が正しいことを証明するものではありません。「SLA Policy for Problem for IT Services」を参照してください。

回避策または既知のエラーによる影響の軽減

安全な一時的な方法によって中断が軽減される場合、問題の回避策情報でその適用性、前提条件、ステップ、制限、リスク、検証結果を文書化します。インシデント履行者が永続的な修正の待機中に一貫してサービスを復元できるように、ガイダンスを使用できるようにします。

問題レコード以外に確認済みの根本原因と再利用可能な回避策を使用する必要がある場合、既知のエラーに関するKnowledge記事を作成または更新します。レコード固有の機密情報を削除し、設定されたレビュープロセスで記事を転送して、対象のサポート利用者が記事を見つけられることを確認します。回避策は症状や影響を制御しますが、根本的な原因を排除するものではありません。

安全な回避策が存在しない場合は、監視、エスカレーション、コミュニケーション、およびリカバリの準備を明示的に強化することを明記します。Knowledge 記事を使用して、検証済みの一時的な回避策を対象利用者に提供します。「Key Workflows in IT Services」を参照してください。

制御された変更による原因の排除

十分な証拠が根本原因と修復をサポートしたら、問題から変更要求を作成して関連付けます。影響を受ける範囲、原因証拠、修正案、実装要件、テスト計画、ロールバック方法、スケジュール制約、検証条件を含めます。変更がリスク評価、承認、スケジュール、実装、検証で進行する間、問題をオープンにしておきます。

変更結果は原因請求をテストする必要があります。対象条件が意図したとおりに変更されたこと、サービスの健全性が許容範囲内に保たれていること、ロールバックが不要または成功したこと、重大な副作用が発生していないことを確認します。繰り返しの失敗が続く場合、正常に実装された変更では不十分です。

恒久的なソリューションが実行不可能な場合は、適切な関係者が残留の影響、可能性、現在のコントロール、所有権、レビュー条件を把握した後にのみ、リスクの受け入れを使用します。監視または再開をトリガーする理由と条件を記録します。リスクの受け入れは管理された決定であり、不完全な分析に代わるものではありません。変更要求とリスク受け入れの手順については、「IT サービスの問題の管理」を参照してください。

定期的な削減とクローズの確認

元の繰り返しパターンに適した期間と量でサービスを監視します。修復前後のインシデント頻度、影響を受けるユーザーまたはトランザクション、エラー率、ダウンタイム、回避策の使用、サポート工数、サービスレベルの結果を比較します。修正の改善を帰結する前に、季節性、トラフィック、リリース、変更の報告を考慮します。

サポートされている根本原因、解決情報、関連するインシデントと修復、検証証拠、残存リスク、再利用可能なKnowledgeがレコードに含まれている場合にのみ、問題をクローズします。組織のプロセスに従って関連する関連付けを解決しながら、その履歴を保持します。問題が再発したとき、原因の説明が反証されたとき、または新しい証拠によって必要なアクションが変更されたときに、問題を再オープンします。

問題管理は、検証済みの修正または明示的なリスク判断によって、再発や影響を追跡可能な範囲で低減できれば成功です。問題をクローズしたり、記事を公開したり、変更を完了したりしても、繰り返し発生する問題が解消されたとは表示されません。

証拠ではなく支援としての AI の使用

設定すると、Einstein はインシデントから問題のドラフトを作成でき、Agentforce アクションで問題の要約、属性の確認、関連レコードの検索、解決策の提案、根本原因または解決策の概要のドラフト作成を行うことができます。保存または操作する前に、生成された項目と関連を確認します。

生成された概要と提案された修正は、検証された根本原因証拠ではありません。ログ、レコード、テスト、信頼できるKnowledge Source、専門分野のエキスパートに対してすべての資料請求を確認します。セマンティック一致、もっともらしい仮説、実証された原因の区別を維持します。「 Einstein を使用したインシデントからの問題の自動作成」、「 問題管理の AI アクション」、および「 IT 問題に対するプロアクティブなアクション」を参照してください。

問題管理の準備ができたことを確認する

このプロセスをより広範にリリースする前に、問題管理とその項目検証、優先度マトリックス、レコードレイアウト、関連付け、ダッシュボード、SLA でプロセスがサポートされていることを確認します。必要なKnowledge、変更管理、CMDB(構成管理データベース)コンポーネントが設定されていることも確認します。Einstein、Agentforce、およびプロアクティブ アクションは、個別の設定と権限を必要とする省略可能な機能です。

適切な「Problem Manager」または「Problem Fulfiller」権限セットグループを割り当てます。また、リスクの受け入れ、問題の再開、インシデント、変更要求、リリースの問題との関連付け、関連付けの解決に必要な権限を割り当てます。「Set Up Problem Management for IT Services and Problem Management Permission Sets for IT Services (IT サービスの問題管理権限セットの設定)」を参照してください。

より広範にリリースする前に設定を検証します。承認されたユーザーが問題レコードとダッシュボードを検索できることを確認し、分析項目と解決項目を調べて、関連するインシデントとその他の関連付けを表示できます。レコードの状態に適した変更要求とリスク アクションが、設定済みのKnowledgeおよびAI支援と共に使用できることを確認します。テスト時に、変更を保存せずに作成、編集、アンケート、生成、承認、またはクローズフローを終了します。