システム障害が起きたときの初動対応
システム障害はいつか必ず起こります。重要なのは障害をゼロにすることではなく、起きたときに慌てず対応できる流れを、事前に決めておくことです。
障害対応で最初にやること
障害が発生した（または疑われる）とき、最初に行うべきは原因の特定ではなく「影響範囲の把握」です。
- どの機能・どの利用者が影響を受けているか
- 業務が完全に止まっているのか、一部の操作だけができないのか
- データの整合性に問題が起きている可能性はあるか
原因究明を急ぐあまり影響範囲の確認を後回しにすると、被害が広がっていることに気づかないまま時間が過ぎてしまいます。
一次切り分けの考え方
一次切り分けとは、「どこで問題が起きているか」の大まかな当たりをつける作業です。
- 特定の利用者だけの問題か、全体に影響しているか
- 直前にリリースや設定変更があったか
- 外部サービス（決済・メール送信・API連携先など）側の障害でないか
すべてを自社で切り分けようとせず、「ここまでは自社側の問題」「ここから先はベンダーに確認が必要」という線引きを早めに行うことで、対応のスピードが上がります。
エスカレーションのルールを決めておく
誰が、どのタイミングで、誰に報告するのかが決まっていないと、対応の判断が遅れます。
- 発見者が最初に連絡する窓口はどこか（担当者個人ではなく、窓口やチャットチャンネルを指定しておく）
- どの深刻度になったら経営層や関連部署に報告するか
- ベンダーへの連絡ルート（保守契約の緊急連絡先）は誰が把握しているか
小規模な組織では「担当者に直接連絡する」運用になりがちですが、その担当者が不在のときに機能しなくなります。個人ではなく仕組みとして連絡ルートを整備しておくことが重要です。
利用者への連絡
社内・社外の利用者がいる場合、状況が分からないまま放置されると不安や不満が大きくなります。原因が分かっていない段階でも、「現在調査中である」ことと「次にいつ情報を更新するか」を伝えるだけで、利用者側の受け止め方は変わります。
収束後の振り返り
障害が収束したら、原因と対応の経緯を簡単にでも記録に残します。「なぜ起きたか」だけでなく「発見から復旧までにどれだけ時間がかかったか」「連絡がスムーズだったか」を振り返ることで、次の障害対応の質が上がります。再発防止だけでなく、対応フローそのものの改善にもつなげる視点が大切です。