インシデント対応 — 直すのが先か、分かるのが先か
原因が分からないまま戻すのは怖い。その感覚が復旧を遅らせる。止血と原因究明の順序、記録の残し方、そして再発防止に「気をつける」と書かないこと。
この記事の進み方
What — 最初の30分に何をするか
障害対応には型があります。順序が決まっているのは、迷う時間そのものが被害になるからです。
- 1検知する誰より先に気づく軽い
- 2影響を測る誰が、何を、どれだけできないか軽い
- 3止血する原因が分からなくても、被害を止める中
- 4原因を突き止める止まってから、落ち着いて重い
- 5再発を防ぐ人ではなく、仕組みを直す中
この順序は「原因を軽視する」という話ではない。原因は必ず要る。ただし利用者が困っている間にやることではない、という切り分け。
原因究明は4番目。3番目までを終える前に深追いを始めると、止血が始まらない。
止血の手段は、事前に持っている数だけ選べます。障害中に作れるものではありません。
直前の変更を取り消す
- 速さ
- 数分
- 効く範囲
- 変更が原因なら確実
- 副作用
- データの形が変わっていると危険
- 事前に要るもの
- 戻せる状態を保つこと
- –直前にデプロイがあるなら、まずこれを疑う
- –スキーマを変えていると戻せないことがある。だから拡張→移行→縮小の順で進める
- –戻して直らなくても、原因を1つ潰したことになる。無駄ではない
速さと副作用のどちらを取るかは状況で変わる。大事なのは、選べる手段を事前に用意してあるか。
- 止血
- 原因を直すことではなく、被害の広がりを止めること。医療の比喩がそのまま使われている。
- MTTR
- 平均復旧時間。壊れないことより、壊れてから戻るまでの短さを指標にする考え方。
- ポストモーテム
- 事後の振り返り。起きたことと、なぜ気づけなかったか、何を変えるかを記録する。
- 非難しない振り返り
- 個人の過失を追及しない前提で行う振り返り。隠されると原因にたどり着けないため。
決済が全面的に止まっています。30分前にデプロイがありました。最初に何をしますか?
Why — なぜ復旧を先にするのか
被害の大きさは、影響範囲 × 時間で決まります。範囲は障害が起きた時点でほぼ決まっていますが、時間はこちらの動き方で変わります。唯一こちらが縮められる変数が時間です。
原因究明は、この変数を縮めるのに向きません。理由は難しいからではなく、終わる時刻が読めないからです。10分で分かることもあれば、3時間かかることもある。始めた時点では区別できません。
一方、止血には終わる時刻が読める手段があります。切り戻しは数分、フラグを落とすのは数秒。読める手段を先に使い、読めない作業は被害が止まってからやる。 これが順序の理由です。
「分からないまま戻す」ことへの抵抗
冒頭の事故を止めていたのは、技術ではなく感覚でした。
この感覚には、もっともらしい理屈がついています。「原因が分からないまま戻しても、直る保証がない」。確かに保証はありません。しかし直らなかったとしても、失うのは数分です。一方、原因を待っている間に失うのは、被害が続く時間そのものです。
比べる対象を間違えているのが、この感覚の正体です。比べるべきは「戻す数分」と「調べる数十分から数時間」であって、「戻して直る確率」と「調べて分かる確率」ではありません。
戻せる状態を、先に作っておく
「切り戻せばいい」が成立するのは、戻せる状態を保っているときだけです。
スキーマを変更していると戻せません。古いコードは新しい列を知らず、新しい列に NOT NULL が付いていれば書き込みが失敗します。だから拡張 → 移行 → 縮小の順で進めます（ops/ci-cd で扱った話です）。列を足す、両方に書く、読み替える、古い列を消す。各段階で戻せる状態を保つための手順です。
フラグも同じです。デプロイとリリースを分けておけば、コードを戻さずに機能だけ止められます。
止血の選択肢は、平常時にしか作れません。 障害対応の準備とは、手順書を書くことより先に、選べる手段を増やしておくことです。
振り返りの再発防止策として、最も弱いのはどれですか?
演習 — まず自分で判断する
解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。
いま障害中です。最初の30分をどう使いますか?
- EC サイト。20分前から、商品をカートに入れられないと問い合わせが来ている
- 監視は何も鳴っていない。エラー率も平常どおり
- 直近のデプロイは3日前。設定変更は今朝、CDN のキャッシュ設定を触った
- 自分ともう1人が対応できる。責任者は会議中で30分後に戻る
- セール期間中で、通常の3倍のアクセスがある
- · 監視が鳴っていないのに問い合わせが来ている、という事実が何を意味するか
- · 2人をどう分けるか
- · 責任者を待つかどうか
振り返りの「再発防止」に何を書きますか。書いてはいけないことも含めて説明してください
- 原因は、設定変更の影響範囲を誤解したことだった
- 変更した本人は経験の浅いメンバーで、レビューは通っていた
- この文書は他のチームも読む
- 同じ設定を触る機会は今後もある
読み終わりましたか?
読了にすると、これを前提とする記事がロードマップで開放されます。