第1章：トラブルシューティングの基本フレーム（症状/影響/再現/仮説）

この章で学ぶこと

• 症状（Symptom）と影響（Impact）を分けて整理する
• 再現条件を把握し、仮説を立てて検証する
• 調査ログを残しながら進める

成果物（または判断基準）

• インシデント記録（付録: インシデント記録）
• タイムライン（付録: タイムライン）

本文

初動では、修正よりも状況の固定（影響拡大の抑止、観測可能性の確保）を優先する。症状と影響を分けると、優先順位（復旧優先か原因特定優先か）を判断しやすい。

注: 再起動などの暫定対応は、証跡（ログ/メトリクス）を上書きする場合がある。実施前に最小限の証跡を確保する。

基本フレーム

• 症状: 何が起きているか（観測事実）
• 影響: 誰に/どれくらい影響しているか
• 再現: 条件が揃うと再現するか
• 仮説: 何が原因候補か
• 検証: 何を観測すれば否定/支持できるか

調査ログは“試行の羅列”ではなく、“仮説と結果”を追跡できる形で残す。

具体例（場当たり→再現性）

悪い例（場当たり）

とりあえずサーバー再起動
ログを見ない
誰に影響しているかを確認しない

良い例（再現性）

症状: API の 5xx が増加（request-id で確認）
影響: 決済が失敗（最大 8%）
仮説: DB 接続枯渇
検証: 接続数/待ち時間メトリクスとエラーログを確認
記録: タイムラインに判断と結果を残す

チェックリスト

• 症状と影響を分けて書いた
• 仮説と検証方法がある
• タイムラインに判断/実施/結果が残っている

まとめ

• 症状（観測事実）と影響（顧客・業務影響）を分離して整理する
• 再現条件、仮説、検証結果をセットで記録し、意思決定の根拠を残す

次章への接続

• 次章: 第2章