システム障害の対応の業務手順書テンプレート（受託開発・情報システム）
障害を検知してから、影響を確かめ、関係者に連絡し、復旧させて原因と再発防止策を報告するまでの流れです。手順書にすると、連絡の遅れや、復旧を急いで原因の記録が残らない事態を防げます。
この手順書の範囲
- 目的
- 障害の連絡と判断の順番を決め、夜間や担当者不在のときでも同じ対応ができるようにします。
- 範囲
- 障害の検知・受付から、復旧、障害報告書の提出までです。
- 始まるきっかけ
- 監視の警告が出たとき、または利用者から「使えない」「遅い」という連絡があったとき
- 頻度・量の目安
- 随時・月0〜10件
- 使う書類・システム
- 監視の警告・利用者からの連絡、保守・運用の対応記録表、連絡先一覧（夜間・休日を含む）、システム構成図・運用手順書
担当と役割
一次対応者（保守担当・ヘルプデスク）
受付、影響の確認、一次対応、記録
障害対応責任者
重要度の判定、連絡、復旧方法の判断
開発・インフラ担当
原因の調査と修正
手順（11ステップ）
1. 障害を受け付けて記録する
検知した時刻、連絡者、症状、影響を受けている機能を対応記録表に入れます。
- 確かめること
- 最初の連絡の時刻を必ず記録する（SLA の判定に使う）。
- できあがるもの
- 対応記録の1行
- 確認一次対応者・目安 15分
2. 症状を再現・確認する
監視画面、ログ、実際の操作で、どの範囲で何が起きているかを確かめます。
- 確かめること
- 利用者の端末の問題か、システム全体の問題かを切り分ける。
- できあがるもの
- 確認結果
- 判定障害対応責任者・目安 5分
3. 重要度を判定する
業務が止まっているか、影響する利用者の数、データの破損・漏えいのおそれで判定します。
- 確かめること
- 個人情報の漏えいのおそれがある場合は、すぐに個人情報の管理責任者に知らせる。
- できあがるもの
- 重要度の判定
4. 関係者に第一報を入れる
発生時刻、症状、影響、現在の対応、次の連絡時刻を伝えます。
- 確かめること
- 重要度が高い障害は、検知から30分以内など決めた時間内に第一報を出す。
- できあがるもの
- 第一報
- 一次対応一次対応者・目安 15〜60分
5. 運用手順書にある一次対応を行う
サービスの再起動、切り替え、負荷の高い処理の停止など、手順書にある対応を行います。
- 確かめること
- 手順書にない操作は障害対応責任者の判断を得てから行う。操作した時刻を記録する。
- できあがるもの
- 一次対応の記録
- 調査開発・インフラ担当・目安 案件による
6. 原因を調べる
ログ、直前の変更（リリース・設定変更）、外部サービスの状況を確かめます。
- 確かめること
- 調査に使ったログを保全する（上書きされる前に保存する）。
- できあがるもの
- 調査メモ
- 復旧障害対応責任者・目安 案件による
7. 復旧の方法を決めて実行する
修正、切り戻し、代わりの手段（手作業での運用など）から選びます。
- 確かめること
- データを修正する場合は、修正前のデータを保存してから行う。
- できあがるもの
- 復旧の記録
- 確認一次対応者・目安 15分
8. 復旧を確かめ、利用者に知らせる
症状が出ないこと、止まっていた処理が再開したことを確かめ、利用者に復旧を知らせます。
- 確かめること
- 障害中に処理できなかったデータ（未連携・未送信）が残っていないか確かめる。
- できあがるもの
- 復旧の連絡
- 報告障害対応責任者・目安 案件による
9. 個人情報の漏えいのおそれがあれば報告を準備する
要配慮個人情報、不正アクセス、1,000人を超える漏えいなどに当たるかを確かめます。
- 確かめること
- 当たる場合は個人情報保護委員会への速報（概ね3〜5日以内）と確報（30日以内、不正の目的によるものは60日以内）、本人への通知を行う。
- できあがるもの
- 報告の準備
- 報告開発・インフラ担当・目安 半日
10. 障害報告書を作る
経緯（時刻つき）、影響、原因、対応、再発防止策を書きます。
- 確かめること
- 原因は「なぜ」を繰り返して、仕組みの原因まで書く。
- できあがるもの
- 障害報告書
11. 再発防止策の実施を追う
対策ごとに担当と期限を決め、完了を確かめます。
- 確かめること
- 運用手順書や監視の設定に反映したかを確かめる。
- できあがるもの
- 再発防止策の進捗
締めのチェックリスト
- 最初の連絡の時刻を記録した
- 利用者の端末の問題か全体の問題か切り分けた
- 重要度を判定した
- 決めた時間内に第一報を出した
- 手順書にない操作は判断を得てから行った
- 調査に使ったログを保全した
- データ修正の前に修正前のデータを保存した
- 未処理のデータが残っていないか確かめた
- 個人情報の漏えいに当たるか確かめた
- 障害報告書と再発防止策の担当・期限を決めた
よくあるミスと防ぎ方
復旧を優先して記録を残さない
再起動などで原因の手がかりが消えます。操作の前に時刻とログを保存し、操作した時刻を記録します。
第一報が遅れる
原因がわかってから連絡しようとすると遅れます。わかっていることだけで第一報を出し、次の連絡時刻を伝えます。
漏えいの報告の判断が遅れる
不正アクセスが疑われる場合などは、個人情報保護委員会への報告が必要になることがあります。重要度の判定に漏えいのおそれの確認を入れます。
測っておきたい指標
- 検知から第一報までの時間
- 検知から復旧までの時間
- 再発防止策の期限内完了率
関係する法令・規格
個人情報保護法
漏えい等が発生し個人の権利利益を害するおそれが大きい場合の、個人情報保護委員会への報告と本人への通知に関わります。
保守契約・SLA
障害の受付時間、初動・復旧の目標時間、報告の方法は契約の取り決めに従います。
無料ダウンロード
業務手順書テンプレート集（IT・受託開発・10業務）
- 「システム障害の対応」を含む10業務の手順書を、1業務1シートで書き換えられるExcel
- 手順ごとに担当・確かめること・できあがるもの・目安時間の列。自社のやり方に合わせて行を足せます
- 締めのチェックリストと改訂履歴のシートつき。A4横で印刷できます
フォームを送信すると、すぐにダウンロードできます
11手順のうち3つは、自動化の候補です
よくある質問
- 第一報はどこまでわかってから出しますか。
- 原因がわからなくても、発生時刻・症状・影響・次の連絡時刻だけで出します。待たせるより、途中経過を伝える方が関係者は動けます。
- 個人情報の漏えいはどんな場合に報告が必要ですか。
- 要配慮個人情報の漏えい、財産的被害のおそれ、不正の目的によるもの、1,000人を超えるものなどが報告の対象です。おそれの段階でも報告が必要になることがあります。
- 障害報告書には何を書きますか。
- 時刻つきの経緯、影響の範囲、原因、行った対応、再発防止策とその担当・期限を書きます。