■ 1. 再発防止の定義
- 再発防止の本質:
- 失敗しにくい仕組みを作ること
- 人間の努力の限界:
- 人間はミスし、忘れ、疲れ、焦る
- 人間が頑張ることには限界がある
- 再発防止で目指す状態:
- ミスを起こしにくくする
- ミスしても壊れにくくする
- 壊れても早く気づけるようにする
- システム側の改善:
- 人ではなくシステム側の改善が重要
■ 2. 原因除去のみの限界
- 原因を潰すだけでは不十分:
- 設定ミスで障害が発生し設定を修正しても、別の設定ミスは防げない
- 深掘りすべき問い:
- なぜ危険な変更ができたのか
- なぜ検知できなかったのか
- なぜ影響が広がったのか
■ 3. 再発防止のゴール
- ゴールは障害ゼロではない:
- 発生確率を下げる
- 影響を小さくする
- 早く検知する
- 早く復旧できるようにする
- 目指すべき状態:
- 次はもっとマシに壊れる状態を作ることが重要
■ 4. アンチパターンな再発防止策
- たまによく見る形骸化した対策:
- 気をつけます、レビューを徹底します、手順をちゃんと確認します
- 朝会で共有します、気合いで、といった精神論の対策
- ありがちな失敗:
- ポストモーテムを書いて終わる
- TODOだけ積まれる
- 優先順位が低く放置される
- オーナー不在
- 振り返り会後の熱量低下:
- 障害の日から日付が経つごとに熱量が下がる
- 誰もやらず数週間後に同じ原因で再発する
- SREとしては悔しい結果になる
■ 5. 放置される問題と処方箋
- 放置される問題:
- 再発防止策が取られないまま放置される事態はよくある
- 障害対応中は懸命に直すが、復旧後は他にやることが多く後回しになる
- 処方箋(1) オーナーと優先度:
- ポストモーテムでオーナーを決定させる
- その場にPMを呼んで優先度を判断させる
- 最重要以外をやらない判断をとる勇気も重要（なんとなく不安だから作ったToDoのようなものを削除、など）
- 四半期に一回程度の棚卸しを行う
- 処方箋(2) その日のうちの対応:
- その日の障害はその日のうちに対応する
- AIがある現在では、超複雑でない限りその日にできることは意外と多い
■ 6. 良い再発防止策の条件
- 良い再発防止策の要件:
- 人の注意力に依存しない
- 自動化されている
- 継続可能である
- システムで制御される
- 誰でも実行できる
- 防ぐだけが再発防止ではない:
- 早期検知
- 自動復旧、フェイルオーバー
- Rollbackの高速化
- Runbookの整備
■ 7. 再発防止策の考え方
- 問いを分けて考える:
- なぜ起きたか
- なぜ検知できなかったか
- なぜ影響が広がったか
- なぜ復旧が遅れたか
- レイヤーで見る視点:
- 障害は1箇所だけで起きるわけではない
- 設計、実装、デプロイのレイヤー
- 監視、運用のレイヤー
- 組織、コミュニケーションのレイヤー
- 複数レイヤーに問題が存在する
- 防御ラインを増やす:
- 1つの対策で完璧を目指さないことが重要
- Validation、Alert、Rollback
- Feature Flag、Canary Release
- 複数の防御ラインを持ち事故を小さくする
■ 8. AIとSRE
- AIは人間の置き換えではない:
- AIによってSREは運用作業の自動化から信頼性を設計する役割へ進化している
- 障害対応、異常検知、RCA、Toil削減に大きな変化が起きている
- 本番導入の前提条件:
- AIは確率的に動作する
- 透明性、段階的権限管理、ロールバックなど安全性を前提とした設計が必須
- 最終的なゴール:
- AI Operatorのような仕組みを通じ、信頼性がデフォルトで組み込まれたシステムを実現すること
- SREの役割の変化:
- 障害対応する人から、信頼性を自己進化させる仕組みを作る人へ変わっていく
■ 9. まとめ
- 再発防止は反省会ではない
- 人を強くするより、システムを強くする
- 気をつけるには限界がある
- 小さく改善を積み重ねることが重要
■ 10. 参考資料
- Postmortem Culture: Learning from Failure
- Blameless PostMortems and a Just Culture
- Incident postmortems
- Whose fault was it anyway? On blameless post-mortems
- Post-incident review best practices