AIで障害の時系列を整理するときは、異常を確認した時刻、通知を受けた時刻、対応を始めた時刻、回復を確認した時刻を分けます。最初のアラートを障害の発生時刻にしたり、対応後に成功したことだけで原因を確定したりしないよう、各行を原記録へ結び付けます。
この記事では、架空の監視・作業・集計記録から、根拠付きのタイムラインと未確認事項を作ります。成果物は事後分析の材料で、実際の障害対応、ログ取得、AI分析、復旧操作は行っていません。
目次
時刻の種類と、資料の範囲を決める
今回の対象は架空の申請APIです。日付は2026年10月20日、すべて日本時間とします。時刻は各資料に記録されたイベント時刻で、資料を後から閲覧した時刻ではありません。時計のずれはない設定ですが、実データならタイムゾーン、時計の同期、ログの記録遅延も確認します。
Google SREのポストモーテム資料は、事象、影響、対応、原因、再発防止の行動を記録し、組織の学びへつなげることを説明しています。以下はその考え方を参考にした独自例で、原因調査を終えた実例ではありません。Google SRE：Postmortem Culture（新しいタブで開く）
時系列の表には、イベント時刻、出所、確認できる内容、確認できないことを持たせます。チャットへ後から「9時ごろからおかしかった」と書かれた場合は、その投稿時刻と、発言が指す推定時刻を同じ欄へ押し込みません。
監視、通知、対応、確認を別の行にする
表は横にスクロールできます
| 根拠ID | イベント時刻 | 架空の記録 | この記録だけでは言えないこと |
|---|---|---|---|
| E01 | 09:00 | 対象APIの監視チェック成功 | 全利用者の処理が正常だったこと |
| E02 | 09:05 | 今回の資料で最初の監視チェック失敗 | 異常が始まった正確な時刻 |
| E03 | 09:08 | アラート通知を受信 | 09:08に障害が発生したこと |
| E04 | 09:20 | 接続設定の切替作業を開始 | 作業がこの時刻に完了したこと、原因が設定だったこと |
| E05 | 09:35 | E02以降、今回の資料で最初に監視チェック成功を確認 | 全機能の回復、恒久対策の完了 |
| E06 | 09:45 | 09:35以降の10分間、対象監視で失敗の追加なしと記録 | 以後の再発がないこと |
| E07 | 10:00 | 09:05以上09:35未満の対象API集計：120リクエスト、失敗24 | 影響した人数、全システムの失敗率 |
この表は手製の架空記録です。資料にない監視チェックや操作完了時刻を補っていません。成功・失敗は指定した監視やAPIの範囲であり、全サービスへ自動で広げません。
Google SREの記載例も、Detection、Resolution、Timeline、Action Itemsなどを分けています。監視通知と事象の始まりを別々に追える構造を参考にし、例の実時間や対策を自分の障害へ流用しないでください。Google SRE：Example Postmortem（新しいタブで開く）
計算した時間には、開始点と終了点を付ける
今回、09:05から09:08までは3分、09:20から09:35までは15分、09:05から09:35までは30分、09:35から09:45までは10分です。
表は横にスクロールできます
| 区間 | 時間 | 報告に使う名前 |
|---|---|---|
| E02→E03 | 3分 | 最初の失敗確認から通知受信まで |
| E04→E05 | 15分 | 切替作業開始から成功確認まで |
| E02→E05 | 30分 | 最初の失敗確認から成功確認まで |
| E05→E06 | 10分 | 成功確認後に記録された監視区間 |
E02→E05の30分を、そのまま実際の障害継続時間としません。資料上の正常確認は09:00、最初の失敗確認は09:05ですが、発生の正確な時点は未確認です。途中の全利用者の状態も、この表にはありません。
同様に3分を、正確な発生時刻から測った検知時間と呼ばないでください。今回は一つの事象の時刻差であり、複数事象を集計した平均検知時間や平均復旧時間でもありません。定義を付けずに略語だけで報告すると、別の指標へ読み替わりやすくなります。
失敗リクエストと、影響した人数を分ける
E07の範囲では、失敗24 ÷ 全120＝20%です。集計範囲は対象APIの09:05以上09:35未満で、09:35ちょうどのリクエストは含めません。監視の成功時刻と、リクエスト集計の区間は別に明記します。
24件は失敗リクエスト数です。同じ利用者の再試行が含まれるか、同じ業務処理が何回送られたかは不明なので、24人が影響したとは書きません。また、120件のうち失敗以外もあるため、この集計から「全処理が30分間停止」とは言えません。
影響を詳しく調べるなら、リクエストと業務処理、必要に応じて利用者を対応させる記録を、許可された範囲で確認します。人数の推測値を追加して表を埋めるより、何をまだ数えられていないかを残します。
時系列上の前後関係を、原因へ変換しない
「切替作業を始めた後、成功を確認した」という順序はE04・E05から言えます。しかし、この2行だけでは切替が回復を引き起こしたことや、切替前の設定が根本原因だったことは証明できません。作業の完了時刻や変更内容も、この資料にはありません。
原因欄は「未確認」とし、設定差分、関連するエラー、同時に行われた別作業など、確認候補を分けます。担当者が原因を調べるための質問であり、それらが実際に存在したと断定する表ではありません。
再発防止案も、実施済みの対策と混ぜません。監視の成功を確認したこと、一定時間追加失敗がなかったこと、恒久対策を検証したことを別の状態にします。個人のミスと結論する材料もありません。
掲載例の区間と割合を検算する
次のPythonは、固定した架空時刻の差とE07の割合を検算します。ログを取得・解析するコードではありません。
from datetime import datetime
from fractions import Fraction as F
raw = {"E01": "09:00", "E02": "09:05", "E03": "09:08",
"E04": "09:20", "E05": "09:35", "E06": "09:45", "E07": "10:00"}
events = {key: datetime.fromisoformat("2026-10-20T" + value + ":00+09:00")
for key, value in raw.items()}
pairs = (("E02", "E03"), ("E04", "E05"), ("E02", "E05"), ("E05", "E06"))
minutes = [(events[end] - events[start]).total_seconds() / 60
for start, end in pairs]
assert minutes == [3, 15, 30, 10]
assert F(24, 120) == F(1, 5)
assert events["E01"] < events["E02"] < events["E03"]
start, end = events["E02"], events["E05"]
assert start <= events["E02"] < end
assert not (start <= events["E05"] < end)
print(minutes, F(24, 120))
これは指定値の計算で、24件・120件を実ログから数えた処理ではありません。時刻の精度、時計のずれ、ID重複、タイムゾーン変換、同時イベントの因果を検査する汎用処理でもありません。原資料と照合した範囲を別に示します。
事後分析へ渡す未確認事項を残す
表は横にスクロールできます
| 確認したいこと | この例で不足する材料 | 状態 |
|---|---|---|
| 発生の正確な時刻 | 正常・異常の間や、それ以前を含む詳細記録 | 未確認 |
| 利用者・業務への影響 | 再試行や業務処理との対応 | 未確認 |
| 回復と作業の関係 | 作業完了、変更差分、他の関連記録 | 未確認 |
| 恒久対策と検証 | 調査後に合意する対応と確認条件 | 未決定 |
質問ごとに確認先、担当、期限を決めますが、入力に担当者名や合意した期限がない場合は未設定として残します。AIが作った調査案を、すでに実施した作業の行へ混ぜないでください。
AIへは、根拠のある時系列と不足だけを返させる
架空の記録E01～E07から、障害の事後分析用タイムラインを整理してください。
イベント時刻、根拠ID、観察したこと、解釈、未確認を別欄にしてください。
アラート時刻を発生時刻へ、成功確認を全機能復旧へ読み替えないでください。
区間の時間は開始・終了の根拠IDと一緒に示してください。
失敗リクエスト数を利用者数へ変換せず、集計区間を明記してください。
作業の後に回復したことだけで原因や効果を断定しないでください。
出力：タイムライン、区間計算、確認済み影響、原因の状態、次の確認事項。
入力にない作業完了、恒久対策、担当、期限を補完しないでください。
この依頼と整理表は手製例で、AIの正答率や実際の障害対応を評価したものではありません。共有前に、観測範囲、発生時刻の不確かさ、原因未確認が短い概要から消えていないかを点検します。資料が追加されたら、前の版と根拠を残して更新し、新たに判明した事実と以前の仮説を区別してください。
参考資料
- Google SRE：Postmortem Culture — Learning from Failure（新しいタブで開く）
- Google SRE：Example Postmortem（新しいタブで開く）
公式資料の確認日：2026年10月20日。API、監視、作業、時刻、リクエスト集計は独自の架空例です。掲載Pythonと計算をローカルで検査しました。実障害、ログ取得、AI分析、影響人数、原因、復旧・恒久対策、連絡・共有、画面表示は未検証です。