incident-response-incident-response

このスキルを使う場面

• インシデント対応のタスクやワークフローに取り組む場合
• インシデント対応に関するガイダンス、ベストプラクティス、チェックリストが必要な場合

このスキルを使わない場面

• タスクがインシデント対応に関係しない場合
• 対象範囲外の別のドメインやツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、結果を検証します。
• 実行可能な手順と検証方法を提示します。

最新の SRE プラクティスに基づき、複数のエージェントでインシデント対応をオーケストレーションし、迅速な解決と学びにつなげます。

[Extended thinking: このワークフローは、最新の SRE 原則に従った包括的なインシデントコマンドシステム（ICS）を実装します。複数の専門エージェントが、検知／トリアージ、調査／緩和、コミュニケーション／調整、解決／事後分析という明確に定義されたフェーズを通じて連携します。このワークフローでは、正確性を損なうことなく迅速に対応し、明確なコミュニケーションチャネルを維持するとともに、責任を問わない事後分析と体系的な改善を通じて、すべてのインシデントを学びの機会にします。]

設定

既存のインシデントコマンダー、重大度ポリシー、許可されたサービス、変更権限に対応付けます。以下の Task／サブエージェント名はホスト固有の例であり、ツールがインストールされているとは限りません。ユーザーまたはプロジェクトの許可がある場合にのみ委任し、それ以外の場合は各役割を順番に実行します。ステータス報告や連絡用の成果物はまず下書きし、明示的に与えられたコミュニケーション権限の範囲内でのみ送信／公開します。可能な場合は緩和策を実施する前に証拠を保全し、タイムスタンプと不確実性を記録します。本番環境への書き込みには、承認済みのロールバック基準を必須とします。緊急であっても、デプロイやデータ削除の権限が与えられるわけではありません。

重大度レベル

• P0/SEV-1：全面的な停止、セキュリティ侵害、データ損失 — 直ちに全員で対応
• P1/SEV-2：大幅な性能低下、ユーザーへの重大な影響 — 迅速な対応が必要
• P2/SEV-3：軽微な性能低下、影響が限定的 — 通常の対応
• P3/SEV-4：軽微な問題、ユーザーへの影響なし — 計画的に解決

インシデントの種類

• パフォーマンスの低下
• サービス停止
• セキュリティインシデント
• データ整合性の問題
• インフラストラクチャの障害
• サードパーティサービスの中断

フェーズ 1：検知とトリアージ

1. インシデントの検知と分類

• subagent_type="incident-responder" を指定して Task ツールを使用します
• プロンプト：「緊急：インシデントを検知して分類してください：$ARGUMENTS。PagerDuty/Opsgenie/監視システムのアラートを分析します。次の項目を特定してください：1) インシデントの重大度（P0～P3）、2) 影響を受けるサービスと依存関係、3) ユーザーへの影響とビジネスリスク、4) 必要な初期インシデントコマンド体制。エラーバジェットと SLO 違反を確認してください。」
• 出力：重大度の分類、影響評価、インシデントコマンドの担当割り当て、SLO の状況
• コンテキスト：初期アラート、監視ダッシュボード、最近の変更

2. 可観測性の分析

• subagent_type="observability-monitoring::observability-engineer" を指定して Task ツールを使用します
• プロンプト：「インシデントについて可観測性を迅速に調査してください：$ARGUMENTS。次を確認してください：1) 分散トレース（OpenTelemetry/Jaeger）、2) メトリクスの相関（Prometheus/Grafana/DataDog）、3) ログ集約（ELK/Splunk）、4) APM データ、5) リアルユーザーモニタリング。異常、エラーパターン、サービスの性能低下箇所を特定してください。」
• 出力：可観測性の調査結果、異常の検知、サービス健全性マトリクス、トレース分析
• コンテキスト：手順 1 の重大度、影響を受けるサービス

3. 初期緩和策

• subagent_type="incident-responder" を指定して Task ツールを使用します
• プロンプト：「重大度 P$SEVERITY のインシデントに対し、直ちに緩和策を実施してください：$ARGUMENTS。対応：1) 必要に応じたトラフィックのスロットリング／迂回、2) 影響を受ける機能のフィーチャーフラグの無効化、3) サーキットブレーカーの有効化、4) 最近のデプロイのロールバック評価、5) 容量が原因の場合はリソースをスケールします。ユーザー体験の回復を優先してください。」
• 出力：実施した緩和策、一時的な修正、ロールバックの判断
• コンテキスト：可観測性の調査結果、重大度の分類

