障害タイムラインは、検知から復旧までの事実・判断・操作・結果を、共通の時刻基準で並べた記録です。 結論は、きれいな物語を後から作るのではなく、障害中に短い行を追記し、推測が外れても消さないことです。
なぜ必要か
障害中はメトリクスも担当者も刻々と変わります。記憶だけに頼ると、操作の前後関係や判断時点で見えていた情報が失われます。タイムラインがあれば、交代要員は調査を再開でき、事後レビューでは復旧を遅らせた情報不足や有効だった対応を検証できます。
タイムラインは誰かの責任を確定する表ではなく、その時点で何が分かり、何をしたかを再現する資料です。
登場人物と対象
インシデントコマンダー、調査・操作担当、記録担当、社内外の連絡担当が主な登場人物です。一人で対応する場合も役割を意識し、操作前後に一行ずつ残します。対象にはアラート、利用者影響、ログ、メトリクス、デプロイ、設定変更、連絡、復旧判定を含めます。
記録の流れ
- 発生日時、記録タイムゾーン、対象サービスを固定する。
- 最初の検知と利用者影響を書く。
- 観測、仮説、判断、操作、結果を別行にする。
- 担当交代・エスカレーション・外部連絡も記録する。
- 復旧条件を観測し、監視継続の期限を書く。
- 事後にログと照合し、推定時刻を明示して補う。
一行の型
10:02 JST [検知] 5xx率アラートが発火
10:05 JST [確認] ログインAPIで5xx増加、閲覧APIは成功を確認
10:08 [操作] 直前リリースを前バージョンへ戻した
10:12 JST [結果] ロールバック後、対象アラートが回復条件を満たした
架空の平常値を置かず、実際のダッシュボード名、クエリ、アラート条件へリンクします。数値が取得できない時は「未確認」と書きます。
記録パターンの比較
| 種類 | 書く内容 | 混ぜないもの |
|---|---|---|
| 観測 | ログ・画面・指標で確認した事実 | 原因の断定 |
| 仮説 | 事実を説明できる候補 | 確定表現 |
| 判断 | 選択と根拠、判断者 | 操作結果 |
| 操作 | 対象、実行者、変更内容 | 成功の推測 |
| 結果 | 操作後の観測 | 因果の断定 |
「操作した」と「回復した」を別行にすると、単なる時間的な連続を因果関係と誤認しにくくなります。
分ける項目
- 観察した事実
- 立てた仮説
- 行った操作
- 操作後の結果
- 判断した人と理由
仮説が外れても削除せず、その後に否定された事実を追記します。
相対時刻を避ける
「さっき」「少し後」ではなく、タイムゾーンを含む時刻を使います。複数システムのログ時刻がUTCか日本時間かも確認します。
時計のずれが疑われる場合、元ログの時刻と変換後時刻を残します。事後に追加した行には「追記」と情報源を付け、障害中の認識と後から判明した事実を区別します。
よくある誤解
議事録を全文書き起こす必要はありません。復旧判断に関係する事実と操作を優先します。誤った仮説は削除しません。否定された時刻と証拠を追記することで、調査の重複を防げます。また、復旧時刻は「最後のエラー時刻」と同じとは限らず、定めた正常条件を満たした時刻で判断します。
注意とベストプラクティス
- トークン、個人情報、顧客データを貼らず、安全なログ参照先を示す。
- 変更系操作には対象環境、実行者、承認、戻し方を残す。
- チャットの重要判断をタイムラインへ転記する。
- 画像だけでなく検索可能なテキストでも要点を残す。
- 記録作業が復旧を妨げる時は、最低限の時刻と操作を優先する。
デバッグ・確認方法
事後に監視、デプロイ履歴、監査ログ、チャットの時刻を照合します。時刻順が逆転していないか、操作の対象と結果が対応しているか、利用者影響の開始・終了根拠があるかを確認します。推定しかできない箇所は範囲または「推定」と記します。
ケーススタディ：決済APIの断続的な失敗
21時03分に決済成功率の低下を検知し、21時08分に直前のアプリ更新を戻したとします。21時10分に成功率が上がっても、ここで「原因は更新、復旧済み」と書くのは早すぎます。外部決済事業者の遅延が同時に解消した可能性や、失敗した要求の再試行がまだ続く可能性があるからです。
記録担当は、まず「21:03 JST [検知] 決済成功率アラート発火」「21:05 JST [観測] 決済APIのタイムアウト増加、注文作成APIは平常範囲」のように影響範囲を分けます。次に「21:08 JST [操作] アプリを版Aから版Bへ戻した」と対象を明記し、「21:10 JST [結果] 直近5分の成功率が回復条件を1回満たした」「21:20 JST [復旧判定] 10分間連続で回復条件を満たし、滞留要求がないことを確認」と観測窓を残します。これなら、操作直後の一時的な改善と復旧判定を区別できます。
判断手順と失敗条件
記録に迷ったら、第一に「この行は画面、ログ、通知、発言のどれで確認できるか」、第二に「事実、仮説、判断、操作、結果のどれか」、第三に「交代者が次の行動を選ぶために必要か」を順に確認します。出典がない原因推測は仮説へ移し、操作対象や実行者が不明ならその場で補います。復旧条件が決まっていない場合は、回復を宣言する前に正常とみなす指標、観測時間、滞留処理の扱いを決めます。
タイムラインの失敗条件は、時刻が多いことではなく、再現に必要な関係が切れていることです。具体的には、操作前の状態がない、操作と結果が同じ文で因果として断定される、復旧判定に観測窓がない、タイムゾーンが混在する、チャット上の承認だけが残る、後日の訂正が元記録を上書きする、といった状態です。一つでも重要操作に該当すれば、事後検証で「何が効いたか」を確かめられません。
良い例と悪い例
悪い例は「21時ごろ決済障害。ロールバックして直った」です。影響範囲、版、実行者、観測値、復旧条件がなく、時刻も曖昧です。良い例は「21:08 JST [操作/担当:佐藤] 本番決済APIを版Aから版Bへ戻した。変更記録INC-42」「21:10 JST [結果] 成功率が回復条件を1回満たした。10分間の監視を継続」のように、操作と観測を分けます。良い記録でも秘密情報や顧客の決済情報は貼らず、アクセス制御された監視画面や監査記録の識別子を示します。
観測方法として、各重要操作に前後一つ以上の観測行があるか、復旧行から監視クエリへ到達できるか、別担当が現在の影響と次回確認時刻を説明できるかを確認します。さらに、ログ時刻と記録時刻の差を数件標本確認します。時計のずれが見つかったら全行を推測で直さず、ずれの範囲と変換規則を注記します。
実践演習：断片から時系列を再構成する
検証用のアラート通知、デプロイ履歴、チャット、アプリログを用意し、各情報のタイムゾーンを確認して一枚の表へ並べます。元の時刻を保存し、表示用時刻を別列にします。判断の根拠が見つからない行には「根拠未記録」と書き、想像で補いません。
次に、操作行を隠して観測だけを読み、交代者が現在状態を説明できるか試します。説明できなければ、利用者影響、対象範囲、最後の正常状態、進行中の仮説のどれが不足しているかを特定します。復旧行が終了条件を満たし、監視継続と次回連絡時刻があるかも確認します。
完了条件はすべての秒を埋めることではありません。重要な判断と変更操作について、前提となる観測、実行者・対象、操作後の観測を追えることです。欠落はそのまま明示し、事後レビューで扱う具体的な改善項目へつなげます。
完了判定と保管
タイムラインには、インシデント識別子、作成者、最終更新日時、参照した監視・ログの保存先を付けます。ログの保持期限が短い場合は、組織のデータ管理方針に従って必要な証拠を保全します。個人情報や認証情報を複製してはいけません。
共有前に、影響開始・検知・最初の対応・緩和・復旧の各時点が追えるか、担当交代がある場合に引き継ぎ内容が残っているかを確認します。外部向け報告と内部タイムラインでは読者と公開範囲が違うため、そのまま転記せず、確認済みの影響と現在状態を選びます。
事後レビューで時刻や事実を訂正する場合は、元の記録を黙って書き換えず、訂正理由と情報源が追える方法を必ず使います。これにより、障害中の認識と事後に確定した事実を区別できます。
まとめ
障害タイムラインは、共通時刻で事実・仮説・操作・結果を分け、復旧と引き継ぎを支える運用データです。 外れた仮説も履歴として残し、事後に一次データと照合します。正確さを装うより、未確認と推定を明示する方が信頼できる記録になります。
参考リソース
記録担当
可能なら調査担当と記録担当を分けます。一人の場合は、操作前後に短い一行だけでも残します。
