同じ種類のincidentが二度目に起きるのを防ぐために、何をしますか?

Question

Accepted Answer

システム的な原因を見つける**blamelessなpostmortem**を実施し、それを**具体的で、オーナー付きで、追跡される**アクションアイテムへと変換します — そして、それが実際に出荷されることを検証します。目標は責める相手を見つけることではなく、同じ種類の失敗が不可能になるか、自己検知できるようにシステムを変えることです。

## コアのループ

1. **blamelessなpostmortem。** 正直なタイムラインを作ります: 何が起きたか、いつ検知したか、どう対応したか、インパクトは何だったか。責めは、あなたが必要とする真実を殺します。
2. **トリガーではなくシステム的な原因まで掘り下げる。** 「エンジニアが不正な設定をプッシュした」はトリガーです。「設定にバリデーションも段階的ロールアウトもなかった」が原因です。**Five Whys**を使いますが、人ではなく必ずシステムで止めます。
3. **単一の修正ではなく、防御の層を生成する**:
   - **防ぐ** — 失敗を不可能にする(バリデーション、型、ガードレール)。
   - **検知する** — より早く捉える(アラート、SLO、合成チェック)。
   - **緩和する** — 影響範囲を限定する(rollback、flag、サーキットブレーカー)。
4. **オーナーと期日を割り当てる。** オーナーのないアクションアイテムは願望です。それらを本物の仕事としてバックログで追跡します。
5. **検証してループを閉じる。** 修正は出荷されたか? それは元の問題を捉えられたか? MTTRと検知は実際に改善したか?

## トレードオフと落とし穴

- **変更ではなくドキュメントを生むpostmortem** — 最もよくある失敗です。やり遂げなければ、同じincidentに再び出会います。
- 特定の症状を**過剰に直す**一方で、バグの種類が放置されること。インスタンスではなくカテゴリを直します。
- チューニングせずに検知を積み上げることによる**アラート疲れ**。ノイズの多いアラートは無視され、次のincidentがすり抜けます。
- **責める文化**は報告を地下に追いやります。最も安いレッスンであるニアミスを失います。
- **繰り返すincidentを不運ではなくプロセス失敗のシグナル**として扱い、再発を指標として追跡します。

## なぜ重要なのか

incidentはすでに支払った授業料です。唯一の無駄は、そこから学ばないことです。再発を体系的に防ぐチームは四半期ごとに信頼性が増す一方、ただ消火するだけのチームは同じ障害を永遠に再体験します。この学習のループ — そしてその中で正直でいられる安全性 — を築くことは、Tech Leadが残せる最も永続的なものの一つです。