フェーズ 2：調査と根本原因分析

4. システムの詳細なデバッグ

• subagent_type="error-debugging::debugger" を指定して Task ツールを使用します
• プロンプト：「オブザーバビリティデータを使用して、インシデント $ARGUMENTS を詳細にデバッグしてください。以下を調査します：1）スタックトレースとエラーログ、2）データベースのクエリパフォーマンスとロック、3）ネットワークレイテンシとタイムアウト、4）メモリリークと CPU スパイク、5）依存関係の障害と連鎖的なエラー。なぜなぜ分析を実施してください。」
• 出力：根本原因の特定、寄与要因、依存関係への影響マップ
• コンテキスト：オブザーバビリティ分析、緩和策の状況

5. セキュリティ評価

• subagent_type="security-scanning::security-auditor" を指定して Task ツールを使用します
• プロンプト：「インシデント $ARGUMENTS のセキュリティ上の影響を評価してください。以下を確認します：1）DDoS 攻撃の兆候、2）認証／認可の失敗、3）データ漏えいのリスク、4）証明書の問題、5）不審なアクセスパターン。WAF ログ、セキュリティグループ、監査証跡を確認してください。」
• 出力：セキュリティ評価、侵害分析、脆弱性の特定
• コンテキスト：根本原因の調査結果、システムログ

6. パフォーマンスエンジニアリング分析

• subagent_type="application-performance::performance-engineer" を指定して Task ツールを使用します
• プロンプト：「インシデント $ARGUMENTS のパフォーマンス面を分析してください。以下を調査します：1）リソース使用率のパターン、2）クエリ最適化の機会、3）キャッシュの有効性、4）ロードバランサーの健全性、5）CDN のパフォーマンス、6）オートスケーリングのトリガー。ボトルネックと容量の問題を特定してください。」
• 出力：パフォーマンスのボトルネック、リソースに関する推奨事項、最適化の機会
• コンテキスト：デバッグの調査結果、現在の緩和策の状況

フェーズ 3：解決と復旧

7. 修正の実装

• subagent_type="backend-development::backend-architect" を指定して Task ツールを使用します
• プロンプト：「根本原因に基づき、インシデント $ARGUMENTS に対する本番環境向けの修正を設計し、実装してください。要件：1）迅速なデプロイに向けた最小限の実用的な修正、2）リスク評価とロールバック機能、3）モニタリングを伴う段階的なロールアウト計画、4）検証基準とヘルスチェック。緊急の修正と長期的な解決策の両方を検討してください。」
• 出力：修正の実装、デプロイ戦略、検証計画、ロールバック手順
• コンテキスト：根本原因分析、パフォーマンスの調査結果、セキュリティ評価

8. デプロイと検証

• subagent_type="deployment-strategies::deployment-engineer" を指定して Task ツールを使用します
• プロンプト：「インシデント修正の緊急デプロイを実行してください：$ARGUMENTS。手順：1）ブルーグリーンまたはカナリアデプロイ、2）モニタリングを伴う段階的なロールアウト、3）各段階でのヘルスチェック検証、4）ロールバックのトリガーを設定、5）デプロイ中のリアルタイムモニタリング。インシデント指揮チームと連携してください。」
• 出力：デプロイ状況、検証結果、モニタリングダッシュボード、ロールバックの準備状況
• コンテキスト：修正の実装、現在のシステム状態

フェーズ 4：コミュニケーションと調整

9. ステークホルダーとのコミュニケーション

• subagent_type="content-marketing::content-marketer" を指定して Task ツールを使用します
• プロンプト：「インシデント $ARGUMENTS に関するコミュニケーションを管理してください。以下を作成します：1）ステータスページの更新（一般公開向け）、2）社内向けエンジニアリング情報（技術的な詳細）、3）エグゼクティブサマリー（ビジネスへの影響／復旧予定時刻）、4）カスタマーサポート向けブリーフィング（説明の要点）、5）重要な決定事項を含むタイムライン文書。重大度に応じて 15〜30 分ごとに更新してください。」
• 出力：コミュニケーション資料、ステータス更新、ステークホルダー向けブリーフィング、タイムライン記録
• コンテキスト：これまでの全フェーズ、現在の解決状況

10. 顧客への影響評価

