managing-incidents

インシデント管理

検知、対応、コミュニケーション、学習を網羅した、エンドツーエンドのインシデント管理ガイダンスを提供します。SRE の文化、非難しないポストモーテム、信頼性の高い運用を実現するための体系的なプロセスを重視します。

このスキルを使用する場面

次の場合にこのスキルを適用してください。

• チームのインシデント対応プロセスを構築するとき
• オンコールのローテーションとエスカレーションポリシーを設計するとき
• よくある障害シナリオのランブックを作成するとき
• インシデント後に非難しないポストモーテムを実施するとき
• インシデントのコミュニケーションプロトコル（社内外）を導入するとき
• インシデント管理ツールやプラットフォームを選定するとき
• MTTR とインシデント発生頻度の指標を改善するとき

基本原則

インシデント管理の理念

早めに、そして頻繁に宣言する： 確信が持てるまで待たないでください。インシデントを宣言することで連携が可能になり、必要に応じて重要度を下げられるほか、対応の遅れを防げます。

根本原因の究明より先に緩和する： 直ちに顧客への影響を止めます（ロールバック、機能の無効化、フェイルオーバー）。安定性を回復した後に、デバッグと根本原因の修正を行います。

非難しない文化： 善意を前提とします。誰が失敗したかではなく、システムがどのように機能しなかったかに注目します。率直に学べる心理的安全性を築きます。

明確な指揮系統： 調整の責任者としてインシデントコマンダー（IC）を任命します。IC はタスクを委任しますが、実際のデバッグ作業は行いません。

コミュニケーションは不可欠： 専用チャンネルで社内の調整を行い、ステータスページで社外に透明性を保ちます。重大なインシデントでは、15～30 分ごとに関係者へ最新情報を共有します。

重大度の分類

標準的な重大度レベルと対応時間は次のとおりです。

SEV0（P0）- 重大な停止：

• 影響：サービスの完全停止、重大なデータ損失、決済処理の停止
• 対応：24 時間 365 日、直ちにページ通知を行い、全員で対応し、経営陣に通知します
• 例：API が完全に停止し、すべての顧客に影響

SEV1（P1）- 大幅な機能低下：

• 影響：主要な機能が低下し、顧客の相当数に影響
• 対応：営業時間内にページ通知し、時間外はエスカレーションして、IC を任命します
• 例：エラー率が 15％、重要な機能が利用不可

SEV2（P2）- 軽微な問題：

• 影響：軽微な機能障害、エッジケースのバグ、少数のユーザーに影響
• 対応：メール／Slack で通知し、翌営業日に対応します
• 例：UI の表示崩れ、重要ではない機能の動作が遅い

SEV3（P3）- 影響が小さい問題：

• 影響：外観上の問題で、顧客向け機能への影響はありません
• 対応：チケットキューに登録し、計画済みのスプリントで対応します
• 例：表示の不整合、ドキュメントの誤り

重大度の詳細な判断フレームワークと対話型の分類ツールについては、references/severity-classification.md を参照してください。

インシデント対応の役割

インシデントコマンダー（IC）：

• インシデント対応全体と調整を統括します
• 戦略的な判断（ロールバックかデバッグか、いつエスカレーションするか）を行います
• 対応者にタスクを委任します（実際のデバッグ作業は行いません）
• 安定性が確認された時点で、インシデントの解決を宣言します

コミュニケーションリード：

• 社内外のチャンネルに状況を投稿します
• 関係者（経営陣、プロダクト、サポート）との連携を調整します
• インシデント後に顧客へ伝える内容を作成します
• 更新頻度：SEV0／SEV1 では 15～30 分ごと

専門分野のエキスパート（SME）：

• 実際にデバッグと緩和を行います
• ランブックを実行し、修正を実装します
• IC に技術的な背景情報を提供します

書記：

• タイムライン、実施した対応、決定事項をリアルタイムで記録します
• ポストモーテムでの再構成に備えて、インシデントのメモを記録します

重大度に応じて役割を割り当てます。

• SEV2／SEV3：対応者 1 名
• SEV1：IC ＋ SME（複数可）
• SEV0：IC ＋ コミュニケーションリード ＋ SME（複数可）＋ 書記

