本番障害。経験したことある人ならわかる、あの胃がキリキリする感覚。Slackが「サイトが落ちてます」で埋め尽くされ、手が震えながらSSHを叩く。何度か経験して学んだ「焦らない障害対応」の心得を共有する。
心得1：まず深呼吸、そして「何が起きてるか」を確認。 慌てて本番サーバーで適当なコマンドを叩くのが一番危ない。僕は過去に「`rm -rf /tmp`のつもりで`rm -rf / tmp`（スペースが余計）」をやらかした。まず`uptime`、`df -h`、`free -h`、`top`。基本の4つだけで状況の7割はわかる。
障害対応の基本フロー：
- 検知 — 監視アラートかユーザー報告。検知したらすぐチームに「調査中」と宣言。
- トリアージ — 影響範囲を特定。全ユーザーか一部か。全機能か特定機能か。
- 緩和（Mitigation） — 根本原因より先に、とにかくサービスを戻す。DBが重いなら読み取りレプリカに切り替え。障害サーバーをELBから外す。落ち着いてから原因調査。
- 原因特定 — ログ、メトリクス、最近のデプロイ、設定変更。時系列で追う。
- 修正 & 再発防止 — 根本原因を直して、同じ障害が起きない仕組みを作る。
心得2：絶対に一人で対応するな。 深夜でも誰かを起こせ。一人だと見落としが増えるし、「このコマンド、本当に本番で叩いていい？」のチェックができない。
心得3：ポストモーテム（障害分析書）を書け。 「何が起きたか」だけじゃなく「なぜ起きたか」「なぜ気づけなかったか」「どう再発防止するか」。個人ブログの障害でも書いてる。この習慣があるかないかで、同じ過ちを繰り返すかどうかが決まる。