ai-sre-incident-response

AI SRE インシデント対応

品質の低下、安全でない出力、予算の急増などのインシデントが発生する AI システムに、SRE の厳格な運用を適用します。

このスキルを使用する場面

• LLM エンドポイントが、品質の低下した回答やハルシネーションを含む回答を返し始めた
• トークンの支出が予算のしきい値を超えて急増した
• モデルプロバイダーがダウンし、トラフィックをフェイルオーバーする必要がある
• 安全性ガードレールが通常と異なる頻度で作動する
• 新しいモデルのデプロイによって、レイテンシまたは精度が低下した

前提条件

• AI サービスのスクレイプ対象を設定した Prometheus と Alertmanager がデプロイされている
• ゴールデンシグナル（レイテンシ、エラー率、コスト、品質）を表示する Grafana ダッシュボードがある
• PagerDuty、Opsgenie、または同等のサービスでオンコールローテーションが設定されている
• 対応者がランブックリポジトリにアクセスできる
• モデルとプロンプトのバージョンをロールバックする仕組みがある（GitOps またはフィーチャーフラグ）

AI インシデントの分類

• 可用性インシデント：モデルまたはプロバイダーが利用できない、タイムアウトが多発している。
• 品質インシデント：回答の精度またはツールの成功率が SLO を下回っている。
• 安全性インシデント：有害な出力またはポリシー違反の出力が増加している。
• コストインシデント：トークンの支出またはプロバイダーへの支出が予期せず急増している。

重大度フレームワーク

重大度	基準	対応時間	通知
SEV1	ユーザー向けサービスの停止、コンプライアンスリスク、データ漏えい	5 分	オンコール担当者とインシデントコマンダーにページ通知
SEV2	主要なフローで大幅な品質低下	15 分	オンコール担当者にページ通知
SEV3	影響範囲が限定的、または社内のみの問題	1 時間	Slack アラート
SEV4	外観上の問題、または優先度の低い品質低下	翌営業日	チケット

AI サービスのゴールデンシグナル

• リクエスト成功率
• レイテンシ（キュー処理＋生成＋ツール実行）
• ハルシネーション／根拠の確かさを示す代理指標
• 1 分あたりおよびテナントあたりのコスト
• ガードレール違反率

Prometheus アラートルール

# prometheus-ai-alerts.yaml
groups:
  - name: ai-service-alerts
    rules:
      - alert: ModelEndpointDown
        expr: up{job="llm-inference"} == 0
        for: 2m
        labels:
          severity: sev1
        annotations:
          summary: "LLM inference endpoint {{ $labels.instance }} is down"
          runbook_url: "https://runbooks.internal/ai/model-outage"

      - alert: HighHallucinationRate
        expr: |
          rate(llm_hallucination_detected_total[10m])
          / rate(llm_requests_total[10m]) > 0.15
        for: 5m
        labels:
          severity: sev2
        annotations:
          summary: "Hallucination rate above 15% for {{ $labels.model }}"
          runbook_url: "https://runbooks.internal/ai/quality-regression"

      - alert: TokenCostExplosion
        expr: |
          sum(rate(llm_token_cost_dollars[5m])) by (tenant)
          > 0.50
        for: 3m
        labels:
          severity: sev2
        annotations:
          summary: "Token spend exceeds $0.50/min for tenant {{ $labels.tenant }}"
          runbook_url: "https://runbooks.internal/ai/cost-spike"

      - alert: LatencyP95Exceeded
        expr: |
          histogram_quantile(0.95,
            rate(llm_request_duration_seconds_bucket[5m])
          ) > 5
        for: 5m
        labels:
          severity: sev2
        annotations:
          summary: "LLM p95 latency exceeds 5s for {{ $labels.service }}"

      - alert: GuardrailViolationSpike
        expr: |
          rate(llm_guardrail_violations_total[10m])
          / rate(llm_requests_total[10m]) > 0.05
        for: 5m
        labels:
          severity: sev1
        annotations:
          summary: "Guardrail violations above 5% for {{ $labels.model }}"
          runbook_url: "https://runbooks.internal/ai/safety-incident"

      - alert: ModelQualityDrop
        expr: |
          llm_eval_score{metric="groundedness"} < 0.70
        for: 10m
        labels:
          severity: sev2
        annotations:
          summary: "Groundedness score dropped below 0.70 for {{ $labels.model }}"

      - alert: ProviderErrorRateHigh
        expr: |
          rate(llm_provider_errors_total[5m])
          / rate(llm_provider_requests_total[5m]) > 0.10
        for: 3m
        labels:
          severity: sev2
        annotations:
          summary: "Provider {{ $labels.provider }} error rate above 10%"

