このユニットの結論
本番障害が起きたとき、最初にするのは原因当てではありません。
- 何が起きているか
- 影響範囲
- 被害拡大防止
- 証拠
- 必要な人
を確認します。
1. 何の話か
月曜日 9:15。
利用者から、
「登録するとエラーになります」
という連絡。
同時に、
「外部連携も止まっている」
という報告。
監視にもエラー。
ここで、いきなり原因を決めつけないことが重要です。
2. 事実と仮説
事実:
09:07からAPI 5xxが増加した。
仮説:
09:00のreleaseが原因かもしれない。
判断:
新規処理を一時停止する。
この3つを混ぜません。
3. 最初の5確認
- 何が起きているか
- いつからか
- 誰に影響しているか
- 業務影響
- 被害が拡大中か
エラー件数だけではSeverityは決まりません。
4. THINK — とりあえず再起動する？
エラーが急増。
担当者:
「分からないので、とりあえず再起動しましょう。」
判断例を開く
判断
理由が分からないまま即再起動とは限りません。
再起動で、
- 一時復旧
- 状態変化
- 証拠消失
が起こることがあります。
事前に定めた手順や影響を確認します。
5. 初動
- 検知
- 影響確認
- 被害拡大防止
- 証拠保全
- 必要な人を集める
必要なら、
- 処理停止
- 一部機能停止
- 連携停止
- 操作制限
を検討します。
6. Severity
重大度に応じて、
- 対応責任者
- 報告先
- communication frequency
- escalation
を変えます。
呼び方よりも、対応を変えることが重要です。
7. Incident Command
重大障害では、全員が自由に動くと混乱します。
指揮役を決め、
- 優先順位
- 調査分担
- 変更統制
- 状況共有
- 次の判断
を管理します。
8. Timeline
例:
- 09:03 最終正常
- 09:07 error rate増加
- 09:10 alert
- 09:12 first user inquiry
- 09:15 incident response開始
- 09:22 new processing停止
時系列が原因調査と変更評価に使われます。
9. 変更を増やしすぎない
障害中に、
- config変更
- restart
- rollback
- DB変更
を同時に行うと、何が効いたか分からなくなります。
記録:
- 何を
- 誰が
- いつ
- 結果どうなったか
10. 復旧と原因究明を分ける
旧versionへ戻せばサービスは復旧できる。
しかし根本原因はまだ不明。
ということがあります。
サービス復旧を先に行い、原因究明を後で続ける判断もあります。
11. 「直った」で終わらない
確認:
- 未処理データ
- 重複
- data inconsistency
- external integration
- error rate
- business confirmation
これが復旧確認です。
12. AI WORKFLOW
AIには、
- logs
- timeline
- error patterns
- recent changes
- hypotheses
- missing evidence
- incident report draft
を整理させます。
指示例:
「障害情報を、確認済み事実、未確認事項、原因仮説、追加証拠、実施済み変更、現在リスクに分類してください。原因を断定しないでください。」
13. REVIEW
AIが、
「直前releaseが原因です」
と言っても、原因確定しません。
確認:
- evidence
- timeline
- reproducibility
- alternative hypothesis
- data coverage
- proposed change risk
14. 障害時にもAI権限を崩さない
障害時は焦るため、AIの提案を承認しやすくなります。
09-06で設計した、
- permission boundary
- human approval
- logging
- rollback
を障害時にも維持します。
15. Communication
関係者へ、
- 何が起きている
- 何が影響
- 現在の対応
- 次回報告
を伝えます。
原因不明なら、原因不明と伝えます。
16. 復旧後
- root cause analysis
- recurrence prevention
- monitoring improvement
- procedure update
- design improvement
- test addition
へ戻します。
障害から得た知識を、仕組みに戻して初めて改善になります。
17. 判断演習
30%の利用者が登録不可。
閲覧正常。
20分前にrelease。
rollback可能。
原因証拠なし。
「releaseが原因でしょうから、戻しましょう」
と言われました。
確認ポイントを開く
確認:
- incident start vs release time
- affected functions
- error detail
- rollback risk
- DB compatibility
- rollback後のverification
原因確定と復旧判断は別です。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
本番障害では、
速く間違えることは、速い対応ではありません。
事実を押さえ、被害を止め、証拠を残し、安全に復旧へ進みます。