第1章：トラブルシューティングの基本フレーム（症状/影響/再現/仮説）
この章で学ぶこと
- 症状（Symptom）と影響（Impact）を分けて整理する
- 再現条件を把握し、仮説を立てて検証する
- 調査ログを残しながら進める
- 観測事実、仮説、判断、実施、結果を分けて記録する
成果物（または判断基準）
本文
初動では、修正よりも状況の固定（影響拡大の抑止、観測可能性の確保）を優先する。症状と影響を分けると、優先順位（復旧優先か原因特定優先か）を判断しやすい。
注: 再起動などの暫定対応は、証跡（ログ/メトリクス）を上書きする場合がある。実施前に最小限の証跡を確保する。
基本フレーム
- 症状: 何が起きているか（観測事実）
- 影響: 誰に/どれくらい影響しているか
- 再現: 条件が揃うと再現するか
- 仮説: 何が原因候補か
- 検証: 何を観測すれば否定/支持できるか
調査ログは“試行の羅列”ではなく、“仮説と結果”を追跡できる形で残す。
調査ログで分けるもの
インシデント対応では、事実と推測が混ざると誤った復旧判断につながる。記録では次を分ける。
| 区分 | 書くこと | 例 |
|---|---|---|
| 観測事実 | ログ、メトリクス、ユーザー報告など確認できた情報 | 10:12 JST から決済 API の 5xx が 6% に上昇 |
| 仮説 | 原因候補。まだ確定ではないことを明示する | 直近デプロイで DB 接続数が増えた可能性 |
| 判断 | なぜその対応を選ぶか | 影響が継続しているため暫定 P1 とする |
| 実施 | 誰が何をしたか | 10:25 JST に機能フラグを OFF |
| 結果 | 実施後に何が変わったか | 5xx 率が 1% 未満に低下 |
仮説は否定された場合も残す。後続担当が同じ調査を繰り返さないためである。
具体例（場当たり→再現性）
悪い例（場当たり）
とりあえずサーバー再起動
ログを見ない
誰に影響しているかを確認しない
良い例（再現性）
症状: API の 5xx が増加（request-id で確認）
影響: 決済が失敗（最大 8%）
仮説: DB 接続枯渇
検証: 接続数/待ち時間メトリクスとエラーログを確認
記録: タイムラインに判断と結果を残す
チェックリスト
- 症状と影響を分けて書いた
- 仮説と検証方法がある
- タイムラインに観測事実/仮説/判断/実施/結果が残っている
まとめ
- 症状（観測事実）と影響（顧客・業務影響）を分離して整理する
- 再現条件、仮説、検証結果をセットで記録し、意思決定の根拠を残す
- 観測事実と仮説を混ぜず、否定された仮説も後続担当向けに残す
次章への接続
- 次章: 第2章