まず止める、それから考える：障害調査の順番を間違えない【第2回】

この記事を読み終えると、障害に遭遇したときに原因を調べる前に選ぶべき3つの止血手段を判断でき、誰に何をいつ伝えるかを段取りとして持て、止血中にやってはいけないことを避けられるようになります。ジュニアエンジニア向け 成果の出し方シリーズ（全12回）の第2回です。

🎯 テーマの主役：「止血」

今回の主役は止血（containment）です。一言で言えば、止血とは「原因を特定せずに、被害の拡大を止める行為」です。原因の究明ではありません。止めることです。

日常の例えで言うなら、火事です。家から煙が出ているとき、あなたはまずなぜ火が出たのかを調べません。まず初期消火を試み、無理なら通報して逃げる。出火原因の調査は、火が消えてから、消防の専門家がやることです。そしてもう1つ重要なことがあります。火事のとき、人は「まだ消せるはずだ」と自分で判断して手を出し、逃げ遅れます。だから消防の世界では、消す・通報する・逃げるという順番と役割が訓練されます。

これは内輪の話ではなく、実際に山火事の教訓から生まれた仕組みです。1970年代のカリフォルニアの山火事では、複数の消防隊が現場に集まったものの、指揮系統が統一されていないために連携が崩れ、被害が拡大する事例が繰り返されました。そこからインシデント・コマンド・システム（ICS）という、役割と指揮系統を最初に固定する仕組みが生まれました。この仕組みは後に、ソフトウェアの障害対応にもそのまま輸入されています。

障害対応が調査ではなく意思決定である理由を、1つ先に書いておきます。障害の最中、あなたが持っている情報は不完全で、刻々と変わり、時間が押している。この条件では、正しい判断を探すことより、決めて動くことのほうが価値を持ちます。間違った止血はやり直せますが、迷っている時間は取り戻せません。

動機：最初の15分で、その後が決まる

障害対応について、ジュニアエンジニアが最初にぶつかる壁は技術的な難しさではありません。順番の判断です。

多くのジュニアは、アラートを見てまずログを開きます。そして原因を推理し始めます。これは真面目な姿勢から来る行動で、責められるものではありません。学校でも現場でも「調査能力」が評価されるからです。しかし障害の最中、この行動は被害を拡大します。推理に没入している数十分のあいだ、利用者は困り続け、影響は広がり、関係者は情報を持たないまま待ちます。

この記事の仮説はこうです。障害対応の質は「正しい原因を当てたか」ではなく「被害を最短で止めたか」で測られる。したがって初動の技術とは、調査技術ではなく、止血の選択と段取りの技術である。もしこれが正しければ、あなたが最初に身につけるべきは推論の速さではなく、手順の速さになります。

なお第8回（開発フロー入門シリーズ）では、SLOとエラーバジェット、観測の3本柱、初動10分の型、ポストモーテムを扱いました。この記事はその続編です。「何をするか」の型は学んだ。では「どう判断するか」——そこを埋めます。まだ読んでいない場合は、そちらを先に読むと理解が速くなります。

🔍 検証①：止血の手段は3つしかない

まず、選択肢を有限にします。慌てる原因の多くは、選択肢が無限に見えることです。実は止血の手段は3つしかありません。戻す・止める・迂回するです。

戻す（revert / rollback）は、直前の状態に戻すことです。最も速く、最も確実で、第一候補になります。デプロイの取り消し、設定の差し戻し、フィーチャーフラグのオフ。第5回で扱う「戻せる変更」は、まさにこの手段を常に使えるようにするための設計です。

止める（disable）は、問題を起こしている機能や経路を落とすことです。「決済だけ止める」「特定のバッチを止める」「該当APIを503で返す」。全部を止めるより、一部を止めるほうが被害が小さいので、範囲を絞れるなら絞ります。ただし止める判断は利用者に直接影響するため、誰の承認で止めるかを先に決めておく必要があります。

迂回する（workaround）は、問題の経路を通らないようにすることです。古いバージョンに逃がす、別のサーバーに切り替える、手作業で代替する。迂回は時間を買う手段であり、根本的な解決ではありません。迂回したら、そのことを必ず記録します（手作業が残ると、後で必ず忘れられます）。

注目してほしいのは、「直す」が最後に置かれていることです。直すことは正しい行為ですが、止血としては最も遅く、最も危険です。検証が不十分なまま出すことになり、二次障害を起こすからです。「直す」を選ぶのは、他の3つが使えないときの最終手段と覚えてください。

