障害後に「担当者が確認を忘れた」と結論づけても、同じ条件なら別の人も失敗します。人ではなく、失敗を許した仕組みを調べます。
確認すること
- 何が起き、利用者へどう影響したか
- いつ検知し、いつ復旧したか
- 当時、担当者に何が見えていたか
- どの防御や確認が働かなかったか
- 何が影響を小さくしたか
行動項目
「注意する」ではなく確認可能な変更にします。
悪い例: デプロイ前によく確認する
改善例: 本番DB変更前にdry-runと別担当者の承認を必須にする
全部を直さない
発生確率、影響、実装コストから優先順位を決め、担当と期限を付けます。
心理的安全性
失敗を隠す方が安全な場では、時系列も原因も集まりません。責任をなくすのではなく、事実を共有して改善できる状態を作ります。
次に読む記事
← 一覧に戻るPR
PR
