障害報告書の最後に「今後は確認を徹底する」と書くと、文章としては締まります。しかし次に何を変更し、誰がいつ、その効果をどう確かめるかは決まりません。
この場面では、担当者の注意喚起より、同じ条件が起きたときのシステムと運用の動きを変えることを優先します。 発生を防ぐ策と、発生しても早く気づき影響を抑える策を分けます。
以下は問い合わせ受付通知が二重に送られた、という架空の事例です。実際の顧客や障害を記述したものではありません。
まず、何が分かっているかを固定する
| 項目 | 架空の記入例 |
|---|---|
| 事象 | 受付済みの問い合わせ1件に対し、同じ内容の通知が2通届いた |
| 影響 | 9月23日 10:00〜10:18 JSTに登録された問い合わせのうち、確認できた5件で重複通知。問い合わせデータの重複登録は確認されていない |
| 検知 | 10:20に担当チームから連絡。システム監視は重複を検知していなかった |
| 復旧 | 10:31に通知ワーカーの自動再試行を一時停止。登録機能は継続。影響範囲を調べてから再開を判断 |
| 現時点の説明 | 通知サービスの応答前に通信が切れ、送信が成功したか分からないまま再試行していた。重複を拒否する識別子がなかった |
| 未確認 | 通知先に同様の事象が他にもないか。後続ログを追加確認する |
被害の件数や時間は、確認できた範囲と未確認の範囲を分けます。「5件だけだった」とは書きません。時刻は同じタイムゾーンで揃え、根拠となるログや作業票へリンクします。
「誰が押したか」で止めず、再発できた条件を探す
時系列をつなぐと、次のようになります。
| 時刻 | 起きたこと | その時点で見えていた情報 |
|---|---|---|
| 10:02 | ワーカーが通知APIを呼ぶ | 送信要求を記録 |
| 10:02 | 応答を受け取る前に接続が切れる | ワーカーは送信の成否を確定できない |
| 10:04 | 自動再試行する | 同じ問い合わせに対する2回目の要求 |
| 10:20 | 担当チームが2通の通知を見つける | 重複監視はない |
| 10:31 | 再試行を一時停止する | 追加の重複を抑えるため |
ここで「実行担当者が確認しなかった」が主原因とは言えません。応答を受け取れない通信では、送信が実際に成功したかを人が画面だけで判断できないこともあります。再試行する設計なら、重複要求を許容するか排除するかを最初から決める必要があります。
Google SREのポストモーテムの説明も、人を責める文面より、曖昧な改善項目を具体的で追跡できる作業へ変えることを重視しています。
再発防止策を「検証できる作業」にする
| 種類 | 対策・担当・期限の例 | 完了を確かめる方法 |
|---|---|---|
| 予防の前提確認 | 開発担当Aが9月25日までに、通知先が同一キーの再送を拒否できるか、キーの有効期間と確認方法を資料・検証環境で調べる | 対応可否と有効期間を記録し、再試行間隔より短くないか確認する |
| 予防（通知先が対応する場合） | Aが9月30日までに、問い合わせIDと通知種別から作る同一キーを再送時にも渡す | 応答欠落を再現し、有効期間内の同一キーで通知が1通だけ届くことを結合テストで確認する |
| 予防（対応しない場合） | Aと運用担当Bが、自動再試行を「結果不明」の要求では止め、通知先の送信履歴を照合してから再送する手順を決める | 結果不明を作るテストで自動再送されず、照合・再送の判断が記録される。完全な重複防止を約束しない |
| 影響軽減 | 運用担当Bが9月25日までに、一定時間内の同一識別子の送信回数を見られる記録を用意する | 検証環境で重複を発生させ、当番が通知を受け取れる |
| 復旧 | リーダーCが9月27日までに、再試行停止・対象絞り込み・再開判断の手順を作る | 当番以外の人が手順を読み、テスト環境で安全に再現できる |
識別子を付けるだけでは重複は消えません。「同一キーなら通知が1通」は、通知先がそのキーを受け付け、有効期間内の再送を重複排除する場合にだけ完了条件にできます。 対応しない場合は、送信履歴の照合を挟み、再送判断を記録します。通知先の履歴でも結果が分からなければ、二重通知と通知漏れのどちらの危険を優先して抑えるかを業務側と決め、影響を監視します。結果不明の通信に対して、こちらだけで「必ず一通届く」とは保証できません。
「確認を徹底する」は、どの人が見ても同じ判定になるテストや監視へ落とし込んではじめて改善項目になります。完了条件を満たさないまま対策票を閉じないことが重要です。
優先順位は影響と実行可能性で決める
全ての対策を同時に進められないなら、まず追加被害を止める暫定策を行い、次に再発を抑える変更と検知を計画します。今回はワーカー停止により通知が遅れるため、登録は続けても担当チームへ別の連絡手段が必要かを判断します。「停止したから安全」と一言で済ませません。
対策にはチケット番号、担当者、期限、検証結果へのリンクを残します。Google SREの事例でも、担当・優先度・追跡先・確認できる完了状態を持つ改善項目が示されています。報告書が承認されたあとも、対策が終わるまで追跡します。
次に障害報告書を書くときは、既存の「再発防止策」を一つ選び、再現テストか監視で効果を確認できる一文へ書き換えてみてください。