対応プレイブック

モデル障害ランブック

TRIGGER: ModelEndpointDown fires for > 2 minutes
RESPONDER: On-call AI platform engineer

1. Acknowledge alert in PagerDuty.
2. Check provider status page (e.g., status.openai.com).
3. Verify network connectivity:
     curl -s -o /dev/null -w "%{http_code}" https://api.provider.com/health
4. If provider is down:
     a. Enable fallback model route in gateway config.
     b. kubectl set env deployment/llm-gateway FALLBACK_ENABLED=true
     c. Verify fallback traffic is flowing via Grafana dashboard.
5. If self-hosted model is down:
     a. Check pod status: kubectl get pods -l app=llm-inference -n ai
     b. Check GPU health: kubectl logs -l app=llm-inference --tail=50
     c. Restart if OOM: kubectl rollout restart deployment/llm-inference -n ai
6. Freeze all deployments:
     kubectl annotate deployment --all deploy-freeze=true -n ai
7. Communicate ETA in #incident-channel.
8. When resolved, unfreeze and run smoke tests.

品質低下ランブック（ハルシネーションの急増）

TRIGGER: HighHallucinationRate or ModelQualityDrop fires
RESPONDER: On-call AI engineer + ML lead

1. Acknowledge alert. Open incident ticket.
2. Identify scope:
     - Which model version? Check deployment metadata.
     - Which routes/tenants affected? Filter by labels in Grafana.
3. Check recent changes:
     - Model version promotion in last 24h?
     - Prompt template changes in last 24h?
     - Retrieval index rebuild in last 24h?
4. If recent model change:
     kubectl rollout undo deployment/llm-inference -n ai
5. If recent prompt change:
     git revert <commit> && git push  # triggers GitOps redeploy
6. Increase trace sampling to 100% for affected route:
     kubectl set env deployment/llm-gateway TRACE_SAMPLE_RATE=1.0
7. Run offline eval suite against current production:
     python run_evals.py --target prod --suite quality --compare baseline
8. Confirm metrics return to baseline before closing.

トークンコスト急増ランブック

TRIGGER: TokenCostExplosion fires
RESPONDER: On-call platform engineer

1. Identify top consumers:
     Query: topk(10, sum(rate(llm_token_cost_dollars[15m])) by (tenant, model, route))
2. Check for runaway loops:
     - Agent retry storms (exponential token growth per request)
     - Missing max_tokens caps on new routes
     - Cache bypass due to config change
3. Apply immediate caps:
     kubectl patch configmap llm-quotas -n ai --patch '
       data:
         max_tokens_per_request: "4096"
         rpm_limit: "60"
     '
4. Enable semantic cache if disabled:
     kubectl set env deployment/llm-gateway CACHE_ENABLED=true
5. Route traffic to cheaper model tier:
     kubectl set env deployment/llm-gateway DEFAULT_MODEL=gpt-4o-mini
6. Notify affected tenants of temporary limits.
7. Open postmortem with cost attribution analysis.

エスカレーション手順

Level 1 (0-15 min):  On-call AI platform engineer
Level 2 (15-30 min): AI platform team lead + affected product owner
Level 3 (30-60 min): Engineering director + security (if safety incident)
Level 4 (60+ min):   VP Engineering + legal (if compliance/data incident)