役割の詳細な責務については、references/incident-roles.md を参照してください。

オンコール管理

ローテーションのパターン

プライマリ＋セカンダリ：

• プライマリ：最初の対応者
• セカンダリ：プライマリが5分以内に応答しない場合のバックアップ
• ローテーション期間：1週間（最適なバランス）

フォロー・ザ・サン（24時間365日）：

• チームA：米国時間、チームB：ヨーロッパ時間、チームC：アジア時間
• メリット：夜勤がなく、ワークライフバランスが向上します
• 必要条件：複数のグローバルチーム

段階的エスカレーション：

• ティア1：ジュニアのオンコール担当者（一般的な問題、ランブックに基づいて対応）
• ティア2：シニアのオンコール担当者（複雑なトラブルシューティング）
• ティア3：チームリーダー／アーキテクト（重大な判断）

ベストプラクティス

• ローテーション期間：1回につき1週間
• 引き継ぎの場：進行中の問題について話し合う30分間の通話
• 報酬：オンコール手当＋重大インシデント後の休暇
• ツール：PagerDuty、Opsgenie、またはincident.io
• 上限：1晩あたり最大2～3件のページ。超過した場合はエスカレーションします

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

標準的なインシデントのライフサイクル：

Detection → Triage → Declaration → Investigation
  ↓
Mitigation → Resolution → Monitoring → Closure
  ↓
Post-Mortem (within 48 hours)

主な判断ポイント

宣言するタイミング： 判断に迷ったら宣言します（重大度はいつでも引き下げられます）

エスカレーションするタイミング：

• 30分経っても進展がない
• 重大度が上がった（SEV2 → SEV1）
• 専門的な知識が必要

終了するタイミング：

• 問題が解決し、30分以上安定している
• 監視結果で、すべてのメトリクスがベースラインに戻っている
• 顧客から報告された問題がない

ワークフローの詳細については、references/incident-workflow.mdを参照してください。

コミュニケーションプロトコル

内部コミュニケーション

インシデント用Slackチャンネル：

• 形式：#incident-YYYY-MM-DD-topic-description
• ピン留め：重大度、ICの名前、ステータス更新テンプレート、ランブックのリンク

ウォールーム： リアルタイムの音声連携が必要なSEV0／SEV1向けのビデオ通話

ステータス更新の頻度：

• SEV0：15分ごと
• SEV1：30分ごと
• SEV2：1～2時間ごと、または主要なマイルストーン到達時

外部コミュニケーション

ステータスページ：

• ツール：Statuspage.io、Instatus、カスタム
• 段階：調査中 → 特定済み → 監視中 → 解決済み
• 透明性：問題を公に認め、可能な場合は復旧予定時刻を提示します

顧客向けメール：

• 対象：顧客に影響するSEV0／SEV1
• タイミング：1時間以内（受領確認）、解決後（詳細全体）
• トーン：謝罪を示し、透明性を保ち、行動を重視します

規制当局への通知：

• データ侵害：GDPRでは72時間以内の通知が必要です
• 金融サービス：規制当局への即時通知
• 医療：HIPAAの侵害通知ルール

コミュニケーション用テンプレートについては、examples/communication-templates.mdを参照してください。

ランブックとプレイブック

ランブックの構成

すべてのランブックには、次の項目を含める必要があります。

1. トリガー： このランブックを起動するアラート条件
2. 重大度： 想定される重大度レベル
3. 前提条件： 必要なシステム状態
4. 手順： 番号付きの実行可能なコマンド（コピー＆ペースト可能）
5. 確認： 修正が機能したことを確認する方法
6. ロールバック： 手順が失敗した場合に元に戻す方法
7. 担当者： 責任を負うチーム／担当者
8. 最終更新日： 最後に改訂した日付

ベストプラクティス

• 実行可能： 説明だけでなく、コマンドをコピー＆ペースト可能にします
• テスト済み： 災害復旧訓練で実行します
• バージョン管理： Gitで変更を追跡します
• リンク： アラート定義から参照します
• 自動化： 手作業の手順を、時間をかけてスクリプトに置き換えます

