Claude Code インシデントレスポンス入門devops-automation プラグインの/incidentコマンドで本番障害を構造化対応する【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto本稿では、Claude Code の公式プラグインdevops-automationに含まれる/incidentスラッシュコマンドについて解説します。本番環境でインシデントが発生した際、記録作成から重大度評価、チーム通知、診断情報の収集、対応統率、解決のドキュメント化、ポストモーテム設定までを、Claude が構造化された7ステップのワークフローとして遂行する仕組みを、実際のプラグイン構成サブエージェント、スクリプト、フック、MCPと合わせて詳しく紹介します。1./incidentコマンドとはdevops-automation は、デプロイ、モニタリング、インシデントレスポンスをカバーする DevOps 自動化プラグインです。その中で/incidentは「本番インシデントを構造化された手順で処理する」ための専用コマンドです。/incidentを実行すると、Claude は以下の7ステップのワークフローを順に実行しますインシデントレコードを作成インシデント記録の作成重大度と影響範囲を評価重大度・影響範囲の評価オンコールチームへ通知オンコールチームへの通知診断情報を収集診断情報の収集対応活動を統率対応活動の統率解決内容をドキュメント化解決内容のドキュメント化ポストモーテムを設定ポストモーテムの設定つまり、/incidentは単なる「障害を知らせる」コマンドではなく、障害のライフサイクル全体を構造化して扱うための入り口です。現場で慌ててアドホックに対応するのではなく、再現性のある手順で対応を進めることを目的としています。2. インストールと前提条件プラグインを利用するには、まず Claude Code2.1 以上と Kubernetes 環境が必要です。README のインストール手順は次のとおりです/plugin install devops-automationKubernetes クラスタへの接続設定も必須ですexport KUBECONFIG~/.kube/configこのKUBECONFIGは、プラグイン付属の kubernetes-config.json で Kubernetes MCP サーバーに渡される環境変数としても利用されます{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }この MCP サーバーを介して、Claude はクラスタ内の Pod 状態やデプロイメントの状況をリアルタイムに参照できます。プラグインに含まれる関連コンポーネント/incidentは単独で動くわけではなく、以下のコンポーネントと連携しますスラッシュコマンド:/deploy,/rollback,/status,/incidentサブエージェント:deployment-specialist,incident-commander,alert-analyzerMCP サーバー: Kubernetes 統合スクリプト:deploy.sh,rollback.sh,health-check.shフック:pre-deploy.js,post-deploy.js3. 7ステップのワークフローを詳解ステップ1インシデントレコードを作成インシデント対応の第一歩は、発生事象を記録として残すことです。Claude がインシデントの起点となる情報発生時刻、影響サービス、報告者などを収集し、レコードとして体系化します。ステップ2重大度と影響範囲を評価収集した情報をもとに、重大度例SEV1〜SEV3と影響範囲例一部ユーザー全ユーザー、特定リージョングローバルを評価します。この評価は、後続の通知先や対応優先度を決める基準になります。この評価作業の中核を担うのが、サブエージェント incident-commander です。このエージェントは以下を責務としています重大度評価Severity assessmentチームの統率Team coordinationステータス更新Status updates解決状況の追跡Resolution trackingポストモーテムの進行Post-mortem facilitationステップ3オンコールチームへ通知評価結果に基づき、オンコール担当者やチームに通知を行います。通知は Slack などのチャネル経由で行われます同一プラグインの/deployコマンドも最終ステップで「Slack でチームに通知」する構成になっており、通知をワークフローの一部として組み込む設計思想が共通しています。ステップ4診断情報を収集障害の原因を特定するため、システムの診断情報を収集します。ここで役立つのが、もう一つのサブエージェント alert-analyzer ですアラートの相関分析Alert correlationトレンド分析Trend analysis根本原因の特定Root cause identificationメトリクス可視化Metric visualization問題の先取り検出Proactive issue detectionまた、プラグイン付属の health-check.sh は、API・データベース・Kubernetes Pod の3系統を一括でチェックできる診断スクリプトです#!/bin/bash echo System Health Check echo ENV${1:-production} # Check API echo -n API: if curl -sf http://api.$ENV.example.com/health /dev/null; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Database echo -n Database: if pg_isready -h db.$ENV.example.com /dev/null 21; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Pods echo -n Kubernetes Pods: PODS_READY$(kubectl get pods -n $ENV --no-headers | grep Running | wc -l) PODS_TOTAL$(kubectl get pods -n $ENV --no-headers | wc -l) echo $PODS_READY/$PODS_TOTAL ready echo 実行例./health-check.sh production # 出力例 # System Health Check # # API: ✅ Healthy # Database: ✅ Healthy # Kubernetes Pods: 3/3 ready # デフォルト環境はproductionで、第1引数で切り替えられます。curl -fやpg_isreadyの終了コードで健全性を判定している点がポイントです。ステップ5対応活動を統率診断結果に基づき、実際の復旧作業ロールバック、再デプロイ、スケール変更などを統率します。ここでincident-commanderが中心となって対応をコーディネートし、必要に応じて同一プラグインの/rollbackや/deployコマンドと連携します。たとえば、デプロイ起因の障害であれば rollback.sh を使って前回の安定版へ切り戻す流れになります#!/bin/bash set -e echo ⏪ Starting rollback... ENV${1:-staging} echo Target environment: $ENV # Get previous deployment PREVIOUS$(kubectl rollout history deployment/app -n $ENV | tail -2 | head -1 | awk {print $1}) echo Rolling back to revision: $PREVIOUS # Execute rollback kubectl rollout undo deployment/app -n $ENV # Wait for rollback echo ⏳ Waiting for rollback to complete... kubectl rollout status deployment/app -n $ENV # Health check echo Running health checks... sleep 5 curl -f http://api.$ENV.example.com/health echo ✅ Rollback complete!kubectl rollout historyで直前のリビジョンを特定し、kubectl rollout undoで復元、rollout statusで完了を待ち、最後にヘルスチェックまで実行する、という一貫した流れになっています。ステップ6解決内容をドキュメント化復旧後、発生した事象・原因・対応内容をドキュメントとして残します。これは再発防止のための重要な資産であり、incident-commanderの「Resolution tracking」責務とも対応しています。ステップ7ポストモーテムを設定最後に、チームメンバーが集まって振り返る**ポストモーテム事後検証**のセッションを設定します。incident-commanderの「Post-mortem facilitation」がここに対応し、根本原因の再検証と再発防止策の策定を行います。4. 実行フローの全体像プラグインの README にある例/deployの場合から、コマンド実行時の Claude の動き方は以下のように想定できますUser: /deploy production Claude: 1. Runs pre-deploy hook (validates kubectl, cluster connection) 2. Delegates to deployment-specialist subagent 3. Runs deploy.sh script 4. Monitors deployment progress via Kubernetes MCP 5. Runs post-deploy hook (waits for pods, smoke tests) 6. Provides deployment summary Result: ✅ Deployment complete Version: v2.1.0 Pods: 3/3 ready ⏱️ Time: 2m 34s/incidentも同様のパターンで動きます。フックやスクリプトの実行、サブエージェントへの委譲、MCP によるクラスタ監視を組み合わせて進行します。5. まとめ/incidentコマンドは、本番インシデント対応を「記録 → 評価 → 通知 → 診断 → 統率 → 文書化 → ポストモーテム」という構造化されたワークフローで進めるための入口です。バックエンドではincident-commander統率とポストモーテムalert-analyzer診断情報の分析health-check.shAPI・DB・Pod のヘルスチェックkubernetes-config.jsonKubernetes MCP 接続といったコンポーネントが連携し、アドホックな対応ではなく再現性のあるインシデントレスポンスを実現します。なお、このプラグインは Claude Code 2.1 以上が必要で、kubectlのインストールとクラスタアクセスの設定が前提です。環境が整っていれば、/incidentと入力するだけで、Claude が障害対応の進行役となってくれます。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考