運用を8年やってきて、障害対応で一番大事なのは技術力より「初動の順番」だと感じています。焦って原因を探し始めて泥沼、というのを何度も見てきました。
原因究明より、まず影響を止める
障害が起きたとき、つい「なぜ壊れたのか」を先に調べたくなります。でも現場でまずやるべきは止血——影響を広げない、サービスを復旧させることです。原因究明は、サービスが戻ってから落ち着いてやればいい。医療のトリアージと同じで、出血を止めるのが先です。
初動の型（私の場合）
- 事象の確定: 何が、いつから、どの範囲で起きているか。監視アラートと利用者の声を突き合わせる。
- 影響範囲の把握: 全系か片系か。1拠点か全拠点か。
- 止血: 切り戻し、片系切り離し、再起動など、まず正常状態に戻す手を打つ。
- 記録開始: 時刻とやったことをメモ。後の原因究明と報告に効く。
- 原因究明: 落ち着いてから、ログと構成変更履歴を追う。
「直近の変更」を最初に疑う
障害の多くは、直前の変更（リリース、設定変更、パッチ）がきっかけです。「昨日まで動いていた」なら、昨日から今日で何が変わったかをまず見ます。変更管理の記録があると、ここで一気に絞れます。
やってはいけないこと
- 記録を取らずに手を動かす（後で何をしたか分からなくなる）
- 複数人が同時にバラバラに触る（切り分けが不能になる）
- 原因が分からないまま、思いつきで設定を次々変える
特に最後は、二次障害の温床です。1つ変えたら1つ確認、を徹底します。
報告も仕事のうち
止血できたら、関係者へ「現状・影響・見込み」を短く共有します。技術的に直すことと、周囲の不安を止めることはセットです。8年やってきて、障害対応の巧拙は、慌てないための「型」を持っているかどうかに尽きると思っています。