本番環境のインシデント中にどのようにリードしますか？

Question

Accepted Answer

インシデント中、あなたの仕事は**サービスを落ち着いて復旧し、対応を調整すること**であり、一人で修正するヒーローになることではありません。明確な役割、落ち着いた communication、および最初に軽減することへの偏向が、スムーズな対応と混乱を分けます。

## インシデントの実行方法

```text
1. ASSIGN roles — incident commander (coordinates), responders (fix),
   comms (updates stakeholders). One person can't do all three.
2. MITIGATE first — stop the bleeding (roll back, feature-flag off)
   before chasing root cause.
3. COMMUNICATE on a cadence — even "still investigating" every 15-30 min.
4. STAY CALM — the team mirrors your energy. Blame comes later, or never.
5. After: BLAMELESS post-mortem — fix the system, not the person.
```

## 診断する前に軽減する

根本原因を見つけたいという本能は強いですが、それに抵抗してください。ロールバックがサービスを復旧する場合、*まず*それを行い、その後、プレッシャーを取り除いて落ち着いて調査してください。ユーザーは診断ではなく、ブロックを解除されることを気にしています。

## 具体例

デプロイがチェックアウトを壊します。プレッシャーの下で新しいコードをライブでデバッグしないでください。すぐにロールバックし、チェックアウトが機能することを確認し、更新を投稿し、*その後*落ち着いた状態で不良なデプロイを調査してください。

## 落とし穴

責任を問うポストモーテムは、人々に問題を隠すことを教えます。責任を問わないようにして、それが起こるのを許した体系的なギャップ（カナリアなし、アラートなし）に焦点を当ててください。

## なぜ重要なのか

インシデントは高いストレスと高い可視性を持っており、あなたがどのようにリードするかは、結果とチームの信頼の両方を形作ります。

落ち着いた調整と責任を問わない learning は、停止を次回より壊しにくいシステムに変えます。