/incident-response

不慣れなプレースホルダーを見かけた場合、または接続されているツールを確認する必要がある場合は、CONNECTORS.md を参照してください。

検出からポストモーテムまでインシデントを管理します。

使用方法

/incident-response $ARGUMENTS

モード

/incident-response new [description]     # 新しいインシデントを開始
/incident-response update [status]       # ステータス更新を投稿
/incident-response postmortem            # インシデントデータからポストモーテムを生成

モードが指定されていない場合は、インシデントがどのフェーズにあるかを尋ねます。

動作方法

┌─────────────────────────────────────────────────────────────────┐
│                    インシデント対応                                   │
├─────────────────────────────────────────────────────────────────┤
│  フェーズ1: トリアージ                                              │
│  ✓ 重大度を評価 (SEV1-4)                                        │
│  ✓ 影響を受けるシステムとユーザーを特定                          │
│  ✓ ロールを割り当て (IC, comms, responders)                    │
│                                                                    │
│  フェーズ2: コミュニケーション                                        │
│  ✓ 内部ステータス更新案を作成                                    │
│  ✓ 顧客への連絡案を作成 (必要に応じて)                          │
│  ✓ ウォールームとケイデンスをセットアップ                        │
│                                                                    │
│  フェーズ3: 軽減                                                     │
│  ✓ 実施された軽減ステップを文書化                                │
│  ✓ イベントのタイムラインを追跡                                  │
│  ✓ 解決を確認                                                    │
│                                                                    │
│  フェーズ4: ポストモーテム                                             │
│  ✓ 非難のないポストモーテムドキュメント                          │
│  ✓ タイムラインの復元                                            │
│  ✓ 根本原因分析 (5 Why)                                         │
│  ✓ オーナー付きアクションアイテム                                │
└─────────────────────────────────────────────────────────────────┘

重大度分類

レベル	基準	対応時間
SEV1	サービス停止、全ユーザー影響	即座、全員対応
SEV2	主要機能の低下、多数のユーザー影響	15 分以内
SEV3	マイナー機能の問題、一部ユーザー影響	1 時間以内
SEV4	見た目の問題または低影響の問題	翌営業日

コミュニケーション指針

定期的なケイデンスで明確で事実に基づいた更新を提供します。含めるべき内容: 何が起きているか、誰が影響を受けているか、何をしているか、次の更新はいつか。

出力 — ステータス更新

## インシデント更新: [タイトル]
**重大度:** SEV[1-4] | **ステータス:** 調査中 | 特定済み | 監視中 | 解決
**影響:** [誰/何が影響を受けているか]
**最終更新:** [タイムスタンプ]

### 現在のステータス
[現在わかっていること]

### 実施されたアクション
- [アクション 1]
- [アクション 2]

### 次のステップ
- [次に何が起こるか、および予想時間]

### タイムライン
| 時刻 | イベント |
|------|---------|
| [HH:MM] | [イベント] |

出力 — ポストモーテム

## ポストモーテム: [インシデントタイトル]
**日付:** [日付] | **期間:** [X 時間] | **重大度:** SEV[X]
**作成者:** [名前] | **ステータス:** ドラフト

### 概要
[2-3 文の平易な言葉での概要]

### 影響
- [影響を受けたユーザー]
- [影響の期間]
- [定量化可能な場合はビジネスへの影響]

### タイムライン
| 時刻 (UTC) | イベント |
|------------|---------|
| [HH:MM] | [イベント] |

### 根本原因
[インシデントの原因についての詳細説明]

### 5 Why
1. [症状]がなぜ起きたか? → [理由...]
2. [原因 1]がなぜ起きたか? → [理由...]
3. [原因 2]がなぜ起きたか? → [理由...]
4. [原因 3]がなぜ起きたか? → [理由...]
5. [原因 4]がなぜ起きたか? → [根本原因]

### うまくいったこと
- [機能した事項]

### うまくいかなかったこと
- [機能しなかった事項]

### アクションアイテム
| アクション | オーナー | 優先度 | 完了予定日 |
|-----------|--------|--------|----------|
| [アクション] | [担当者] | P0/P1/P2 | [日付] |

### 教訓
[チームへの主要な取り組み]

コネクタが利用可能な場合

monitoring が接続されている場合:

• アラート詳細とメトリクスを取得
• 影響を受けたメトリクスのグラフを表示

incident management が接続されている場合:

• PagerDuty/Opsgenie でインシデントを作成または更新
• オンコール対応者をページング

chat が接続されている場合:

• インシデントチャネルにステータス更新を投稿
• ウォールームチャネルを作成

ヒント

1. 即座に書き始める — 完全な情報を待たないでください。学習するにつれて更新します。
2. 更新は事実に基づいたものに — わかっていること、実施したこと、次に何をするか。推測は含めません。
3. ポストモーテムは非難がない — 個人ではなくシステムとプロセスに焦点を当てます。