slo_definitions:
  - name: API可用性
    sli: "成功レスポンス(2xx, 3xx) / 全リクエスト"
    target: 99.9%
    window: "30日ローリング"
    error_budget: "月間約43分のダウンタイム"
    business_impact: "可用性低下は直接的な売上損失に直結"
    measurement: "rate(http_requests_total{status!~'5..'}[30d]) / rate(http_requests_total[30d])"

  - name: APIレイテンシ
    sli: "レスポンスタイム P99"
    target: "P99 < 500ms (全リクエストの99%が500ms以下)"
    window: "30日ローリング"
    error_budget: "P99が500msを超えるリクエストが1%まで許容"
    business_impact: "レイテンシ悪化はカート離脱率の増加に直結"
    measurement: "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))"

  - name: 決済成功率
    sli: "決済成功リクエスト / 全決済リクエスト"
    target: 99.95%
    window: "30日ローリング"
    error_budget: "月間約22分の決済障害許容"
    business_impact: "決済失敗は直接的な売上損失かつ顧客信頼の低下"
    measurement: "rate(payments_total{status='success'}[30d]) / rate(payments_total[30d])"

error_budget_policy:
  thresholds:
    - budget_remaining: ">50%"
      status: "正常"
      actions:
        - "通常どおり新機能リリースを推進"
        - "実験的な変更も許容"

    - budget_remaining: "25-50%"
      status: "注意"
      actions:
        - "リスクの高いリリースはレビュー強化"
        - "カナリアリリースの期間を延長（通常30分→2時間）"
        - "変更のバッチサイズを小さくする"

    - budget_remaining: "10-25%"
      status: "警告"
      actions:
        - "新機能リリースを週1回に制限"
        - "信頼性改善タスクをスプリントの50%に設定"
        - "全デプロイにインシデントコマンダーのアプルーバルを必須化"

    - budget_remaining: "<10%"
      status: "凍結"
      actions:
        - "新機能リリースを全面凍結"
        - "セキュリティパッチとクリティカルバグ修正のみ許可"
        - "チーム全体で信頼性改善に注力"
        - "経営層へのエスカレーション"

  review:
    frequency: "週次"
    participants: ["SREリード", "プロダクトマネージャー", "テックリード"]

oncall_design:
  rotation:
    type: "weekly"
    team_size: 6
    primary: 1
    secondary: 1

  schedule:
    weekday: "09:00-18:00 (プライマリ + セカンダリ)"
    after_hours: "18:00-09:00 (プライマリのみ、エスカレーション有)"
    weekend: "プライマリのみ、SEV1/2のみ対応"

  escalation:
    level1: "プライマリオンコール (応答目標: 5分)"
    level2: "セカンダリオンコール (15分応答なしで自動エスカレーション)"
    level3: "テックリード (30分応答なし)"
    level4: "CTO (SEV1が1時間未解決)"

  wellbeing:
    max_consecutive_weeks: 1
    handoff_meeting: "毎週月曜10:00"
    compensatory_off: "深夜対応(22:00-06:00)は翌日半休"
    interruption_budget: "オンコール中の割り込みは週20%以内を目標"

# プレイブック: 決済障害 (SEV1)

## トリガー
- Payment Serviceのエラー率 > 5% が5分間継続
- 決済成功率SLO違反アラート

## 初動（最初の5分）
1. Slackチャネル #incident-payment を作成
2. ダッシュボード確認: Payment Service RED メトリクス
3. 影響範囲確認: 全ユーザーか特定セグメントか

## 診断（5-15分）
1. トレースでPayment Serviceのエラー詳細を確認
2. 外部決済API(Stripe)のステータスページを確認
3. 直近のデプロイ履歴を確認（git log / CD履歴）
4. ログでエラーコードとスタックトレースを確認

## 暫定対応
| 原因 | 対応 |
|------|------|
| デプロイ起因 | 前バージョンにロールバック |
| Stripe障害 | フォールバック決済に切り替え |
| 負荷起因 | Payment Serviceをスケールアウト |
| DB起因 | DBコネクション確認、必要に応じて再起動 |

## コミュニケーション
- 初報: 検知から10分以内にSlack #general に投稿
- 更新: 30分ごとにステータス更新
- 解決報告: 復旧確認後、速やかに全体通知

## 復旧確認
- エラー率が正常値（< 0.5%）に回復
- 決済成功率が99.9%以上に回復
- 15分間安定していることを確認