🔍 検証②：止血の速さは「被害の広がり速度」で決める

次に、いつ止血するかの判断基準です。「影響範囲が分かってから動こう」と考えると遅れます。判断の軸は正確さではなく、広がりの速度です。

広がりが速いほど、確認を待たずに止血します。広がりが遅い（または止まっている）なら、少し確認してから止血しても間に合います。この2つを混同すると、遅い障害に焦って誤った止血を打ち、速い障害に慎重になって被害を広げるという、最悪の組み合わせになります。

ここで大事なのは、迷ったら止血寄りに倒すという原則です。止血の多くは可逆です（戻したものをまた出せる、止めたものを再開できる）。そして止血の副作用（機能が一時的に使えない）は、たいてい被害より小さい。一方、被害の拡大は取り戻せません。可逆な行動と不可逆な結果を比べたら、可逆な行動を選ぶ。これは障害対応だけでなく、あらゆる判断に効く原則です。

🔍 検証③：伝える相手は3系統ある

止血と同じくらい重要なのが共有です。ここでジュニアがやる失敗は、共有を最後に回すことです。「まだ原因が分からないので、報告できません」。しかし聞かれているのは原因ではありません。状況と次の連絡時刻です。

共有先は3系統に分かれます。判断する人（上長・責任者）、現場（同僚・サポート窓口）、外側（利用者・取引先）。この3系統は必要な情報が違います。全部に同じ長文を送る必要はありません。

「判断してほしいこと」を明示するのが、特に重要な技術です。「復旧のめどは立っていません」では、判断者は動けません。「15分以内に復旧できなければ、決済機能を停止します。停止してよいですか」——これなら判断できます。障害対応における良い報告とは、判断を要求する報告です。

そして次の連絡時刻を必ず添えます。「15分後に続報を出します」。この一文があるだけで、関係者は待つ必要がなくなり、他の仕事に戻れます。情報がないことより、次にいつ情報が来るか分からないことのほうが、人を疲れさせます。

🔍 検証④：止血中にやってはいけない5つ

次に、やってはいけないことです。これは失敗から学ぶほうが速い領域なので、実際に起きたことに結びつけて説明します。

その1：同時に複数の変更を試す。 止血の最中に、設定を変え、コードを変え、サーバーも増やす。すると何が効いたか分からなくなり、何が悪化させたかも分からなくなります。1つ変えて、結果を観測するを守ります。観測に30秒かける余裕が、1時間の遠回りを防ぎます。

その2：観測手段を自分で壊す。 これは実在の大規模障害で起きています。2017年2月28日のAWSのS3障害では、運営用のコマンドの入力ミスによって、必要なサーバーが想定より多く停止し、復旧に数時間を要しました。同種の教訓としてより鮮明なのが、2021年10月4日の大手SNSの世界的障害です。この障害では、ネットワーク経路を撤回する操作が原因で、社内の連絡ツールや遠隔操作の手段まで到達不能になり、復旧作業そのものが難しくなりました。教訓は明快です。止血の手段が「止まっているシステム」に依存していてはいけない。社内チャットが落ちても連絡できる手段、管理画面が落ちても操作できる手段を、平時に用意しておく必要があります。

その3：ログや証拠を消す。 ディスクが逼迫したからログを消す、再起動する前にダンプを取らない。止血が先ではありますが、消す操作は不可逆です。消す前に、可能なら残す（コピーする、書き出しておく）。後の原因調査ができなくなると、同じ障害が再発します。

その4：犯人探しに時間を使う。 「誰がこの設定を変えたのか」。これは止血には1ミリも貢献しません。そして情報を隠す動機を生みます。次に障害が起きたとき、誰も早く言わなくなります。原因の特定と責任の追及は別物です。

その5：徹夜で粘る。 睡眠を削った判断力は確実に落ちます。第6回で扱う評価の話にも通じますが、疲労した状態での誤操作が二次障害を起こす事例は多く報告されています。引き継げる形で交代することが、個人の根性より成果に効きます。

🔍 検証⑤：復旧の宣言と、その後の引き継ぎ

止血が終わった瞬間に、人は「終わった」と思いたくなります。しかしここに落とし穴があります。

