サービスマネジメントとSLA運用｜インシデント管理・問題管理・変更管理

ITシステムを安定稼働させ、利用者に約束した品質水準を維持し続けるための体系的マネジメントが「ITサービスマネジメント（ITSM / ITIL / JIS Q 20000）」です。

情報セキュリティマネジメント試験（SG）では、「SLA（サービスレベル合意書）の定義とモニタリング」「インシデント管理と問題管理の明確な相違」「変更管理におけるCAB（変更諮問委員会）の役割」といったサービス運用の現場で求められる標準的プラクティスが頻出します。

1. SLA（サービスレベル合意書）とSLM（サービスレベル管理）

SLA（Service Level Agreement）とは、ITサービスの提供者（社内情シスや外部クラウド事業者）と顧客（業務部門や利用者）の間で、サービスの品質・範囲・可用性について事前に取り交わす合意文書です。

主要SLA項目	指標の意味・測定方法	目標値の具体例
サービス可用性（稼働率）	計画稼働時間に対する実際の稼働可能時間の割合	「月間稼働率 99.9% 以上」
MTBF（平均故障間隔）	システムが故障せず正常に動いていた時間の平均（信頼性指標）	「MTBF 1,000時間以上」
MTTR（平均復旧時間）	障害発生からサービス復旧までに要した時間の平均（保守性指標）	「MTTR 2時間以内」
応答時間（レスポンスタイム）	利用者が操作要求を送信してから結果が返るまでの時間	「Web検索結果の表示 3秒以内」
インシデント初動時間	障害通報を受理してから技術者が調査を開始するまでの時間	「緊急障害時 15分以内に一次回答」

2. 「インシデント管理」と「問題管理」の決定的な違い

【試験最頻出の対比】
・
インシデント管理の目的：
「何が原因であれ、とにかく迅速にサービスを復旧させ、業務への悪影響を最小化すること（暫定回避策・ワークアラウンドの適用）」。
・
問題管理の目的：
「インシデントの
根本原因（Root Cause）を究明
し、未知のエラーを特定して、恒久対策を講じることで再発を完全に防止すること」。

比較項目	インシデント管理（Incident Management）	問題管理（Problem Management）
最大の目的	サービスの迅速な復旧（ビジネスの継続）	根本原因の究明と再発防止
対応スピード	緊急（即時対応が求められる）	中長期（徹底した分析・検証を行う）
典型的なアクション	サーバ再起動、予備系への切り替え、バックアップ復元	ログの詳細解析、バグ修正パッチの作成、設計見直し
成果物	復旧完了報告、暫定回避策（ワークアラウンド）	既知のエラー（Known Error）の記録、変更要求（RFC）

3. 変更管理（Change Management）とCABの役割

ITシステムで発生する障害の多くは、「システムのバージョンアップ」「ネットワーク設定変更」「パッチ適用」などの変更作業ミスに起因します。

変更要求（RFC：Request for Change）：変更の理由、影響範囲、作業手順、コスト、リスクを記載した申請書。
CAB（変更諮問委員会：Change Advisory Board）：変更によるリスクと事業影響を多角的に評価・承認する機関。
ロールバック計画（切り戻し手順）：変更作業が失敗したり予期せぬ不具合が発生した際、即座に変更前の正常状態へ戻すための手順を事前に準備・検証しておくこと。

4. 科目B形式実戦シナリオ演習

演習1：反復発生するシステム障害へのインシデント・問題管理の連携

〔背景〕電子機器メーカーU社の受注管理システムで、毎週月曜日の朝に「データベース接続タイムアウトエラー」が発生し、業務が一時停止するトラブルが3週連続で発生した。

〔これまでの対応〕サービスデスクの担当者は、障害発生のたびに「DBサーバプロセスの再起動」を実施し、約10分間でシステムを復旧させていた。

〔設問〕ITサービスマネジメントの観点から、この反復障害に対して次に取るべき最も適切なアクションはどれか。

ア：サービスデスクの人員を増強し、月曜朝に待機して再起動時間を5分に短縮する。
イ：インシデント管理から問題管理プロセスへ事象を引き継ぎ、月曜朝のアクセス集中ログやコネクションプール設定を詳細解析して根本原因を特定し、恒久対策を実施する。
ウ：利用者に月曜朝の受注入力を禁止し、火曜日にまとめて入力するよう依頼する。
エ：SLAの稼働率目標を引き下げ、月曜朝のダウンタイムを契約除外とする。

【解答と解説】

正解：イ

解説：サーバ再起動による一時復旧はインシデント管理における「暫定回避策（ワークアラウンド）」です。しかし、同一のインシデントが反復して発生している場合、その場しのぎの再起動を繰り返すだけでは不十分であり、「問題管理（Problem Management）」へエスカレーションして根本原因を究明・特定し、コネクション設定の最適化やハードウェア増強などの恒久対策を講じる必要があります。

演習2：基幹サーバの緊急パッチ適用と変更管理手順の遵守

〔背景〕V社のWebサーバで重大なゼロデイ脆弱性が公表され、攻撃コードがネット上に出回った。インフラチームはベンダーから提供された修正パッチを緊急適用したいと考えている。

〔設問〕緊急を要する変更作業（緊急変更）を実施するにあたり、変更管理規程で必ず担保しておくべき手続きとして、最も適切なものはどれか。

ア：事後審査も含め、緊急変更諮問委員会（ECAB）の承認を得るとともに、万一パッチ適用に失敗した場合の切り戻し手順（ロールバック手順）を事前に確認しておく。
イ：緊急時であるため、変更記録（RFC）の作成や承認手続きは一切不要とし、作業者の判断のみで即時実行する。
ウ：パッチ適用作業中はバックアップ取得を省略し、適用時間を最優先する。
エ：社内の全利用者に作業通知を行わず、深夜に抜き打ちで実施する。

【解答と解説】

正解：ア

解説：緊急を要するパッチ適用（緊急変更）であっても、無統制な変更は二次災害（システム完全停止）を引き起こす危険があります。そのため、緊急承認枠組みである「ECAB（緊急変更諮問委員会）」の承認を得ること、および適用後に不具合が生じた場合の「切り戻し手順（ロールバック計画）」の事前検証を省略してはなりません。

5. まとめと試験直前チェックリスト

SLA（合意書）とSLM（管理）：品質基準を数値（稼働率、MTTR等）で合意し、定期的に達成度をレビュー
インシデント管理：サービスの「迅速な復旧」とワークアラウンド適用が最優先
問題管理：インシデントの「根本原因究明」と再発防止（既知のエラー化）
変更管理（RFC・CAB）：変更に伴うリスクを評価・承認し、ロールバック計画を必ず保持
構成管理（CMDB）：IT資産や構成品目（CI）の依存関係を正確に台帳管理

サービスマネジメントとSLA運用｜インシデント管理・問題管理・変更管理の実務