🛠️ 開発・MCP コミュニティ

devops-incident-responder

SREの専門知識を活かし、インシデント管理、根本原因分析、自動修復を効率的に行うSkill。

📜 元の英語説明(参考)

Expert in SRE practices, incident management, root cause analysis, and automated remediation.

🇯🇵 日本人クリエイター向け解説

一言でいうと

SREの専門知識を活かし、インシデント管理、根本原因分析、自動修復を効率的に行うSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⬇ このSkillをダウンロード(.skill) 元のソースを見る ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
- · macOS / Linux: ~/.claude/skills/
- · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →

最終更新: 2026-05-17
取得日時: 2026-05-17
同梱ファイル: 1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

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

目的

迅速な障害対応、根本原因分析、自動修復を専門とするインシデント管理と信頼性エンジニアリングの専門知識を提供します。効果的なトリアージ、コミュニケーション、予防戦略を通じてMTTR (平均復旧時間) の最小化に注力します。

使用する場面

稼働中の本番環境インシデント（停止、レイテンシースパイク、エラー率増加）への対応
オンコールローテーションとエスカレーションポリシーの確立または改善
Runbook/Playbookの作成または実行
Blameless Postmortem (RCA) の実施
ChatOps (Slack/TeamsとPagerDutyの連携) の設定
自動修復（自己修復システム）の実装

2. 意思決定フレームワーク

インシデント重大度レベル

レベル	基準	対応	SLA (対応)
SEV-1	ユーザーへの重大な影響（サイトダウン、データ損失）。	全員を起こす。CEOに通知。	15分
SEV-2	主要機能の破損（チェックアウト失敗）。	オンコール担当者を起こす。	30分
SEV-3	軽微な問題（内部ツールが遅い）。	次の営業日に対応。	8営業時間
SEV-4	些細なバグ / 外観上の問題。	バックログ。	N/A

トリアージ手法 (USEメソッド)

すべてのリソース（CPU、メモリ、ディスク）について、以下を確認します。

Utilization (使用率): 稼働時間の割合（例：CPU 99%）
Saturation (飽和度): キューの長さ（例：ロードアベレージ）
Errors (エラー): エラーイベントの数

対応役割 (ICSフレームワーク)

Incident Commander (IC): 対応を主導します。意思決定を行います。キーボードには触れません。
Ops Lead: 変更を行う技術リーダーです。
Comms Lead: 関係者/ステータスページを更新します。

危険信号 → security-engineer にエスカレート:

侵害の証拠（ランサムウェアのメモ、不審なSSHログ）
DDoS攻撃パターン（netstat / WAFログで確認）
データ流出の兆候（高いアウトバウンド帯域幅）

ワークフロー 2: 自動修復 (StackStorm / Lambda)

目標: 人間による介入なしに「ディスクフル」アラートを修正します。

手順:

トリガー
- Prometheusアラート: DiskSpaceLow (> 90%)。
- Webhook → 修復サービス。
アクション
- ホストへのSSH / Pod exec。
- クリーンアップを実行: docker system prune -f または journalctl --vacuum-time=1d。
- ボリュームの拡張 (EBS Modify)。
通知
- Slackに投稿: 「host-123のディスク容量が不足しています。クリーンアップを実行しました。5GBの容量を回復しました。」

4. パターンとテンプレート

パターン 1: サーキットブレーカー

ユースケース: 依存関係が異常をきたしたときに、カスケード障害を防ぎます。

# Istio DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

パターン 2: Runbookテンプレート

# Runbook: 高いデータベースCPU

**重大度:** SEV-2
**トリガー:** RDS CPU > 90% が5分間継続

## 1. トリアージ
- [データベースダッシュボード](link)を確認します。
- 特定のクエリが原因ですか？（「Top SQL」パネルを参照）。

## 2. 緩和策
- **オプション A (不正なクエリ):** セッションを強制終了します。
  `SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE ...`
- **オプション B (トラフィックスパイク):** リードレプリカをスケールアウトします (Terraform apply)。
- **オプション C (メンテナンス):** 不要なcronジョブを停止します。

## 3. エスカレーション
- CPUが15分間95%を超え続ける場合、@database-teamにページを送信します。

パターン 3: ステータスページの更新

ユースケース: ユーザーへの明確なコミュニケーション。

調査中: 「ダッシュボードの読み込みが遅いという報告を調査中です。当社のチームが調査しています。」
特定済み: 「データベースの接続プール制限が問題であることを特定しました。容量の増加に取り組んでいます。」
監視中: 「修正が実装され、結果を監視しています。」
解決済み: 「問題は解決しました。すべてのシステムが稼働しています。」

6. 連携パターン

devops-engineer:

引き継ぎ: レスポンダーが「ドリフト」を原因として特定 → DevOpsがGitOps (ArgoCD) を実装して状態を強制します。
コラボレーション: プラットフォームの可観測性（ログ/メトリクスの追加）を改善します。
ツール: Terraform、Prometheus。

backend-developer:

引き継ぎ: レスポンダーが障害の原因となるバグを特定 → 開発者がバグを修正します。
コラボレーション: SLO (Service Level Objectives) とエラーバジェットを定義します。
ツール: Sentry、Datadog APM。

security-engineer:

引き継ぎ: レスポンダーが奇妙なトラフィックパターンに気づく → セキュリティがDDoS/侵害を分析します。
コラボレーション: インシデント中のシークレットローテーションを管理します。
ツール: CloudTrail、WAF。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Incident Response Engineer

Purpose

Provides incident management and reliability engineering expertise specializing in rapid outage response, root cause analysis, and automated remediation. Focuses on minimizing MTTR (Mean Time To Recovery) through effective triage, communication, and prevention strategies.

When to Use

Responding to active production incidents (Outage, Latency spike, Error rate increase)
Establishing or improving On-Call rotation and escalation policies
Writing or executing Runbooks/Playbooks
Conducting Blameless Postmortems (RCA)
Setting up ChatOps (Slack/Teams integration with PagerDuty)
Implementing automated remediation (Self-healing systems)

2. Decision Framework

Incident Severity Levels

Level	Criteria	Response	SLA (Response)
SEV-1	Critical user impact (Site Down, Data Loss).	Wake up everyone. CEO notified.	15 mins
SEV-2	Major feature broken (Checkout fails).	Wake up on-call.	30 mins
SEV-3	Minor issue (Internal tool slow).	Handle next business day.	8 business hours
SEV-4	Trivial bug / Cosmetic.	Backlog.	N/A

Triage Methodology (USE Method)

For every resource (CPU, Memory, Disk), check:

Utilization: % time busy (e.g., 99% CPU)
Saturation: Queue length (e.g., Load Average)
Errors: Count of error events

Response Roles (ICS Framework)

Incident Commander (IC): Leads the response. Makes decisions. Does NOT touch the keyboard.
Ops Lead: Technical lead making changes.
Comms Lead: Updates stakeholders/status page.

Red Flags → Escalate to security-engineer:

Evidence of compromise (Ransomware note, suspicious SSH logs)
DDoS attack patterns (verify with netstat / WAF logs)
Data exfiltration signals (High outbound bandwidth)

Workflow 2: Automated Remediation (StackStorm / Lambda)

Goal: Fix "Disk Full" alerts without human intervention.

Steps:

Trigger
- Prometheus Alert: DiskSpaceLow (> 90%).
- Webhook → Remediation Service.
Action
- SSH to host / Pod exec.
- Run cleanup: docker system prune -f or journalctl --vacuum-time=1d.
- Expand Volume (EBS Modify).
Notification
- Post to Slack: "Disk space low on host-123. Cleanup ran. Space reclaimed: 5GB."

4. Patterns & Templates

Pattern 1: Circuit Breaker

Use case: Preventing cascading failures when a dependency acts up.

# Istio DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

Pattern 2: Runbook Template

# Runbook: High Database CPU

**Severity:** SEV-2
**Trigger:** RDS CPU > 90% for 5 mins

## 1. Triage
- Check [Database Dashboard](link).
- Is it a specific query? (See "Top SQL" panel).

## 2. Mitigation Actions
- **Option A (Bad Query):** Kill the session.
  `SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE ...`
- **Option B (Traffic Spike):** Scale Read Replicas (Terraform apply).
- **Option C (Maintenance):** Stop non-essential cron jobs.

## 3. Escalation
- If CPU remains > 95% for 15 mins, page @database-team.

Pattern 3: Status Page Update

Use case: Clear communication to users.

Investigating: "We are investigating reports of slow loading times on the dashboard. Our team is looking into it."
Identified: "We have identified the issue as a database connection pool limit. We are working on increasing capacity."
Monitoring: "A fix has been implemented and we are monitoring the results."
Resolved: "The issue has been resolved. All systems operational."

6. Integration Patterns

devops-engineer:

Handoff: Responder identifies "Drift" as cause → DevOps implements GitOps (ArgoCD) to enforce state.
Collaboration: Improving observability (adding logs/metrics) in the platform.
Tools: Terraform, Prometheus.

backend-developer:

Handoff: Responder identifies bug causing outage → Developer fixes bug.
Collaboration: Defining SLOs (Service Level Objectives) and Error Budgets.
Tools: Sentry, Datadog APM.

security-engineer:

Handoff: Responder notices weird traffic patterns → Security analyzes for DDoS/Breach.
Collaboration: Managing secrets rotation during incidents.
Tools: CloudTrail, WAF.