その1：復旧宣言を誰がするかを決めておく。 一部の利用者はまだ影響を受けているかもしれません。「どの指標がどうなったら復旧と見なすか」を先に決め、宣言する人を1人に定めます。複数の人が別々に「直った」と言うと、現場が混乱します。

その2：一時的な止血を、恒久対応と混同しない。 迂回した手作業、止めたバッチ、古いバージョンへの切り替え。これらは負債として記録します。記録しないと、半年後に「なぜか手作業がある」という謎として残ります。第7回（開発フロー入門の設計回）で扱った決定の記録と同じ発想です。「なぜこうなっているか」を残すのが、次の人への贈り物になります。

その3：引き継ぎを、記憶があるうちに書く。 障害の記憶は驚くほど速く抜けます。特に徹夜の後は、数時間で細部が消えます。時系列で「何を試して、何が起きたか」をメモしておきます。原因の推定は後で構いません。試した事実を残すのが目的です。これが後のポストモーテム（振り返り）の質を決めます。

結果：初動の判断フロー

ここまでの内容を、実際に使えるフローにします。

【0〜2分】把握
  ・何が使えないか（機能）／いつからか（時刻）／広がっているか（増加傾向）
  ・「広がっている」なら、以降は確認を最小化して止血を優先

【2〜5分】止血の選択
  ・直前に変更を出したか？ → YES: まず戻す
  ・問題の範囲が特定できるか？ → YES: その部分だけ止める
  ・止められないか？ → 迂回して時間を買う
  ・どれも無理か？ → 影響が限定されているか確認してから直す

【並行】共有
  ・判断する人：影響範囲＋選択肢＋判断してほしいこと
  ・現場：いま利用者に起きていること＋回避策
  ・外側：影響＋次の連絡時刻（必ず時刻を書く）

【止血後】
  ・復旧の定義を確認し、宣言する人を決める
  ・一時的な止血を負債として記録する
  ・時系列で試したことを書き、交代できるようにする

このフローで最も重要なのは、「把握」と「止血」のあいだで止まらないことです。完璧な把握は不可能であり、不完全な把握で止血を選ぶのが仕事です。そして、選んだ止血が間違っていたら、その時点でやり直せます。

考察：止血の速さは、事前の準備で決まる

ここまでの内容を踏まえて、1つ踏み込んだ話をします。障害対応の速さは、障害が起きた後の努力ではほとんど決まりません。 決まるのは事前に何を用意していたかです。

考えてみてください。「戻す」を選ぶには、戻し方が事前に決まっている必要があります。「止める」を選ぶには、止める権限と手順が事前に用意されている必要があります。最初の5分で動けなかったチームは、5分で努力が足りなかったのではなく、5分で動ける状態を作っていなかったのです。

この視点は、ジュニアにとって希望になります。なぜなら、障害対応の能力はその場の才能ではなく、事前の設計で決まるからです。あなたが今日できる最も価値の高い仕事の1つは、戻し方を決めて、書いて、試しておくことです。これは第5回のテーマです。

もう1つの考察は、止血の判断は、技術力より「決める権限」に制約されるということです。優れた判断をしても、決められなければ動けません。だからジュニアのうちに身につけるべきは、「判断材料を揃えて、判断を要求する技術」です。これは第6回（報告）と第8回（提案）で扱う技術の原型です。障害対応は、成果の出し方が最も凝縮されて現れる場面だと言ったのは、この意味です。

📌 注目ポイント

核心は4点です。第一に、障害対応は調査ではなく意思決定であり、最初にすべきは止血であること。第二に、止血の手段は「戻す・止める・迂回する・直す」の4つで、直すは最後の手段であること。第三に、判断の軸は正確さではなく、被害の広がり速度であること。第四に、共有では原因ではなく、判断要求と次の連絡時刻を伝えること。

特に第三点が実務で差になります。「正確に把握してから動く」は平時の美徳ですが、障害時には被害を拡大する行動になりえます。可逆な行動を、不可逆な結果より優先する。この原則を1つ持っておくと、判断が速くなります。

💡 活用事例：止まっているシステムに依存した止血は使えない

2017年5月27日、英国航空（British Airways）で大規模なシステム障害が発生し、多数の便が欠航・遅延しました。原因はデータセンターへの電力供給に関する作業で、電力の供給が想定外に落ちたことでした。重要なのは、この障害で「戻す」も「直す」も、影響を受けたシステムの管理画面が使えない状態では実行できなかったという点です。復旧には、現地での物理的な作業が必要になりました。

