mcpField
I
incident-response-engineer

incident-response-engineer

github.com/wyattowalshクラウド・DevOps537 回インストール8 週間前に更新
リポジトリ

incident-response-engineer について

incident-response-engineerは、ライブ障害やサービス低下のトリアージから復旧、事後検証までを調整するスキルです。対応、連絡、レビュー、訓練を個別のモードで扱います。

主な機能

  1. 01インシデントのトリアージと重大度評価
  2. 02影響封じ込めと復旧の調整
  3. 03関係者向け状況報告の作成
  4. 04タイムラインと事後検証の計画
  5. 05対応レビューと訓練

活用シーン

  1. 01稼働中の障害で対応者を調整
  2. 02顧客や関係者への定期報告を作成
  3. 03インシデント後の担当付き改善策を作成
  4. 04リージョン障害への対応を訓練

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wyattowalsh/agents --skill incident-response-engineer

インストール後、Claude Code で/incident-response-engineerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
references/
comms-templates.md
containment-recovery-aids.md
severity-matrix.md
timeline-postmortem-examples.md
scripts/
check.py
scripts/asset_toolkit/
__init__.py
_shared.py
common.py
package.py
validate_evals.py
validate_hooks.py
validate_skill.py

詳細

インシデント対応エンジニア

最初のシグナルから復旧、ポストモーテムまで、本番環境のインシデント対応を調整します。

対象範囲: 稼働中の運用インシデントとサービスの劣化です。一般的なコードレビュー(review)、予防的な脆弱性スキャン(security-scanner)、またはインシデント対応の調整を伴わない単発のバグ修正は対象外です。

標準用語

用語定義
severityビジネスへの影響に基づくインシデントの優先度
impactユーザーに見える被害、収益の損失、または運用の劣化
blast radius影響を受けるシステム、リージョン、テナント、またはユーザー
containmentインシデントの拡大を食い止める短期的な対応
mitigation根本原因を完全に修正する前に影響を軽減する対応
recoveryサービスを許容される動作状態に戻すこと
incident commander意思決定とタイムラインを一元的に調整する担当者
stakeholder update社内または社外の関係者に向けた、時間を区切って発信する状況報告
timeline事実、決定、対応を時系列で記録したもの
action item担当者と期限が明確な具体的なフォローアップ項目

ディスパッチ

$ARGUMENTSモード
triage <signal>インシデントを分類し、最初の対応計画を立てます
stabilize <incident>影響を封じ込め、軽減策を調整します
comms <incident>社内向けまたは顧客向けの報告を作成します
postmortem <incident>インシデントレビューと是正措置をまとめます
review <timeline or runbook>インシデント対応を監査します
drill <scenario>机上演習またはリハーサル計画を実施します
稼働中の障害に関する自然言語の入力最も近いモードを自動検出します
空例を含むモードメニューを表示します

モードメニュー

#モード例
1トリアージtriage elevated 500s in eu-west checkout
2安定化stabilize auth outage caused by bad deploy
3コミュニケーションcomms database failover affecting signups
4ポストモーテムpostmortem queue backlog incident
5レビューreview incident timeline from 2026-03-12
6演習drill primary region outage

使用する場面

  • サービスが停止または劣化している、あるいは SLO に違反している場合
  • 複数の対応者が共通のインシデント対応体制を必要としている場合
  • 関係者または顧客への報告を定期的に発信する必要がある場合
  • 修正方法は判明しているものの、封じ込めと復旧の間にリスク管理が必要な場合
  • チームがポストモーテムまたは机上演習を必要としている場合

分類ゲート

  • 運用上の影響を伴わない通常のデバッグや単発のバグの場合は、investigate を使用してください。
  • 予防的な脆弱性の発見、脅威モデリング、またはセキュリティスキャンの場合は、security-scanner を使用してください。
  • コードレビュー、修正品質の評価、またはマージ前のリスクレビューの場合は、review を使用してください。
  • 稼働中のインシデントとは無関係なテレメトリ設計、アラートアーキテクチャ、または SLO の定義の場合は、observability-advisor を使用してください。
  • 特定ベンダー向けのダッシュボード、アラーム、またはログプラットフォームの設定の場合は、incident-response-engineer ではなく、該当するプラットフォームスキルに振り分けてください。

手順

モード:トリアージ
  1. 検証済みの事実のみから始めます。症状、影響を受けたシステム、影響を受けたユーザー、検知元を確認します。
  2. 直感ではなく、影響と影響範囲に基づいて深刻度を見積もります。references/severity-matrix.md を使用してください。
  3. インシデントコマンダーを指名し、次の意思決定チェックポイントを定めます。
  4. 封じ込めの選択肢、最も安全な即時の軽減策、現在の仮説を裏付ける、または棄却する証拠を特定します。
  5. 最初の15分間の対応計画を作成します。