ランブックのテンプレートについては、examples/runbooks/ディレクトリを参照してください。

非難しないポストモーテム

非難しない文化の原則

善意を前提とする： 誰もが、入手可能な情報に基づいて最善の判断をしました。

システムに焦点を当てる： 誰が失敗したかではなく、プロセスがどのように機能しなかったかを調査します。

心理的安全性： 正直さが評価される環境を作ります。

学習の機会： インシデントは、組織の知識を得る機会です。

事後レビューのプロセス

1. レビューの予定を設定（48 時間以内）： 記憶が新しいうちに行います

2. 事前準備： タイムラインを再構成し、メトリクス／ログを収集して、ドキュメントの草案を作成します

3. ミーティングの進行：

• タイムラインを確認します
• 5 Whys 分析でシステム上の根本原因を特定します
• 良かった点／問題だった点を確認します
• 担当者と期限を決めてアクションアイテムを定義します

4. 事後レビューのドキュメント：

• セクション：概要、タイムライン、根本原因、影響、良かった点／問題だった点、アクションアイテム
• 配布先：エンジニアリング、プロダクト、サポート、リーダーシップ
• 保管場所：検索可能なナレッジベースにアーカイブします

5. フォローアップ： スプリント計画でアクションアイテムを追跡します

詳細な進行ガイドとテンプレートについては、references/blameless-postmortems.md と examples/postmortem-template.md を参照してください。

アラート設計の原則

対応が必要なアラートのみ：

• すべてのアラートに人による対応が必要です
• グラフ、ランブックへのリンク、最近の変更を含めます
• 関連するアラートを重複排除します
• サービスの担当状況に基づいて、適切なチームに通知します

アラート疲れの防止：

• 四半期ごとにアラートを監査し、対応不要なアラートを削除します
• ノイズの多いメトリクスのしきい値を上げます
• 固定しきい値の代わりに異常検知を使用します
• 上限：夜間のページ通知は最大 2～3 件

ツールの選定

インシデント管理プラットフォーム

PagerDuty：

• 最適な用途：確立された大企業、複雑なエスカレーションポリシー
• 費用：1 ユーザーあたり月額 $19～41
• 適用条件：チーム規模が 10 人以上、予算が月額 $500 以上

Opsgenie：

• 最適な用途：Atlassian エコシステムのユーザー、柔軟なルーティング
• 費用：1 ユーザーあたり月額 $9～29
• 適用条件：Atlassian 製品を使用している、予算が月額 $200～500

incident.io：

• 最適な用途：モダンなチーム、AI を活用した対応、Slack ネイティブ
• 適用条件：チーム規模が 5～50 人、Slack 中心の文化

詳細なツール比較については、references/tool-comparison.md を参照してください。

ステータスページソリューション

Statuspage.io： 最も信頼性が高く、セットアップが簡単です（月額 $29～399） Instatus： 手頃な価格で、モダンなデザインです（月額 $19～99）

メトリクスと継続的改善

主要なインシデントメトリクス

MTTA（平均確認時間）：

• 目標：SEV1 では 5 分未満
• 改善策：オンコール体制の強化

MTTR（平均復旧時間）：

• 目標：SEV1 では 1 時間未満
• 改善策：ランブック、自動化

MTBF（平均故障間隔）：

• 目標：重要なサービスでは 30 日超
• 改善策：根本原因の修正

インシデント発生頻度：

• 追跡対象：月ごとの SEV0、SEV1、SEV2 の件数
• 目標：減少傾向

アクションアイテム完了率：

• 目標：90% 超
• 改善策：スプリントへの組み込み、担当の明確化

継続的改善のサイクル

Incident → Post-Mortem → Action Items → Prevention
   ↑                                          ↓
   └──────────── Fewer Incidents ─────────────┘

意思決定フレームワーク

重大度分類の判断ツリー

Is production completely down or critical data at risk?
├─ YES → SEV0
└─ NO  → Is major functionality degraded?
          ├─ YES → Is there a workaround?
          │        ├─ YES → SEV1
          │        └─ NO  → SEV0
          └─ NO  → Are customers impacted?
                   ├─ YES → SEV2
                   └─ NO  → SEV3

