検証できる振り返りを書く
「監視を強化する」ではなく、時系列・仕組みの原因・検証可能な改善で書く
あなたは障害振り返りの進行役です。以下の時系列と対応記録から、振り返りを書いてください：1）システムの状態や判断を変えた地点だけを残し、タイムゾーンを明記する；2）原因は「どの仕組みが欠けていたか、どの前提が崩れたか」まで掘り下げ、「人為ミス」で止めない；3）改善項目を「実施済み／未実施」に分け、担当ロール、期限、検証方法を付ける；4）「今回は運が良かった点」を独立した節にする。「監視を強化する」「意識を高める」など、検証できない項目は書かないでください。 ［障害の時系列／影響範囲／対応記録］
使い方
「今回は運が良かった点」は、システムの実際の余裕を最もよく示します。これが書けないなら、振り返りはまだ表面にとどまっています。
向いている場面
- 実際のユーザーに影響が出た障害で、エンジニアリングと経営の双方が同じ事実認識を持つ必要があります。
- 同じ種類の障害が二度目で、前回の振り返りの改善策が明らかに定着していません。
向いていない場面
- 障害がまだ収束しておらず、原因も分かっていない段階です。まず止血し、振り返りは後で書きます。
- アラートが一度鳴っただけで、ユーザー影響も状態変化もないなら、振り返りは意味を創作することになります。
例
入力
14:02 v2.3 をデプロイ 14:05 エラー率 0.1% -> 8% 14:09 ロールバック開始 14:16 ロールバック完了、エラー率は正常化 14:30 ロールバックがアプリだけで、DB migration を戻していないと判明 備考：当日はセールで、トラフィックは平時の 3 倍
得られるもの
原因を「デプロイのせい」にしてはいけません。ロールバック手順がアプリを対象にしていても migration を含んでいなかったためロールバックは完了しておらず、この仕組みの欠落が問題です（セール日の 3 倍トラフィックは影響を増幅した可能性はありますが、根本原因ではありません）。14:09 に誰がどの指標でロールバックを決めたかを足し、改善項目は「ロールバック手順に migration を含め、演習済みにする」とし、次回リリース前の dry-run 記録で検証します。
よくある誤用
- 振り返りを責任追及として書くことです。各自が防御的な説明に移り、欠けていた仕組みが紙に残りません。
- 「リリース手順を改善する」のような改善項目です。担当も検証方法もなければ、3 か月後も同じ一文が残ります。
こう変えると効く
- 「当日の当番の視点で情報の不足を書く」と加えると、ダッシュボードに出ない組織的な問題が見えます。
- 「改善項目ごとに、失敗しうる検証を一つ付ける」と求めると、「直しました」が申告から証拠に変わります。