モード:安定化
  1. 封じ込めと根本原因への対応を分けます。
  2. ロールバック、トラフィックの切り替え、フィーチャーフラグ、依存関係の隔離、フェイルオーバーなど、ユーザーへの被害を最も速く軽減できる対応を優先します。references/containment-recovery-aids.md を使用してください。
  3. 意味のある対応ごとに、タイムスタンプ、担当者、結果を記載した最新のタイムラインを維持します。
  4. 影響範囲が変化するたびに、重大度を再評価します。
  5. 「封じ込め済み」「一部復旧」「完全復旧」の3つの状態を明示的に追跡します。
モード:コミュニケーション
  1. 対象者を特定します。対応担当者、経営幹部、サポート、顧客のいずれかです。
  2. 判明していること、ユーザーが目にする可能性のある状況、チームが行っていること、次回の更新時刻を伝えます。
  3. 根本原因について、推測に基づく主張は避けます。
  4. 顧客への更新は簡潔で分かりやすい表現にします。references/comms-templates.md を使用してください。
モード:ポストモーテム
  1. 記憶だけに頼らず、検証済みの事象からタイムラインを作成します。references/timeline-postmortem-examples.md を使用してください。
  2. トリガー、寄与要因、防御の失敗、復旧対応、教訓を区別します。
  3. 教訓を、担当者、期限、測定可能な成果を含むアクション項目に変換します。
  4. 責任追及ではなく、システムの改善に焦点を当てます。
モード:レビュー
  1. タイムライン、更新内容、ランブック、フォローアップ対応を確認します。references/severity-matrix.md、references/comms-templates.md、references/timeline-postmortem-examples.md と照らし合わせます。
  2. 検知、トリアージの速度、指揮体制、コミュニケーションの質、復旧戦略、アクション項目の質を評価します。
  3. ギャップを重大、警告、情報に分類して提示します。
モード:訓練
  1. シナリオ、目的、停止条件を定義します。
  2. references/severity-matrix.md、references/comms-templates.md、references/containment-recovery-aids.md を使用して、検知、役割分担、エスカレーション、ロールバック、顧客への連絡をシミュレーションします。
  3. 意思決定のボトルネックと、ランブックに不足している手順を記録します。

出力要件

  • トリアージと安定化の出力には、重大度、影響範囲、指揮担当者、次の確認時刻、直ちに実施する対応を含めてください。
  • コミュニケーションの出力には、対象者と次回の更新時刻を含めてください。
  • ポストモーテムには、担当者を明記したアクション項目を含めてください。

重要なルール

  1. 事実、推論、仮説を常に区別します。
  2. 洗練された原因分析より、顧客への影響を優先します。
  3. 根拠が裏付ける前に、根本原因を公に断定してはいけません。
  4. 進行中のインシデントには、必ず単一のインシデント指揮担当者を置きます。
  5. 対応中の意味のある行動は、すべてタイムラインに記録します。
  6. ポストモーテムでは、曖昧な教訓ではなく、担当者が割り当てられた是正措置を必ず作成します。

スケーリング戦略

  • 単一サービスのインシデントでは、指揮担当者1人、タイムライン1つ、対応チャネル1つ、短い更新間隔を維持します。
  • チーム横断のインシデントでは、単一の指揮担当者と唯一の正確なタイムラインを維持しながら、封じ込め、原因分析、コミュニケーションを明確な作業領域に分けます。
  • 重大インシデントでは、更新間隔を定め、顧客への連絡の担当者を割り当て、場当たり的な調整によって連携が分断される前に、経営幹部への共有をエスカレーションする基準を定義します。

参考ファイル

現在のモードで、より詳細な構成や再利用可能なテンプレートが必要な場合にのみ使用してください。

ファイル目的使用する場面
references/severity-matrix.md影響、影響範囲、対応方針に基づく重大度の評価トリアージ、安定化、訓練、レビュー
references/comms-templates.md内部、経営幹部、サポート、顧客向けの更新テンプレートと更新間隔のガイダンスコミュニケーション、安定化、訓練、レビュー
references/timeline-postmortem-examples.mdタイムラインの構成、ポストモーテムのセクション例、アクション項目のパターンポストモーテム、レビュー
references/containment-recovery-aids.mdロールバック、フェイルオーバー、依存関係の隔離、縮退モード、復旧確認のための判断補助資料トリアージ、安定化、訓練

対象範囲

対象: 障害発生時のリアルタイムな連携、緩和策の策定、関係者への状況報告、事後分析、インシデント訓練。

対象外: 脆弱性の発見、コードレビュー、運用への影響を伴わない日常的なデバッグ。

コメント