2021年10月4日の大手SNSの世界的障害では、ネットワーク経路の撤回が原因で、社内の連絡手段と遠隔での復旧手段が同時に失われました。技術チームは、物理的にデータセンターへ向かい、内部のネットワークに直接接続して復旧作業を行ったと説明されています。

3つの事例に共通するのは、止血手段が「止まっているもの」に依存していたことです。ここから実務的な行動が導けます。障害時の連絡手段を、社内チャット以外に1つ用意する（電話番号の一覧、外部メール等）。復旧手順を、落ちているシステムに依存しない形で1枚に書く。手順は、試したことがある人だけが使える。この3つは、ジュニアでも今日から用意できます。第5回で扱う「戻せる変更」は、この発想の設計版です。

✅ 要点まとめ

• 障害対応の初動は止血。原因究明は止血の後でよい
• 止血の手段は戻す・止める・迂回する。直すは最後の手段
• 判断の軸は被害の広がり速度。速ければ確認を待たず止血する
• 可逆な行動（止血）を、不可逆な結果（被害拡大）より優先する
• 共有先は3系統。伝えるのは原因ではなく判断要求と次の連絡時刻
• 止血手段が、止まっているシステムに依存しないように設計する
• 一時的な止血は負債として記録し、時系列メモを残す
• 障害対応の速さは、事前の準備でほぼ決まる

🚀 取り込み方：明日から使う3段階

今日（5分でできること）：自分の担当サービスの「戻し方」を1つ調べて、3行で書いてください。デプロイの取り消しコマンド、設定の差し戻し手順、フラグの切り方。書けなかった項目が、あなたの最大のリスクです。書けなかったなら、それを上長に「分かりません」と伝えることが今日の成果です。

今週（小さく試す）：次の小さなリリースで、「戻す」を1回試してください。問題がないリリースでも、戻して、また出す。これを1回経験しておくと、本番の障害時に手が震えません。あわせて、障害時の連絡手段を1つ確保します（社内チャット以外の経路）。手順は試したことがある人だけが使える——この事実を体で知っておくと強いです。

今月（業務に組み込む）：チームの「止血の選択肢表」を作る提案をします。戻す・止める・迂回するの3列に、具体的なコマンドや手順を書いた1枚です。加えて、「止める権限は誰にあるか」を明文化します。これが決まっていないチームは、必ず障害時に迷います。あなたが作ったこの1枚は、第1回で扱った「成果」の典型例です。作業としては地味ですが、効果は長期にわたって残ります。

🔥 ハマりポイント：初動で判断を誤る3つの型

その1：「原因が分かってから報告しよう」と思いがちだが、実は報告が遅れるほど被害が増える

症状は、30分後に「実は30分前から壊れていました」と報告する。原因は、報告の目的を「報告すること」だと思っていることです。報告の目的は判断を引き出すことです。判断材料が不完全でも、「広がっている／分かっていない／15分後に続報」で十分に判断できます。対処は、報告に求める情報を3点に絞ること。影響範囲・やったこと・判断してほしいこと。この3点だけを書く練習をしてください。

その2：「戻すのは敗北」と思いがちだが、実は戻すのが最もプロらしい判断

症状は、戻せば直るのに、原因を特定してから直そうとする。原因は、戻すことに心理的な抵抗があることです。「せっかく作ったものを消す」「自分のミスを認めることになる」。しかし利用者から見れば、戻すか直すかは関係ありません。早く使えるようになるかどうかだけです。対処は、戻す基準を先に決めておくこと。「この機能のエラー率が1%を超えたら、原因を問わず戻す」。基準を先に決めておけば、その場の感情が判断に入りません。

その3：「みんなで集まれば早く直る」と思いがちだが、実は人が増えると遅くなる

症状は、10人が同じログを眺め、同じコマンドを打ち、互いの作業を打ち消す。原因は、役割が決まっていないことです。対処は、最初に役割を3つ決めること。指揮（決める人）・調査（手を動かす人）・連絡（外に伝える人）。10人集まったら、調査は2人まで、残りは手を出さない。これは先に紹介したICSの基本です。人が足りないのではなく、役割が足りていないのです。

🔄 代替アプローチとの比較：インシデント対応の型の違い

障害対応には複数の型があります。どれが正しいかではなく、組織の規模と性質で選ぶものです。自分の現場がどの型かを知っておくと、動き方が合わせやすくなります。

