incident-response

インシデント対応

検知からポストモーテムまでの体系的なインシデント管理と、連鎖障害を防止・封じ込めるためのレジリエンスパターンです。

使用する場面

• 本番環境でインシデントが発生している（停止、性能低下、データ損失）
• サーキットブレーカー、バルクヘッド、フォールバック戦略を設計する
• カオスエンジニアリングの演習を実施または計画する
• ポストモーテム文書を作成またはレビューする
• オンコール手順とエスカレーション経路を整備する

次の場合は使用しないでください：

• 問題が開発時のバグで、本番環境への影響がない
• 一般的なシステムアーキテクチャを設計する（代わりに system-design を使用してください）

クイックリファレンス

トピック	リファレンスを読み込む
トリアージフレームワーク	skills/incident-response/references/triage-framework.md
ポストモーテムパターン	skills/incident-response/references/postmortem-patterns.md

インシデント対応ワークフロー

フェーズ 1：検知

• アラートが発生するか、ユーザーから報告を受ける
• 問題が実際に発生していることを確認する（誤検知ではないこと）
• 影響を受けているサービスとユーザーへの影響範囲を特定する

フェーズ 2：トリアージ

• 重大度を分類する（P0-P3）
• インシデントコマンダーを割り当てる
• コミュニケーションチャネルを開設する（ウォールーム、Slack チャンネル）
• ステータスページの更新を開始する

フェーズ 3：封じ込め

• 被害の拡大を止める：ロールバック、機能フラグ、トラフィックの切り替え
• 連鎖を防ぐ：サーキットブレーカー、負荷遮断、バルクヘッドによる分離
• 連絡する：P0/P1 では 15 分ごとに関係者へ状況を報告する

フェーズ 4：解決

• 修正を実施する（まず最小限の実用的な修正を行う）
• 時間が許せばステージング環境で検証する
• 監視とロールバック計画を準備してデプロイする
• メトリクスがベースラインに戻ったことを確認し、復旧を確かめる

フェーズ 5：ポストモーテム

• 48 時間以内にタイムラインを記録する
• すべての参加者で、非難のないレビューを実施する
• 根本原因と寄与要因を特定する
• 担当者と期限を設定してアクション項目を割り当てる
• 学んだ教訓に基づいてランブックとアラートを更新する

重大度フレームワーク

レベル	影響	対応時間	例
P0	完全な停止、データ損失、セキュリティ侵害	即時（< 5 分）	サービス停止、データ破損、認証情報の漏えい
P1	主要機能の障害、ユーザーへの重大な影響	< 30 分	決済処理の失敗、リージョンでの認証障害
P2	パフォーマンスの低下、一部機能の喪失	< 4 時間	レイテンシの上昇、重要度の低い機能が利用不可
P3	軽微な問題、回避策あり	翌営業日	UI の不具合、レポート生成の遅延、見た目上のエラー

出力

• インシデントのタイムラインと重大度の分類
• 実施した封じ込め措置
• アクション項目を含むポストモーテム文書
• 更新済みのランブックとアラートルール

よくある間違い

• 重大度の分類を省略し、すべてを P0 として扱う
• ロールバック計画なしで変更を行う
• 関係者への状況連絡を忘れる
• システム上の問題の特定ではなく、個人を非難するポストモーテムを書く
• ポストモーテムのアクション項目をフォローアップしない