「障害の連絡を受けたが、何から確認すればよいか分からない」
「原因を調べているうちに、最初の報告が遅れてしまった」
システム障害の初動で最も大切なのは、原因をすぐ当てることではありません。事実を押さえ、影響の拡大を防ぎ、関係者が判断できる情報を早く共有することです。
障害発生直後は情報が少なく、利用者の申告、監視アラート、ログの内容が一致しないこともあります。この段階で原因を決めつけると、誤った調査や不要な変更につながります。
私も銀行システムの開発・保守に25年以上携わるなかで、初動の記録と共有が、その後の復旧速度を大きく左右する場面を何度も経験しました。若手SEが一人で結論を出す必要はありません。確認できた事実を、短く正確に渡すことが重要です。
この記事では、障害発生から最初の30分を想定し、現場で使える初動手順を解説します。
初動のゴールは「チームが安全に動ける状態」をつくること
初動では、復旧作業そのものより先に、発生事象、影響、証拠、連絡、役割を整えます。原因が未確定でも、ここまで整理できれば、責任者は復旧優先か調査優先かを判断できます。
特に本番環境では、再起動や設定変更によって証拠が消えることがあります。緊急性と証拠保全のバランスを取り、承認された手順で進めます。
| 確認軸 | 確認内容 | 初動での表現例 |
|---|---|---|
| 事実 | いつ・どこで・何が起きたか | 10時15分から振込画面でエラー |
| 影響 | 誰に・何件・どこまで影響するか | 現時点で3件、継続確認中 |
| 証拠 | ログ・監視・画面・データを残したか | 対象時刻のログを退避済み |
| 対応 | 誰が何をしているか | Aさんが影響調査、Bさんがログ確認 |
| 共有 | 次回報告時刻を決めたか | 10時30分に再報告 |
障害発生から最初の30分で行う4ステップ
1．発生時刻・対象・事象を固定する
最初に、利用者から見えた事象と、システムで確認できた事実を分けます。「画面が固まった」は申告であり、技術的にはタイムアウト、処理遅延、ブラウザ側の問題など複数の可能性があります。
監視アラートの発生時刻、対象画面や処理、利用者ID、取引番号、再現性を確認します。時刻は秒まで取れると、複数ログを突き合わせやすくなります。
- 発生日時とタイムゾーン
- 対象環境・機能・サーバ
- 利用者から見えた事象
- エラーコードやメッセージ
- 再現性と継続有無
2．証拠を保全してから状態を変える
再起動、デプロイ、設定変更、データ更新の前に、可能な範囲でログ、監視画面、プロセス状態、接続数、対象データを保存します。変更前後を比較できるよう、取得時刻と取得者も記録します。
ただし、サービス停止の影響が大きく、定められた復旧手順を直ちに実施すべき場合は、責任者の判断を優先します。証拠保全に時間をかけすぎるのも初動の失敗です。
3．影響拡大を防ぐ暫定措置を検討する
受付停止、対象ジョブの保留、外部連携の一時停止、特定ノードの切り離しなど、影響を広げない選択肢を整理します。実施には業務影響があるため、若手SEだけで決めず、選択肢とリスクを責任者へ提示します。
- 続行した場合にデータ不整合が増えないか
- 停止した場合に後続業務へ何が起きるか
- 切り戻しや再開の条件が明確か
- 利用者への案内が必要か
4．一次報告と役割分担を行う
一次報告は原因説明ではなく、事実と現在の対応を共有するものです。長い文章より、発生事象、確認済みの影響、実施中の対応、次回報告時刻を短く伝えます。
対応者が増えたら、指揮、記録、ログ調査、影響調査、関係者連絡の役割を決めます。複数人が無記録で本番操作をすると、状況を悪化させるおそれがあります。
【一次報告】 10時15分から振込受付画面でエラーが発生しています。 現時点で3件を確認し、事象は継続中です。 対象ログを保全し、他機能とデータ更新への影響を確認しています。 次回は10時30分に状況を共有します。
初動記録のテンプレート
障害対応中は、チャットや口頭だけでなく、時系列の記録を一か所へ集約します。次の項目があれば、途中参加者も状況を追いやすくなります。
【発生】 発生日時： 対象環境・機能： 利用者から見えた事象： 【確認済みの事実】 監視・ログ： 再現性： 直前の変更： 【影響】 利用者・件数： データ・後続処理： 【対応】 実施時刻／担当／操作／結果： 次回報告時刻： 判断が必要な事項：
記録では、未確認の情報に「推定」「可能性」と明記します。事実と仮説が混ざらないだけで、誤解は大きく減ります。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| 原因調査だけに集中する | 影響確認と報告が遅れ、業務判断ができなくなる | 原因担当と影響・報告担当を分ける |
| すぐ再起動する | 一時復旧しても証拠が消え、再発時に追えない | 許される範囲で変更前情報を保全する |
| 分かるまで報告しない | 関係者が古い情報で判断する | 確認済み・未確認・次回報告をセットで伝える |
若手SE向けチェックリスト
- 発生日時、対象、事象、再現性を確認した
- 利用者の申告とシステム上の事実を分けた
- 状態変更前に必要な証拠を保全した
- 影響拡大を防ぐ選択肢を整理した
- 一次報告に次回報告時刻を入れた
- 指揮・記録・調査・連絡の役割を決めた
- 操作と結果を時系列で残した
まとめ：初動では原因より先に、事実と判断材料をそろえる
障害の初動対応では、慌てて修正するより、事実を押さえて安全にチームを動かすことが重要です。
若手SEの役割は、最初から正解を言うことではありません。確認した内容を整理し、判断が必要な事項を責任者へ渡せれば、十分に価値のある初動です。
- 発生事象と影響を短時間で確認する
- 証拠を残してから状態を変える
- 一次報告と役割分担でチーム対応へ切り替える
コメント