障害報告プレゼン：資料作成メモ

自社の記録に置き換えて使うための架空事例です。実際の顧客障害や製品テストの記録ではありません。

振り返りに参加する相手：
この会議で答える問い：
障害記録の参照先・承認された共有範囲：
発生日・タイムゾーン：
確認済みの元記録・記録の担当者：

事例の記録（すべて同じ架空の発生日、UTC）
09:00：リリース開始。記録上最初のレポート生成ジョブの失敗も発生。
09:04：オンコール担当にアラートが届く。
09:12：ロールバック開始。
09:27：監視により、新規のレポート生成ジョブが正常に完了していることを確認。
10:00：影響を受けたと特定した 180 件すべてについて、照合記録上の完了を確認。
180 件は重複しないジョブ ID の数であり、顧客の実人数ではない。
失敗時のログには、未知のステータスというエラーがある。
そのステータスを生じさせたコンポーネントと、リリース前のテストで見つからなかった理由は調査中。
確認済みの顧客実人数や、事業への影響額の計算はない。
処理完了だけでは、内容が正しいことやデータ損失がないことまでは確認できない。

7 枚の構成
1. 確認された影響範囲、現在の状態、未決定のリリース判断。
2. 影響を受けた業務の流れと 180 件の定義。顧客数は未確認。
3. 時系列：最初の失敗、検知、ロールバック、新規処理の復旧、残りの処理完了。
4. 観測した事実／考えられる説明／追加で必要な根拠。
5. 根拠のある具体的な対応の良かった点・遅れ。教訓を作り足さない。
6. 改善案、担当を引き受ける人の確認、優先順位、完了を確認する根拠。
7. 実際の決定事項、未確認の根拠、次にリリースを検討するための条件。

改善案の例（未承認・未完了）
互換性テスト：失敗した送信側とワーカーの組み合わせで、拒否されたステータスを再現する。修正した組み合わせでは、期待する動作を記録する。
復旧手順：訓練で、新規処理の復旧、影響を受けたジョブの照合、未解決ジョブを別々に記録する。

各説明の記入欄
説明する内容：
観測した事実／推定／不明：
参照元、事象発生時刻、記録時刻：
影響の定義・分母：
この根拠からは言えないこと：

各改善案の記入欄
具体的な変更：
対処する失敗や遅れ：
担当を引き受けた人：
優先順位・期限：
確認する根拠：
残る不確かさ：

資料作成の指示
提供した記録から障害の振り返り資料を下書きしてください。影響、検知、ロールバック、新規ジョブの復旧、影響を受けたジョブの照合を分けてください。観測した事実と仮説を区別し、不明点、参照元、タイムゾーンを残してください。影響を受けた顧客数、損失額、原因、担当者の承諾、対策の完了を作り足さないでください。

振り返りの後に記録すること
実際に合意した判断と条件：
未解決の問いと、根拠を確認する担当者：
引き受けられた対応と確認日：
元記録を更新した人：