全員招集型が向いているケースもあります。学習段階のチームや、頻度の低い大規模障害では、全員が同じ状況を見ることに価値があります。ただし役割だけは決めてください。役割のない全員招集は、最も遅い選択肢になります。そして、同じ障害が2回起きたら、それは自動化の対象です。人の注意力に頼る対応は、いつか必ず失敗します。

📅 今後の展望：止血の自動化と、人間の役割の移動

障害対応は、この10年で検知と止血の自動化が進みました。異常を検知して自動で切り戻す、負荷が上がったら自動で逃がす、といった仕組みが一般化しています。その延長として、カオスエンジニアリング（意図的に障害を起こして復旧力を確かめる手法）も広がりました。これは「壊れたときに自動で戻るか」を普段から試すという発想です。

この流れで、人間の役割は「手を動かす」から「判断する」へ移ります。自動復旧が働いたとき、そのまま任せるか、それとも手を止めるか。自動化が失敗する条件を事前に把握しているか。つまり、止血の自動化が進むほど、”止血の選択”という今回の主題の重要性は上がります。手を動かす部分は減っても、決める部分は減りません。

もう1つの流れは、振り返りの文化の標準化です。責任を追及せず原因を学ぶポストモーテムは、多くの組織で標準になりました。これは第1回で書いた「成果は作業量ではない」という考え方と直結します。障害を隠さない組織のほうが、長期的に強い。あなたがジュニアのうちに、「報告すると怒られる」という経験を組織に作らせないこと——これはあなた自身の未来の安全にもつながります。

まとめ

この記事では、障害調査の順番を扱いました。最初にするのは原因の究明ではなく止血です。止血の手段は戻す・止める・迂回するの3つで、直すは最後の手段。判断の軸は被害の広がり速度。共有では判断要求と次の連絡時刻を伝えます。そして、止血手段が止まっているシステムに依存しないように設計します。

これを読んだあなたは、障害に遭遇した最初の5分で、止血の選択肢を3つ挙げ、判断を要求する報告を書けるようになりました。次の第3回では、止血が終わったあとの原因調査の技術を扱います。当てずっぽうで探すのをやめ、仮説を立てて消していく——それが次の技術です。

参考文献

1. Google『Site Reliability Engineering』第14章 Managing Incidents — 障害対応の役割分担と指揮系統の実務。 https://sre.google/
2. Google『The Site Reliability Workbook』 — インシデント対応とポストモーテムの手順。 https://sre.google/
3. FEMA『Incident Command System（ICS）』／NIMS — 山火事対応から生まれた指揮系統の標準。 https://www.fema.gov/
4. AWS「Summary of the Amazon S3 Service Disruption in the Northern Virginia Region」（2017年2月28日） — 運営コマンドの入力ミスによる障害の公式説明。 https://aws.amazon.com/
5. British Airways 障害に関する報道（2017年5月27日） — 電力供給の作業に起因する大規模障害。 https://www.bbc.com/
6. 大手SNS世界障害に関する公式説明（2021年10月4日、Santosh Janardhan） — ネットワーク経路撤回により社内手段が失われた経緯。
7. Gary Klein『Sources of Power』（1998） — 時間制約下での意思決定（自然主義的意思決定）の研究。
8. James Reason『Human Error』（1990） — 組織事故の層モデル（スイスチーズモデル）。
9. Sidney Dekker『Field Guide to Understanding ‘Human Error’』 — 人の失敗を個人責任に還元しない見方。
10. John Allspaw「Blameless PostMortems and a Just Culture」（2012, Etsy Code as Craft） — 責任追及しない振り返りの原典。 https://www.etsy.com/codeascraft
11. NIST SP 800-61『Computer Security Incident Handling Guide』 — インシデント対応の4段階（準備・検知分析・封じ込め・復旧）。 https://csrc.nist.gov/
12. JPCERT/CC『インシデント対応ガイド』 — 日本における対応手順の実務資料。 https://www.jpcert.or.jp/
13. ITIL 4（AXELOS） — インシデント管理と問題管理の区別。
14. Karl E. Weick & Kathleen M. Sutcliffe『Managing the Unexpected』 — 高信頼組織（HRO）の研究。
15. Charles Perrow『Normal Accidents』（1984） — 複雑で密結合なシステムにおける事故の必然性。
16. IPA『情報セキュリティ10大脅威』 — 日本組織のインシデント傾向。 https://www.ipa.go.jp/