SKILL: インシデント対応

ゴールデンルール

1. 透明性 — 早期かつ頻繁にコミュニケーションを取る
2. 焦点 — システムをオンラインに戻す（完璧さは二の次）
3. 学習 — 全てのインシデントからポストモーテムを生成する
4. 非難なし — システムを責める、人を責めない

インシデント対応ランブック

Phase 1: 検出とトリアージ（最初の2分）

□ エラー率が5分以内に1%を超える → インシデント発動
□ オンコール エンジニアに通知（PagerDuty / Slack統合）
□ 重要度を宣言:
   CRITICAL: 100%のユーザーに影響、コア機能がダウン
   HIGH: 50%以上のユーザーに影響、またはエラー率が5%を超える
   MEDIUM: 50%未満のユーザーに影響、回避策が存在
   LOW: マイナー機能が破損、顧客への影響なし

□ インシデントチケットを作成:
   - 開始時刻（秒単位）
   - 重要度レベル
   - 影響を受けるサービス
   - 初期エラーメッセージ / メトリクス上昇

Phase 2: 初期対応（最初の5分）

□ オンコール チームを集める:
   - サービスオーナー（システムを知っている）
   - オンコール エンジニア（問題を解決する）
   - オンコール マネージャー（コミュニケーションを取る）

□ 出血を止める（完璧な修正はまだ不要）:
   OPTION A: フィーチャーフラグ → 破損した機能を無効化
   OPTION B: スケール → 過負荷の場合、キャパシティを追加
   OPTION C: リバート → 最後のデプロイメントをロールバック
   （通常、フラグで機能を無効化するのが最速）

□ コミュニケーション:
   - ステータスページを更新: 「調査中です...」
   - 顧客にメール（CRITICAL/HIGHの場合）
   - Slack #incidents: 「Service X がダウン、調査中。ETA 10分」

Phase 3: 根本原因分析（10〜30分）

この順序でチェック（通常は最初の3つで解決）:

1. 最近のデプロイメント? → デプロイ差分を確認
2. トラフィック スパイク? → ダッシュボード メトリクスを確認
3. データベースが遅い? → クエリのパフォーマンスを確認
4. サードパーティ問題? → ステータスページを確認（AWS、Stripe等）
5. 設定? → 環境変数を検証
6. リソース枯渇? → CPU、メモリ、ディスクを確認
7. 並行処理の問題? → ログで競合状態を確認

# クイック診断スクリプト
async def diagnose_incident():
    checks = {
        "last_deploy": await get_last_deploy_time(),
        "error_rate": await get_current_error_rate(),
        "p99_latency": await get_p99_latency(),
        "database_health": await check_db_connection(),
        "cpu_usage": await get_cpu_percent(),
        "memory_usage": await get_memory_percent(),
        "disk_usage": await get_disk_percent(),
        "recent_errors": await get_latest_error_logs(limit=20),
    }
    
    # 診断結果を出力
    for check, result in checks.items():
        status = "🔴" if result["bad"] else "✅"
        print(f"{status} {check}: {result['message']}")

Phase 4: 実装（30〜60分以上）

IF 根本原因 = 最近のデプロイメント:
  Option 1: デプロイをリバート（1分で修正）
    flyctl releases rollback --app [app]
    git revert [commit-sha]
    
  Option 2: 前進して修正（コードを修正、再デプロイ）
    [最小限の修正を行う]
    git commit -m "fix: [インシデント問題]"
    flyctl deploy

IF 根本原因 = データベース:
  速度低下の原因となったクエリを実行
  インデックスを追加またはクエリを最適化
  再デプロイ
  解決を監視

IF 根本原因 = リソース枯渇:
  スケールアップ: より多くのリソースを追加
  監視: 復旧したか?
  安定後: 理由を調査（メモリリーク、非効率なコード）

Phase 5: 復旧と検証（インシデント解決時）

□ 修正を検証:
  - エラー率が0.1%未満に戻る
  - P95レイテンシーがベースラインに戻る
  - 顧客からの問題報告が止まる（サポートチャネルを監視）
  - ステージング環境で機能が動作
  - 本番環境でスポット チェック

□ 解決をコミュニケーション:
  - ステータスページを更新: 「問題は解決しました」
  - 顧客にメール: 「インシデントを解決しました...」
  - Slack: 「インシデントは[タイムスタンプ]に解決、根本原因[要約]」

□ 次の30分間は密接に監視:
  - 全メトリクスの異常検出
  - 再発の兆候があるか?

Phase 6: ポストモーテム（24時間以内）

# インシデント ポストモーテム: [インシデント名]

## タイムライン
- 14:32 UTC: エラー率スパイク検出
- 14:34 UTC: オンコール チームに通知
- 14:38 UTC: 根本原因を特定（新機能のメモリリーク）
- 14:41 UTC: フラグで機能を無効化
- 14:44 UTC: エラー率が正常化

## 根本原因
新しいレコメンデーション エンジン（13:45のデプロイ）のメモリリーク。
各リクエストが100MBを割り当て、解放されない。
200リクエスト後、サービスがメモリ不足になりクラッシュ。

## 発生した理由
- デプロイ前のメモリ プロファイリングなし
- ロード テストで10の同時ユーザーのみテスト
- 本番環境は1000の同時ユーザー

## これを防ぐためにやること
- [ ] デプロイ前チェックにメモリ プロファイリングを実装
- [ ] 予想される同時ユーザー数の10倍でロード テスト
- [ ] メモリ使用率アラートを追加（2分間で80%を超える場合にトリガー）
- [ ] リスクの高い機能にフィーチャーフラグを使用（この機能は使用すべきだった）

## フォローアップ
- メモリ プロファイリング PR: [日付]までに
- ロード テスト プロセス: [日付]までに
- アラート設定: [日付]までに

クオリティ チェック

• ランブックを作成、オンコール チームがアクセス可能
• ステータスページを設定（デプロイなしで更新可能）
• 全ての重要な機能でフィーチャーフラグを使用
• 重要なメトリクスの監視アラートを設定
• オンコール ローテーションをドキュメント化
• ポストモーテム テンプレートを作成
• チームがインシデント対応プロセスをトレーニング済み