SGのインシデント管理・問題管理・サービス要求管理の違いを図解

現行SGシラバスVer.4.1には、インシデント管理、サービス要求管理、問題管理が並び、回避策、根本原因、予防処置、傾向分析などが用語として挙がっています。日常語ではどれも「問題への対応」と言えますが、サービス管理では何を目的に、何の状態を記録するかが違います。

Atlassianの公式資料は、サービスの早期回復と、背景にある原因の調査・再発防止を区別しています。また、新たな利用権や機器などを求めるサービス要求を、予定外のサービス中断とは分けて説明しています。本記事では製品の画面や特定版のITIL手順の暗記ではなく、SGのケースを読む際の目的と記録の違いを整理します。

以下は全て当サイト独自の架空ケースです。実在の障害や公式問題を再現していません。サービス管理でいうインシデントは、サイバー攻撃だけを指す言葉ではありません。一方、不正操作や情報漏えいの疑いがあれば、通常の不具合として処理を急ぐのではなく、組織のセキュリティ対応手順にもつなげる必要があります。

インシデント管理では、意図したサービスが使えない、著しく遅いといった支障を受け、影響と優先度を確認して回復を進めます。原因が完全に解明される前でも、許可された回避策によって影響を抑えられる場合があります。ただし、速さを理由に必要な安全確認や記録を省いてよいわけではありません。

問題管理では、一つ又は複数のインシデントの原因や潜在的な原因を調べ、対応を検討します。毎回同じ回避策で復旧できても、原因が残れば繰り返す可能性があります。調査は復旧の完了後にしか始められないものではなく、役割を分けて並行して進めることもあります。

サービス要求管理では、利用者からの定められた依頼を扱います。例えば入社者へ施設予約サービスの利用を追加する申請です。受付窓口が障害対応と同じでも、本人・利用目的・必要な承認・付与する範囲を確認する目的は変わりません。「使いたい」という連絡を、すべて既存サービスの故障と決めないようにします。

架空の総務部で、施設予約サービスKの送信処理が月曜9時に失敗しました。担当者はインシデントINC-01として影響と発生条件を記録し、権限のある運用担当者が承認された回避策を適用しました。9時10分、対象の予約操作と記録の整合を確認して回復を報告しました。根本原因はまだ不明という条件です。

火曜9時にも似た失敗が起き、INC-02として記録し、確認の結果9時8分に回復しました。前日に「復旧」としたこと自体が、直ちに虚偽だったわけではありません。月曜の確認範囲でサービスが回復した事実と、翌日に再発した事実を、それぞれ残します。ただし月曜の時点で「原因まで解消した」と記載するのは、根拠が不足しています。

問題PRB-01の記録では、二件の発生時刻、対象操作、構成、ログ、適用した回避策と効果を関連付けて調べます。同じエラー表示だけで同じ原因とは断定できません。例えば別の利用者が通信断で同様の表示を見た場合まで、調査せずPRB-01の原因へまとめないようにします。

回避策は、完全な解決がまだない状況で影響を小さくする対応です。実施できる条件、必要な権限、確認手順、有効でなかった場合の連絡先などを残します。「前にも直ったから」と、現象や環境を確認せず適用することは避けます。回避策があることと、原因が取り除かれたことは別です。

この架空ケースでは、水曜の調査で特定の日付条件を扱う処理に欠陥があることを、検証環境での再現と記録から確認できた、という追加条件を置きます。原因が分かっただけでは本番のプログラムは直りません。変更CHG-01として影響・試験・承認・切戻し条件を確認し、許可された担当者が木曜に修正を反映したとします。

その後、問題管理の側では原因への対処と効果、残るリスクを確認します。変更が承認されたこと、反映できたこと、業務の操作を確認したこと、一定期間の観測で再発しなかったことは、それぞれ異なる根拠です。一週間再発しなかったから永久に起きない、と保証するものではありません。

火曜には、新入社員へKの利用を追加する依頼REQ-01も届いたとします。まだ利用権を付与していない人が「使えない」と言う場合、予定された利用追加の申請なのか、付与済みなのに使えない障害なのかを確認します。連絡の言葉だけで分類するのではなく、期待されていた状態と実際の状態を比べます。

サービス要求として受け付けた場合も、依頼者が望めば即座に管理者権限を渡すという意味ではありません。業務上必要な範囲、承認条件、期限、付与結果を確認します。依頼の途中で既存の不具合を見つけたら、関連するインシデントへ情報をつなぎ、申請の目的と障害の状態を混ぜずに管理できます。以下の記録表では、REQ-01も承認された利用権の付与まで確認できたとします。

ケースを読むときは、一人の担当者が兼務できるかより、その担当者がいま何の目的で動いているかを追います。窓口を一本化することと、全ての記録を「対応済み」の一行で済ませることは違います。分類や引継ぎの詳細は組織の手順によるため、この記事の識別子を必須の書式として覚える必要はありません。

次の表は、Kのケースを読み分けるための学習用の最小記録です。実際の台帳には、責任者、優先度、確認時刻、証跡の参照先などを組織の条件に応じて持たせます。秘密情報や不要な個人情報を、関係者全員が見える欄へ貼り付けるものではありません。

問われているのが復旧、調査、申請、変更のどの判断かを先に特定すると、「原因が不明だから全て止めて待つ」「復旧したから原因調査も終了」「修正を承認したから全端末で直った」のような飛躍を見つけやすくなります。分かった事実と、まだ確認していないことを別々に残しましょう。

設定変更の具体的な手順は変更管理の承認・検証・切戻しへ。初動と解決の測り方はSGのSLA・サービスレベル管理、攻撃の疑いがある事故後の安全確認は復旧と業務再開の終了条件で扱います。本記事の通常の業務障害の例を、そのままサイバー事故の再開許可に使うものではありません。

範囲はSGシラバス案内で確認できます。登録不要の無料6問では演習と解説の操作を試せますが、この管理分野全体の習熟診断ではありません。SGの教材・料金で学習内容と購入条件を確認してください。

SLOとエラーバジェットの計算では、測定の分母と集計期間をそろえ、数値を復旧や変更の判断へつなげる方法を独自例で確認できます。