• subagent_type="incident-responder" を指定して Task ツールを使用します
• プロンプト：「インシデント $ARGUMENTS による顧客への影響を評価し、文書化してください。以下を分析します：1）影響を受けたユーザーセグメントと地域、2）失敗したトランザクションまたはデータ損失、3）SLA 違反と契約上の影響、4）カスタマーサポートのチケット件数、5）収益への影響の推定。顧客への先回りした連絡先リストを作成してください。」
• 出力：顧客影響レポート、SLA 分析、連絡に関する推奨事項
• コンテキスト：解決の進捗状況、コミュニケーション状況

フェーズ 5：事後検証と再発防止

11. 非難しない事後検証

• subagent_type="documentation-generation::docs-architect" を指定して Task ツールを使用します
• プロンプト：「インシデント $ARGUMENTS の非難しない事後検証を実施します。以下を記録してください：1）判断を含むインシデントの完全なタイムライン、2）根本原因と寄与要因（システムに焦点を当てる）、3）対応でうまくいったこと、4）改善できること、5）担当者と期限を含むアクションアイテム、6）チーム教育のための教訓。SRE の事後検証に関するベストプラクティスに従ってください。」
• 出力：事後検証ドキュメント、アクションアイテム一覧、プロセスの改善点、トレーニングの必要性
• コンテキスト：インシデントの完全な履歴、すべてのエージェントの出力

12. 監視とアラートの強化

• subagent_type="observability-monitoring::observability-engineer" を指定して Task ツールを使用します
• プロンプト：「$ARGUMENTS の再発を防止するために監視を強化します。以下を実施してください：1）早期検知のための新しいアラート、2）必要に応じた SLI/SLO の調整、3）可視性を高めるダッシュボードの改善、4）ランブックの自動化の機会、5）テスト用のカオスエンジニアリングのシナリオ。アラートが実行可能で、ノイズを減らせるようにしてください。」
• 出力：新しい監視設定、アラートルール、ダッシュボードの更新、ランブックの自動化
• コンテキスト：事後検証の結果、根本原因の分析

13. システムの堅牢化

• subagent_type="backend-development::backend-architect" を指定して Task ツールを使用します
• プロンプト：「インシデント $ARGUMENTS を防止するためのシステム改善を設計します。以下を提案してください：1）回復力を高めるアーキテクチャの変更（サーキットブレーカー、バルクヘッド）、2）グレースフルデグラデーションの戦略、3）キャパシティプランニングの調整、4）技術的負債の優先順位付け、5）依存関係を減らす機会。実装ロードマップを作成してください。」
• 出力：アーキテクチャの改善、回復力を高めるパターン、技術的負債の項目、ロードマップ
• コンテキスト：事後検証のアクションアイテム、パフォーマンス分析

成功基準

直近の成功（インシデント発生中）

• SLA の目標時間内にサービスを復旧する
• 5 分以内に重大度を正確に分類する
• 15～30 分ごとにステークホルダーへ連絡する
• 連鎖障害やインシデントのエスカレーションを発生させない
• 明確なインシデント指揮体制を維持する

長期的な成功（インシデント後）

• 48 時間以内に包括的な事後検証を行う
• すべてのアクションアイテムに担当者と期限を設定する
• 1 週間以内に監視の改善をデプロイする
• ランブックの更新を完了する
• 学んだ教訓についてチーム研修を実施する
• エラーバジェットへの影響を評価し、共有する

連携プロトコル

インシデント指揮体制

• インシデントコマンダー：意思決定権限、調整
• テクニカルリード：技術調査と解決
• コミュニケーションリード：ステークホルダーへの連絡
• 分野の専門家：特定システムに関する専門知識

コミュニケーションチャネル

• ウォールーム（Slack/Teams チャネルまたは Zoom）
• ステータスページの更新（StatusPage、Statusly）
• アラートには PagerDuty/Opsgenie
• ドキュメントには Confluence/Notion

引き継ぎ要件

• 各フェーズで次のフェーズに明確なコンテキストを引き継ぐ
• すべての調査結果を共有インシデントドキュメントに記録する
• 事後検証のため、判断の根拠を記録する
• 重要なイベントにはすべてタイムスタンプを付ける

即時対応が必要な本番インシデント：$ARGUMENTS

例

ユーザーの依頼：

このタスクには @incident-response-incident-response を使用してください：インシデント対応に取り組む際に使用します。

制限事項

• タスクが上記の説明された範囲に明確に一致する場合にのみ、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、成功基準が不足している場合は、作業を中止して確認を求めてください。