本番のWebサイトがちょうどダウンしました。どう対応しますか?

Question

Accepted Answer

最優先は**まずサービスを復旧し、それから原因を見つける**ことです。緩和が診断に先行します。私ならincidentを宣言し、役割を明確に割り当て、コミュニケーションを取り続けながら、最も速く安全な復旧に向けて推進します。

## まず安定させる

- **incidentを宣言**し、単一のチャネル(war room / Slackスレッド)を開いて、調整が散らばらないようにします。
- **役割を割り当てる**: 意思決定をする**Incident Commander**、stakeholderに更新を伝える**コミュニケーション担当**、そして調査する**対応者**。Tech Leadとして私はしばしばICを引き受け、エンジニアが問題に集中できるようにします。
- **最も速く、元に戻せる修正に手を伸ばす。** デプロイが障害と相関しているなら、まず**rollback**して質問は後にします。ユーザーを復旧させることは、正しくあることに勝ります。

## 並行して診断する

- **明白なシグナル**を確認します。ダッシュボード、エラー率、直近のデプロイ、インフラの変更、トラフィックの急増、期限切れの証明書など。
- 仮説を立て、最も安いものから先に検証し、**一度に5つのことを変えない**ようにします。何が効いたのか分からなくなるからです。

## 継続的にコミュニケーションする

沈黙はパニックを生みます。私はニュースがないときでも、安定したリズムで更新を送ります:

```
[14:05] 調査中 — checkoutがダウン、約40%のユーザーに影響。次の更新は14:20。
[14:20] 特定: 不正なデプロイ。今からrollback中。ETA 10分。
[14:35] サービス復旧。監視中。postmortemは後ほど。
```

## 復旧後

- 「良くなったように見える」だけでなく、完全な復旧を確認します。
- 数日以内に**blamelessなpostmortem**を実施します。タイムライン、根本原因、検知/修正を遅くした要因、そして**オーナー付きの具体的なアクションアイテム**。
- アウトプットは体系的な改善(より良いアラート、ガードレール、rollbackの自動化)であって、責める相手の名前ではありません。

## 落とし穴

- ユーザーが苦しんでいる間に**緩和の前にデバッグする**こと。
- **単一の意思決定者がいない**ため、5人が並行して当てずっぽうをすること。
- stakeholderに対して**音信不通になる**こと。
- **個人を責める**こと。これは将来のincidentが依存する正直さを殺します。

## なぜ重要なのか

障害は避けられません。それをどう運用するかが、チームの信頼と顧客の信用を定義します。冷静で役割ベースの調整と、blamelessなフォローアップが、悪い一日をより強いシステムへと変えます。そしてそれは、失敗が魔女狩りではなくプロセスとして扱われるからこそ速く動いても安全だ、とエンジニアに示すことになります。