Safety incidents always start at Level 2 minimum.
Provider-side incidents: open support ticket immediately at Level 1.

検出クエリ（PromQL）

# Request success rate by model
1 - (
  sum(rate(llm_requests_total{status="error"}[5m])) by (model)
  / sum(rate(llm_requests_total[5m])) by (model)
)

# Cost per successful answer
sum(rate(llm_token_cost_dollars[5m])) by (route)
/ sum(rate(llm_requests_total{status="success"}[5m])) by (route)

# Hallucination rate trend (1h window, 5m steps)
rate(llm_hallucination_detected_total[1h])
/ rate(llm_requests_total[1h])

# Latency breakdown by stage
histogram_quantile(0.95, rate(llm_retrieval_duration_seconds_bucket[5m]))
histogram_quantile(0.95, rate(llm_generation_duration_seconds_bucket[5m]))
histogram_quantile(0.95, rate(llm_tool_execution_duration_seconds_bucket[5m]))

# Tenant cost leaderboard
topk(10, sum(rate(llm_token_cost_dollars[1h])) by (tenant))

ポストモーテムの要件

• 検出時刻と対応者のタイムスタンプを含むタイムライン
• テナントおよび機能ごとの影響範囲
• 見逃したシグナルとアラートの調整内容
• 担当者と期限を定めた具体的な強化タスク
• コストへの影響（金額、トークン数、影響を受けたリクエスト数）
• 顧客への連絡記録

ポストモーテムのテンプレート

## Incident Summary
- **Severity**: SEVx
- **Duration**: start_time - end_time (Xh Ym)
- **Detection**: How was it detected? (alert / customer report / manual)
- **Impact**: X tenants, Y requests, $Z cost

## Timeline
| Time (UTC) | Event |
|------------|-------|
| HH:MM | Alert fired |
| HH:MM | Responder acknowledged |
| HH:MM | Root cause identified |
| HH:MM | Mitigation applied |
| HH:MM | Incident resolved |

## Root Cause
[Description]

## Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| Tune alert threshold | @engineer | YYYY-MM-DD | Open |
| Add fallback route | @platform | YYYY-MM-DD | Open |

AI システムのカオスエンジニアリング

インシデント対応の準備状況を定期的にテストします。

• プロバイダーのフェイルオーバー訓練：ネットワークレベルでプロバイダーの API をブロックし、SLO 以内にフォールバックが有効になることを確認します。
• モデルのロールバック訓練：問題のあることが分かっているモデルバージョンをデプロイし、自動品質ゲートが検出することを確認します。
• コスト上限の訓練：トークン使用量の急増をシミュレートし、予算のしきい値に達する前にクォータが作動することを確認します。
• キャッシュ障害の訓練：セマンティックキャッシュを無効にし、システムが適切に縮退することを確認します。

トラブルシューティング

症状	確認項目	対処方法
すべてのリクエストがタイムアウトする	プロバイダーのステータスページ、DNS 解決	フォールバックプロバイダーを有効にする
品質が徐々に低下する	最近のモデル／プロンプトのデプロイ	最後に正常だったバージョンにロールバックする
コストが突然急増する	テナントごとのトークン使用量ダッシュボード	緊急のトークン上限を適用する
ガードレール違反が急増する	モデルバージョン、プロンプトインジェクションのログ	より厳格な入力フィルタリングを有効にする
503 エラーが断続的に発生する	Pod の再起動、GPU の OOM イベント	メモリ上限を増やすか、バッチサイズを減らす

関連スキル

• incident-response - 標準的なインシデント対応プロセスと証跡
• alerting-oncall - ページ通知とエスカレーションのポリシー
• llm-cost-optimization - 支出の管理と効率化のパターン
• agent-observability - リクエスト、トレース、コストの計測
• rag-observability-evals - RAG の品質モニタリング