インシデントの振り返りに使う時系列の作り方

障害の事後検証では、アラート、緩和策、復旧の時刻は覚えていても、利用者への影響がアラートより前に始まっていたことを見落としがちです。タイムラインにすると、記録された出来事と後から考えた説明を分け、調べるべき空白を見つけられます。

時刻を検証できる形で残します。 タイムゾーン、時刻の出典、確度を記録し、空欄を推測で埋めず「未確認」と表示します。検知、確認、影響の抑制、復旧、フォローアップを分けて並べましょう。最初のアラートが顧客への影響開始時刻とは限りません。

共同作業ボードには、事実、疑問、改善案を並べて置けます。Google SREの事後検証の考え方は、詳しい時系列、個人を責めない学習、検証可能な改善を重視します。以下の時刻は架空の例であり、Boardmixの顧客データではありません。

並べる前に記録を集める

エラーログ、リリース記録、対応チャネルの会話、サポートへの問い合わせ、サービスの指標を確認します。タイムゾーンを明記し、発生時刻とチームが知った時刻を区別します。資料ごとに時刻が異なるなら、調査するまで両方残しましょう。

例：予約確認のエラー

この順序だけでは、リリースが唯一の原因とは言えません。コード、設定、実際の動作を照合します。また、エラー率が戻ったことと、遅れた予約確認がすべて完了したことは別です。

影響と仮説を分けて示す

時間軸の下に、利用者への影響、通知、判断、未解決の問いを置きます。「09:16にアラートが届いた」は検証できます。一方、「当番者の対応が遅かった」では、当時どの情報が届いていたのか分かりません。原因の仮説は確定した事実と別に扱います。

Boardmixに時系列をまとめる

横軸に時刻を配置し、その下に確認できた影響を並べます。機密ログを公開ボードへ貼る代わりに、権限付きの原本へリンクします。最初の失敗とアラートの八分間の差を問いとして残し、改善案には担当者と確認方法を付けます。

「監視を改善する」だけでは実施内容が不明です。どの通知条件を変え、後でどう確かめるかを決めましょう。運用上の事実は監視システムで確認し、ボードは検証の議論に使います。