はじめに：今、この記事を読んでいるあなたへ
もしあなたが今まさに本番障害の夜を過ごしているなら、まず深呼吸してください。
大丈夫です。あなたの前にも、あなたの後にも、本番障害を経験しないエンジニアは一人もいません。
この記事は、障害の渦中で頭が真っ白になっている人に向けて、「今すぐ何をすべきか」と「終わった後にどう立ち直るか」を書いたものです。
第1章：今すぐやるべきこと（行動編）
ステップ1：まず報告する（5秒）
障害の原因を調べる前に、まずチームに報告してください。
Slackの障害チャンネルに投稿：
「本番で〇〇のエラーが発生しています。影響範囲を調査中です」
不完全な情報でOKです。原因が分かってから報告しようとすると、30分〜1時間の空白が生まれ、その間にユーザーへの影響が拡大します。
ステップ2：影響範囲を把握する（5分）
原因よりも先に**「誰がどのくらい困っているか」**を確認します。
□ 全ユーザーに影響？ それとも一部のユーザーだけ？
□ 完全にサービス停止？ それとも一部機能が動かない？
□ データの破損は発生している？
□ 金銭的な影響はある？（決済・課金系）
ステップ3：「直す」か「戻す」か判断する（1分）
障害対応の鉄則：「直す時間 > 戻す時間」なら、まず戻す。
原因が明確で、修正が5分以内にできる → 直す（Hotfix）
原因が不明、または修正に時間がかかる → 戻す（Rollback）
直前のデプロイが原因なら、git revert + 再デプロイ で元のバージョンに戻すのが最速です。完璧な修正は、サービスを安定させた後で落ち着いてやればいい。
ステップ4：タイムラインを記録する
障害対応中は記憶があやふやになります。Slackのスレッドに時系列で全ての行動を書き残してください。
22:03 アラート発報。/api/users で500エラー多発
22:05 #incident-channel に報告
22:08 影響範囲確認。全ユーザーの API リクエストが失敗
22:12 直前のデプロイ（PR #1234）が原因と判明
22:15 git revert 実行、ステージングで動作確認
22:20 本番に再デプロイ。エラー率低下を確認
22:25 正常復旧を確認。関係者に報告
このログがそのまま、後日のポストモーテム（振り返り）の資料になります。
ステップ5：影響を受けたユーザーに通知する
復旧したら、ステータスページやSNS、メール等でユーザーに知らせましょう。
「〇月〇日 22:03〜22:25 の間、一部のAPIリクエストでエラーが発生しておりました。
現在は復旧しております。ご迷惑をおかけし申し訳ございません。」
第2章：復旧した後にやるべきこと（仕組み編）
ポストモーテム（事後検証）を書く
犯人探しではなく、「なぜこの障害が起きたのか」「なぜ防げなかったのか」を構造的に振り返ります。
## ポストモーテム：2026/04/05 API障害
### 概要
22:03〜22:25（約22分間）全ユーザーの API が 500 エラーを返した。
### 根本原因
PR #1234 のマイグレーションにより、NOT NULL 制約のカラムが追加されたが、
既存レコードにデフォルト値が設定されていなかった。
### なぜ防げなかったか
1. ステージング環境のDBにはテストデータが10件しかなく、
本番の100万件のレコードとの差異が反映されていなかった
2. マイグレーションの本番適用前レビュープロセスが未整備だった
### 再発防止策
1. ステージングDBに本番相当のマスクデータを投入する
2. マイグレーションを含むPRには「DB変更チェックリスト」を義務化する
3. デプロイ直後のエラー率監視アラートの閾値を5%→1%に下げる
### タイムライン
（ステップ4で記録したログをここに貼る）
第3章：あなたのメンタルを守る（最も大切な章）
「やらかした」自分を責めないでください
障害を起こした夜、あなたの頭の中はこんな声でいっぱいかもしれません。
「なんであんなコードを書いたんだ」
「もっと慎重にやるべきだった」
「みんなに迷惑をかけてしまった」
「エンジニア辞めた方がいいのかな」
断言します。これらは全て、疲労と恐怖が作り出す嘘の声です。
覚えておいてほしいこと
1. 障害を起こさないエンジニアは「何もリリースしていないエンジニア」だけ
コードを本番に反映する以上、障害のリスクはゼロにはなりません。障害を経験していないエンジニアは、単にまだリリースの経験が少ないか、運が良いだけです。
2. 障害の原因は「人」ではなく「仕組み」
あなたのコードにバグがあったとしても、それをレビューで見つけられなかった仕組み、テストで検出できなかった仕組み、本番でキャッチできなかった監視の仕組み──全てが「仕組みの穴」です。あなた個人の責任ではありません。
3. この夜を乗り越えたあなたは、確実に強くなっている
本番障害を経験したエンジニアは、次から「このコードを書いたら本番で何が起きるか」を想像できるようになります。その想像力は教科書では絶対に身につかない、あなただけの武器です。
先輩・リーダーへのお願い
障害対応後の新人に最初にかける言葉で、その新人の1年が決まります。
❌ 「なんでこんなミスしたの？」→ 新人は二度とリスクを取らなくなる
✅ 「復旧対応お疲れ様。報告が早くて助かったよ」→ 新人は次も正直に報告できる
おわりに
この記事を、いつか本番障害を経験する（または今まさに経験している）全てのエンジニアに贈ります。
あなたが世の中に向けてサービスを動かしている以上、この夜は必ず来ます。でも大丈夫。この夜を乗り越えた朝、あなたは昨日とは別のエンジニアになっています。
今は寝てください。明日ポストモーテムを書きましょう。