対話型分類ツールを使用します：python scripts/classify-severity.py

エスカレーションマトリックス

詳細なエスカレーションガイダンスについては、references/escalation-matrix.md を参照してください。

緩和策と根本原因

緩和策を優先する場合：

• 顧客への影響が継続している
• 迅速な修正が可能（ロールバック、機能の無効化）

根本原因への対応を優先する場合：

• 顧客への影響がすでに緩和されている
• 修正に慎重な分析が必要

原則： まず緩和策を実施します（99% のケース）

避けるべきアンチパターン

• 宣言の遅れ： インシデントを宣言する前に確証を待つ
• 事後レビューの省略： 「小規模な」インシデントからも学びを得られます
• 非難する文化： 個人を罰すると、システム上の学びが妨げられます
• アクションアイテムの放置： フォローアップのない事後レビューは時間の無駄です
• 明確な IC がいない： 複数人が指揮を執ると混乱が生じます
• アラート疲れ： ノイズが多く対応不要なアラートによって、オンコール担当者がページ通知を無視するようになります
• IC 自らが手を動かす： IC はデバッグを委任すべきであり、自ら行うべきではありません

導入チェックリスト

フェーズ 1：基盤（第 1 週）

• 重大度レベル（SEV0～SEV3）を定義する
• インシデント管理プラットフォームを選ぶ
• 基本的なオンコールローテーションを設定する
• インシデント用 Slack チャンネルのテンプレートを作成する

フェーズ 2：プロセス（第 2～3 週）

• よくあるインシデント向けの最初の 5 つのランブックを作成する
• ステータスページを設定する
• インシデント対応についてチームをトレーニングする
• 机上演習を実施する

フェーズ 3：文化（4 週目以降）

• 非難のない事後分析を初めて実施する
• 事後分析の定期的な実施体制を確立する
• MTTA／MTTR ダッシュボードを実装する
• スプリント計画でアクション項目を追跡する

フェーズ 4：最適化（3～6 か月目）

• インシデント宣言を自動化する
• ランブックの自動化を実装する
• 毎月、災害復旧訓練を実施する
• 四半期ごとにインシデントの傾向を確認する

他のスキルとの連携

オブザーバビリティ： 監視アラートがインシデントを発生させます → 対応には incident-management を使用します

災害復旧： DR は復旧手順を提供します → Incident-management は運用上の対応を提供します

セキュリティインシデント対応： コンプライアンス／フォレンジックの要素が加わる以外は、同様のプロセスです

Infrastructure-as-Code： IaC により、自動再構築を通じて迅速な復旧が可能になります

パフォーマンスエンジニアリング： パフォーマンスインシデントが対応を開始させます → 影響緩和後にパフォーマンスチームが調査します

例とテンプレート

ランブックテンプレート：

• examples/runbooks/database-failover.md
• examples/runbooks/cache-invalidation.md
• examples/runbooks/ddos-mitigation.md

事後分析テンプレート：

• examples/postmortem-template.md - 非難のない事後分析の完全な構成

コミュニケーションテンプレート：

• examples/communication-templates.md - 状況更新、顧客向けメール

オンコールの引き継ぎ：

• examples/oncall-handoff-template.md - 週次引き継ぎの形式

連携スクリプト：

• examples/integrations/pagerduty-slack.py
• examples/integrations/statuspage-auto-update.py
• examples/integrations/postmortem-generator.py

スクリプト

対話型重大度分類ツール：

python scripts/classify-severity.py

影響度と緊急度に基づいて適切な重大度を判断するための質問をします。

さらに読む

書籍：

• Google SRE Book：「Postmortem Culture」（第 15 章）
• Gene Kim 著「The Phoenix Project」
• 「Site Reliability Engineering」（全編）

オンラインリソース：

• Atlassian：「非難のない事後分析の実施方法」
• PagerDuty：「インシデント対応ガイド」
• Google SRE：「Postmortem Culture: Learning from Failure」

標準：

• Incident Command System（ICS）- 技術分野向けに適用された FEMA 標準
• ITIL Incident Management - 従来型の IT サービス管理