3.1インシデント管理

サービス停止や品質低下が起きたとき、サービスマネージャがまず問われるのは「なぜ壊れたのか」ではなく「どれだけ早く合意した水準へ戻せるか」です。インシデント管理の目的はサービスの迅速な回復であり、恒久的な原因究明は次節の問題管理の役目です。この節では、限られた要員とSLA目標の制約下で、どのインシデントから対処し、いつ誰へ引き継ぎ、根本原因が分からないうちに何をもって「回復」とするかという運用判断を学びます。

3.1.1目的は根本原因究明ではなく迅速な回復

• インシデント＝サービスの計画外の中断、または品質の低下（合意した水準を満たさない事象）。インシデント管理の唯一の目的は、事業への影響を最小化しつつ可能な限り迅速に通常のサービス運用へ回復させること。
• 根本原因の特定や恒久的な再発防止は目的ではない——それは次節の問題管理が担う。回復のために原因を完全に理解する必要はなく、再起動や代替経路への切替といったワークアラウンド（暫定回避策）で症状を解消できれば、そのインシデントは「解決（回復）」とみなしてよい。
• 回復（サービスが動く状態に戻す）と、恒久解決（二度と起きないようにする）を混同しないことが要点。回復を最優先し、原因の追究は問題管理へ引き渡すことで、SLAで合意した停止時間の上限を守りやすくなる。

3.1.2優先度＝影響度×緊急度とエスカレーション

• 優先度は影響度（影響を受ける利用者数・業務の重要度）と緊急度（対処までに許される時間の短さ）の掛け合わせで決める。受付順（FIFO）ではなく、この優先度に従って対処順を並べ替えるのが原則。
• 機能的エスカレーション（水平）＝一次窓口（サービスデスク）で解決できないインシデントを、専門知識を持つ二次・三次の技術グループへ引き渡すこと。階層的エスカレーション（垂直）＝重大な影響や権限判断が必要な場合に、管理者・上位職へ通知・判断を仰ぐこと。両者は目的が異なる。
• 重大インシデント（major incident）＝影響度・緊急度がともに高いインシデント。通常のフローとは別に、専任の指揮者を立て、関係者を招集し、迅速な回復に資源を集中させる別立ての手順を発動する。

あるサービスマネージャが、月末の請求バッチ稼働中に「基幹の販売管理システムが応答しない」という通報を受けたとします。同時刻に「社内の1利用者が壁紙を変更できない」という軽微な通報も届いています。ここでまず行うべきは原因の解析ではなく、影響度×緊急度による優先度付けです。販売管理システムは全営業部門（数百名）が使用し、月末処理という時間的猶予のない業務であるため影響度・緊急度ともに最高——これは重大インシデントとして別立ての手順を発動し、専任指揮者のもとで回復に資源を集中します。壁紙の件は影響度・緊急度ともに低く、後回しでSLA違反にはなりません。販売管理システムについては、一次窓口では復旧できないため専門のインフラチームへ機能的エスカレーションし、同時に事業影響が大きいため部門長へ階層的エスカレーションして状況を通知します。調査の結果、原因は特定できないもののDBコネクションプールの枯渇が疑われ、サービスを再起動すると一時的に回復することが分かりました。ここでサービスマネージャは、根本原因が未解明でもワークアラウンド（再起動）で回復させることを選び、SLAの停止時間上限内にサービスを戻します。そして「なぜコネクションが枯渇するのか」という根本原因の究明と恒久対策は、インシデントを問題管理へ引き渡して別途進めます。回復（インシデント管理）と原因究明（問題管理）を明確に分離し、まず回復を優先する——これが同時多発する障害を捌くサービスマネージャの中核判断です。

3.1.3この節のまとめ

• インシデント管理の目的はサービスの迅速な回復であり、根本原因の究明ではない（それは問題管理）
• 優先度＝影響度×緊急度で対処順を決め、機能的エスカレーション（専門グループ）と階層的エスカレーション（上位者）を使い分ける
• 根本原因が未特定でもワークアラウンドで症状を解消すれば回復とみなし、原因究明は問題管理へ引き渡す