chaos_experiment_plan:
  quarter: "2025 Q1"

  experiments:
    - month: 1
      name: "Payment Service Pod 停止"
      hypothesis: "サーキットブレーカーが作動し、注文は適切なエラーで応答"
      target: "payment-service (50% of pods)"
      duration: "5分"
      schedule: "1月第2水曜 14:00"

    - month: 1
      name: "Database 接続遅延注入"
      hypothesis: "コネクションプールのタイムアウトが正常に機能"
      target: "PostgreSQL (200ms遅延注入)"
      duration: "10分"
      schedule: "1月第4水曜 14:00"

    - month: 2
      name: "外部API (Stripe) 障害シミュレーション"
      hypothesis: "フォールバック決済が自動的に有効化"
      target: "Stripe API呼び出し (503返却)"
      duration: "5分"
      schedule: "2月第2水曜 14:00"

    - month: 3
      name: "API Gateway 高負荷テスト"
      hypothesis: "オートスケーリングとRate Limitingが正常に機能"
      target: "API Gateway (通常の3倍のトラフィック)"
      duration: "15分"
      schedule: "3月第2水曜 14:00"

  prerequisites:
    - "全実験にロールバック手順を用意"
    - "実験中は専任のインシデントコマンダーを配置"
    - "低トラフィック帯（14:00-15:00）に実施"

toil_reduction_plan:
  current_toil:
    - task: "手動デプロイ（承認 + 実行）"
      frequency: "週5回"
      time_per_occurrence: "30分"
      monthly_hours: 10
      automation: "カナリアリリース自動化 + 自動ロールバック"
      target_monthly_hours: 1

    - task: "SSL証明書の更新"
      frequency: "四半期ごと"
      time_per_occurrence: "2時間"
      monthly_hours: 0.7
      automation: "cert-managerによる自動更新"
      target_monthly_hours: 0

    - task: "ログの手動調査レポート作成"
      frequency: "週2回"
      time_per_occurrence: "1時間"
      monthly_hours: 8
      automation: "Grafanaの定期レポート自動生成"
      target_monthly_hours: 1

    - task: "スケールアウト/インの手動調整"
      frequency: "月4回"
      time_per_occurrence: "15分"
      monthly_hours: 1
      automation: "HPAによるオートスケーリング"
      target_monthly_hours: 0

  summary:
    current_total: "約20時間/月"
    target_total: "約2時間/月"
    reduction: "90%削減"

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

## 基本情報
| 項目 | 内容 |
|------|------|
| 日時 | YYYY-MM-DD HH:MM - HH:MM |
| 重要度 | SEV1 / SEV2 / SEV3 |
| 影響時間 | XX分 |
| 影響ユーザー数 | XX人 |
| 作成者 | |
| レビュー日 | |

## サマリー（3行以内）

## タイムライン
| 時刻 | イベント | 担当 |
|------|---------|------|
| | | |

## 根本原因
（5 Whysで分析した結果を記述）

## 寄与要因
- 要因1
- 要因2

## 影響
- ユーザー影響:
- 売上影響:
- SLO影響:

## アクションアイテム
| ID | 内容 | 担当 | 優先度 | 期限 |
|----|------|------|--------|------|
| | | | | |

## 良かった点
- （うまく機能したこと）

## 学んだこと
- （今回の障害から得た教訓）

monthly_sre_report:
  sections:
    - title: "SLO達成状況"
      content:
        - "各SLOの現在値と目標値の比較"
        - "エラーバジェット残量の推移グラフ"
        - "前月比のトレンド"

    - title: "インシデントサマリー"
      content:
        - "今月のインシデント件数（重要度別）"
        - "平均検知時間（MTTD）"
        - "平均復旧時間（MTTR）"
        - "主要インシデントの概要"

    - title: "Toil削減進捗"
      content:
        - "Toil時間の推移"
        - "自動化プロジェクトの進捗"
        - "削減率"

    - title: "アクションアイテム追跡"
      content:
        - "過去のポストモーテムのAI完了状況"
        - "新規AI"
        - "期限超過のAI"

    - title: "カオス実験結果"
      content:
        - "今月実施した実験とその結果"
        - "発見された問題と対策"

    - title: "来月の計画"
      content:
        - "計画されているカオス実験"
        - "重点改善項目"