タイムラインが報告書の半分だ

一言でいうと

タイムラインは出来事の羅列ではなく、各区間が何を意味するかを表に出す道具であり、その区間が、そのまま次回に縮めるべき時間です。

なぜ必要なのか

障害報告書で、顧客が最初に読むのは原因分析ではなく、タイムラインです。理由があります。タイムラインは、「私たちがどれだけ長く気づかなかったか」と「気づいてからどれだけ早く動いたか」を、同時に見せるからです。

そして、この2つの数字が、来四半期の改善課題を決めます。

どう動くのか

使えるタイムラインには、5つの時刻があります。

変更時刻: 何かが変わったとき。デプロイ、設定変更、トラフィックの急増。 影響開始時刻: ユーザーが実際に失敗を経験し始めたとき。 認知時刻: 私たちが気づいたとき。アラートが鳴ったか、顧客が報告したとき。 措置時刻: 緩和措置が入ったとき。 復旧確認時刻: 同じ物差しで測り直して、正常を確認したとき。

そして、この5つの間の4つの区間が、それぞれ名前を持ちます。

変更 → 影響: 潜伏区間です。短ければすぐに表に出たのであり、長ければ、特定の条件が溜まって初めて起きるタイプです。後者のほうがはるかに恐ろしいです。

影響 → 認知: 検知遅延です。この値が大きければ、問題はシステムではなく観測です。顧客が先に知らせてくれる状況が繰り返されると、原因をどれだけうまく直しても、信頼は回復しません。

認知 → 措置: 対応遅延です。ランブックがあれば短く、なければ長くなります。

措置 → 復旧確認: 検証区間です。この区間がない報告書は、「直したと思う」までしか言っていません。

現場での姿

ここで、よく出てくる判断を1つ指摘しておきます。影響継続時間を、どこからどこまでで数えるかです。

変更時刻から数えると実際より長くなり、措置時刻までしか数えないと実際より短くなります。ユーザーの視点で正直な計算は、影響開始から復旧確認までです。ユーザーはデプロイがいつだったかを知らず、ロールバックコマンドが入った瞬間ではなく、実際に正常になった瞬間に、影響から抜け出すからです。

そして、タイムラインを書くときに守るべきルールがもう1つあります。人の名前を書きません。「誰それが03:19にデプロイ」ではなく、「03:19 payment 2.7.0をデプロイ」です。

これは道徳ではなく計算です。顧客企業の報告書に特定の担当者が名指しされると、次の障害でその人は情報を隠します。すると、次回の検知遅延が増えます。責任追及をしない報告書は、次の診断の速さを買う投資です。

時刻をそろえるのが半分

複数の出所のログを1行に並べるとき、最初に引っかかるのが、タイムゾーンと精度です。

出所	よくある形式	落とし穴
アプリケーションログ	`2026-09-06 12:04:31`	タイムゾーンがない。サーバーのローカルなのかUTCなのかがわからない
Kubernetesイベント	`2026-09-06T12:04:31Z`	UTC固定。アプリログと9時間の差
クラウドコンソール	ブラウザーのローカル時間	見る人ごとに違って見える
アラート	発生時刻ではなく評価時刻	実際より1–5分遅い

すべてUTCに変換して書き、ドキュメントの一番上に、そう書いたと明記します。そして、アラートは「検知時刻」であって「発生時刻」ではないことを表示します。この区別をしないと、「アラートが遅かった」と「障害が遅く始まった」を混ぜてしまいます。

精度もそろえます。秒単位のログとミリ秒単位のログを同じ行に並べるときは、秒に切り捨てます。ない精度をあるように書くと、因果がひっくり返って見えます。

何を因果と見なすのか

時間順に並べると、前後関係は見えますが、因果は見えません。3つを確認して初めて、因果だと言えます。

時間の整合: 原因が結果より先か。伝播遅延を考慮しても、順序が合うか。
範囲の整合: 原因の影響範囲と症状の範囲が同じか。Podが1つだけ変わったのに、全体が落ちたなら、ほかの原因があります。
元に戻す検証: 原因を元に戻したとき、症状が消えたか。これが最も強い証拠です。

3つのうち1つでも合わなければ、「関連がありそうなもの」として書き、確定しません。タイムラインのドキュメントで、推定と確認を区別して表示することが、信頼を作ります。

| 시각(UTC) | 사건 | 출처 | 확인 |
|---|---|---|---|
| 03:19:02 | payment 2.7.0 배포 시작 | Argo CD | 확인 |
| 03:19:40 | payment 파드 5xx 시작 | 앱 로그 | 확인 |
| 03:23:11 | 결제 실패율 경보 | Alertmanager | 확인(평가 시각) |
| 03:24 경 | 고객 문의 유입 | 지원 티켓 | 추정(티켓 시각은 접수 시각) |
| 03:31:05 | 2.6.4 로 롤백 | Argo CD | 확인 |
| 03:31:52 | 5xx 소멸 | 앱 로그 | 확인 — 되돌림으로 인과 성립 |

このコードブロックの韓国語の表は、時刻(UTC)・出来事・出典・確認の4列で、03:19:02のpayment 2.7.0のデプロイ開始から、Podの5xx開始、アラート(評価時刻)、顧客からの問い合わせ(受付時刻に基づく推定)、2.6.4へのロールバック、5xxの消滅(元に戻すことで因果が成立)までを示しているという意味です。

次のラボですること

デプロイ履歴、アプリケーションログ、アラート履歴から、5つの時刻をそれぞれ抜き出し、時間順に並べたタイムラインのドキュメントを作り、ユーザー視点の影響継続時間を計算します。