3.2問題管理

前節のインシデント管理が「まず止血して回復させる」役だとすれば、問題管理は「なぜ出血したのかを突き止め、二度と起きないようにする」役です。同じ障害が繰り返すのに毎回ワークアラウンドで凌ぐだけでは、いつまでも根が絶えません。この節では、インシデント管理と問題管理の目的の違いを明確にしたうえで、どの時点でインシデントを問題へ昇格させ、根本原因分析をどう進め、蓄積した知見（KEDB）を次のインシデント対応にどう還元するかという判断を学びます。

3.2.1インシデント管理との目的の違い

3.2.2根本原因分析とKEDB

• 問題＝1つ以上のインシデントの根本原因（またはその可能性のあるもの）。繰り返し発生するインシデントや、原因不明の重大インシデントを問題として起票し、根本原因分析（RCA）（なぜなぜ分析・時系列分析等）で真因を突き止める。
• 既知の誤り（known error）＝根本原因が判明し、かつ回避策（ワークアラウンド）が確立された問題。これらを蓄積したものが既知の誤りデータベース（KEDB）。同種のインシデントが再発した際、KEDBを参照すれば原因調査を省いて即座に既知の回避策を適用でき、回復時間を大幅に短縮できる。
• 恒久対策は多くの場合、構成の変更を伴うため変更管理（次章／設計・移行の領域）と連携して実施される。恒久対策が完了し原因が除去されれば、その問題はクローズできる。

3.2.3リアクティブとプロアクティブ

• リアクティブ問題管理＝インシデントが発生した後に、その原因を分析して再発を防ぐ事後型の活動。障害の発生が起点となる。
• プロアクティブ問題管理＝インシデントの傾向分析やログ・監視データからまだ顕在化していない潜在的な問題を先回りで発見し、障害が起きる前に対処する予防型の活動。「同じ警告が増えている」「ディスク使用率が上昇傾向」といった兆候から手を打つ。

あるサービスマネージャが、過去1か月で「特定のWebサービスが深夜に応答しなくなり、再起動で回復する」というインシデントが5回繰り返していることに気づいたとします。毎回のインシデント対応では、SLAの停止時間を守るため再起動というワークアラウンドで迅速に回復させており、それ自体は正しい判断です。しかし同じ障害が繰り返す以上、再起動で凌ぎ続けるだけでは根本的な解決になりません。ここでサービスマネージャは、この繰り返すインシデント群を1つの問題として起票し、問題管理へ移します。根本原因分析（RCA）を進めると、深夜のバックアップジョブとアプリのメモリ解放処理が競合し、メモリリークで応答不能に陥っていることが判明しました。原因（メモリリーク）と回避策（再起動、あるいは深夜バックアップの時間帯変更）が確立した時点で、これは既知の誤りとしてKEDBに登録します。以降、同種のインシデントが再発しても、サービスデスクはKEDBを参照して原因調査を省き即座に回避策を適用でき、回復時間を短縮できます。最終的な恒久対策（アプリのメモリ解放処理の修正）は構成変更を伴うため変更管理と連携して実施し、原因が除去されれば問題をクローズします。さらにサービスマネージャは、他のサービスでも同様のメモリ使用率の上昇傾向がないかを監視データからプロアクティブに点検し、まだ障害化していない潜在問題を先回りで摘み取ります。「回復を優先しつつ、繰り返す兆候を捉えて問題として根本原因を潰し、知見をKEDBに残す」——これがインシデント管理と問題管理を正しく連携させるサービスマネージャの判断です。

3.2.4この節のまとめ

• 問題管理の目的は根本原因の特定と恒久対策による再発防止であり、迅速な回復を目的とするインシデント管理と明確に対をなす
• 繰り返すインシデントを問題として起票しRCAで真因を特定、原因と回避策はKEDBへ登録して再発時の回復を短縮する
• 障害後に原因を潰すリアクティブと、傾向分析で潜在問題を先回りするプロアクティブを使い分ける