incident-response について
本番環境のインシデントに対応するチーム向けのスキルです。重大度の基準に沿って、初動、緩和、連絡、復旧、責任追及をしない振り返りを進めます。
主な機能
- 01重大度と対応時間の基準
- 02検知・トリアージのチェック項目
- 03一般的な障害への緩和策
- 04社内外への状況共有の指針
- 05復旧と振り返りの手順
活用シーン
- 01本番障害の重大度判定
- 02初動の緩和策の選択
- 03インシデント状況の共有
- 04解決後の改善点の記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ revitalb-port/ skills-registry-demo --skill incident-responseインストール後、Claude Code で/incident-responseを入力して読み込まれたか確認します。
詳細
インシデント対応
本番環境のインシデントに体系的に対処します。
重大度レベル
| レベル | 定義 | 対応時間 | 例 |
|---|---|---|---|
| SEV1 | サービスが停止し、すべてのユーザーに影響 | 即時 | データベースのクラッシュ、DNS 障害、認証の不具合 |
| SEV2 | 主要機能が使えず、多数のユーザーに影響 | < 30 分 | 決済の失敗、検索の不具合 |
| SEV3 | 軽微な機能が使えないが、回避策がある | < 4 時間 | エクスポートボタンの不具合、ダッシュボードの動作が遅い |
| SEV4 | 見た目上の問題、または影響の小さい問題 | 翌営業日 | UI の誤字、軽微なスタイルの不具合 |
インシデント対応ワークフロー
1. 検知とトリアージ(最初の 5 分)
- インシデントを確認します。「調査しています」
- 重大度レベルを判断します
- 監視ダッシュボード(エラー率、レイテンシ、ステータスページ)を確認します
- 最近のデプロイを確認します。
git log --oneline -10— 最近何かデプロイされましたか?
2. 緩和(次の 15~30 分)
目標は根本原因を見つけることではなく、まず被害を食い止めることです。
迅速な緩和策:
- ロールバック:
git revert <commit> && deploy— デプロイが原因の場合、最も早い方法です - 機能フラグ:不具合のある機能を無効にします
- スケールアップ:容量の問題であれば、インスタンスを追加します
- フェイルオーバー:プライマリが停止している場合、バックアップ/セカンダリに切り替えます
- トラフィックをブロック:特定の悪質なトラフィックをレート制限するか、ブロックします
3. コミュニケーション
社内向け:
- インシデント用チャンネル(
#incident-2026-04-10)を開設します - 15~30 分ごとに状況を更新します
- 役割を割り当てます:インシデントコマンダー、コミュニケーター、エンジニア
社外向け:
- ステータスページを更新します
- サービス停止が長引く場合は、影響を受けるユーザーにメール/通知を送ります
- 正直に伝えます:「X に問題が発生しています。原因を特定し、修正に取り組んでいます。」
4. 解決
- 修正をデプロイします
- 修正が本番環境で機能していることを確認します(エラーがないことだけでなく、メトリクスを確認します)
- インシデント用チャンネルを要約とともに終了します
5. ポストモーテム(48 時間以内)
非難のないポストモーテムを作成します。
# Incident: Payments failing for Stripe webhook
**Date:** 2026-04-10
**Duration:** 45 minutes (14:30 — 15:15 UTC)
**Severity:** SEV2
**Impact:** ~200 users unable to complete purchases
## Timeline
- 14:30 — Alert fires: payment success rate drops to 20%
- 14:35 — On-call engineer acknowledges, begins investigation
- 14:40 — Identified: Stripe webhook endpoint returning 500
- 14:45 — Root cause: migration added NOT NULL column without default
- 14:50 — Fix deployed: added default value to migration
- 15:00 — Payment success rate recovering
- 15:15 — Metrics back to normal, incident closed
## Root Cause
Database migration #47 added a `currency` column with NOT NULL
but no DEFAULT value. Existing rows were fine (backfilled), but
new webhook events failed because the insert didn't include `currency`.
## What Went Well
- Alert fired within 5 minutes of the issue starting
- Rollback was considered but the fix was faster
## What Went Wrong
- Migration wasn't tested with live webhook payloads
- No staging test for the webhook flow
## Action Items
- [ ] Add webhook integration test to CI (@alice, due 2026-04-17)
- [ ] Require DEFAULT for all new NOT NULL columns in migration review (@bob)
- [ ] Add runbook for payment failures (@charlie, due 2026-04-14)
ヒント
- まずロールバックし、調査は後で行います。洗練さよりもスピードが重要です
- 最も直近のデプロイが原因である可能性が最も高いです
- ポストモーテムで個人を責めず、プロセスの改善に注力します
- よくある障害パターンに備えて、ランブックを整備します
- 実際のインシデントが発生する前に、ゲームデーでインシデント対応を訓練します
コメント
Markdown 対応