✍️ 필사 모드: SRE 実践ガイド 2025：インシデント管理、ポストモーテム、Error Budget、On-Call、Toil削減

SRE 核心原則：
1. 運用作業にソフトウェアエンジニアリングを適用
2. SLOで安定性目標を定量化
3. Error Budgetで革新と安定性のバランスを維持
4. Toilを減らして自動化に投資
5. モニタリングは症状ベースで、原因ベースではない
6. シンプルさを追求
7. ブレームレスポストモーテムで継続的に学習

DevOpsとSREの関係：

DevOps = 文化、哲学、価値観
  - 開発と運用の協業
  - 継続的インテグレーション/デリバリー
  - Infrastructure as Code
  - フィードバックループ

SRE = DevOpsの具体的実装
  - "class SRE implements DevOps"
  - 測定可能な目標（SLO/SLI）
  - Error Budgetという意思決定フレームワーク
  - エンジニアリングベースの運用アプローチ

両者は対立ではなく補完の関係：
DevOpsが「何を」なら、SREは「どのように」

SLA (Service Level Agreement)
= サービス提供者と顧客間の契約
= 違反時に金銭的/法的結果が伴う
例：「月間可用性99.9%保証、未達時サービスクレジット10%提供」

SLO (Service Level Objective)
= 内部目標
= SLAより厳格に設定（バッファを確保）
例：「月間可用性99.95%目標」（SLA 99.9%より厳格）

SLI (Service Level Indicator)
= 実際の測定値
= SLOを評価するためのメトリクス
例：「過去30日間の実際の可用性 99.97%」

サービスタイプ別SLIの例：

APIサービス：
- 可用性：成功リクエスト数 / 全リクエスト数
- レイテンシ：p99レスポンスタイム < 200msのリクエスト比率
- スループット：秒間処理可能リクエスト数

データパイプライン：
- 鮮度：N分以内に処理されたデータの割合
- 完全性：処理されたレコード数 / 期待レコード数
- 正確性：正しく処理されたレコードの割合

ストレージシステム：
- 耐久性：データ損失なく保存された割合
- 可用性：成功した読み取り/書き込みリクエストの割合
- レイテンシ：p50読み取りレイテンシ

SLO設定プロセス：

ステップ1：ユーザー視点から開始
  「ユーザーにとって最も重要なことは何か？」
  → ページロード時間、決済成功率、通知遅延

ステップ2：SLIの定義
  可用性SLI = 成功HTTPレスポンス(2xx, 3xx) / 全HTTPレスポンス
  レイテンシSLI = 200ms以内のレスポンスの割合

ステップ3：初期SLOの設定
  - 現在のパフォーマンスデータを分析（直近30日）
  - 現在のp50レベルを初期SLOとして設定
  - 高すぎる値に設定しないこと！

ステップ4：Error Budgetの計算
  SLO 99.9% → Error Budget = 0.1%
  月間：30日 x 24時間 x 60分 x 0.001 = 43.2分

ステップ5：反復改善
  - 4週間ごとにSLOレビュー
  - ユーザーフィードバックの反映
  - 必要に応じてSLOを調整

# Prometheus + Grafana SLOダッシュボード
# 可用性SLOクエリ
availability_slo:
  target: 99.9
  window: 30d
  query: |
    sum(rate(http_requests_total{status=~"2.."}[30d]))
    /
    sum(rate(http_requests_total[30d]))
    * 100

# レイテンシSLOクエリ
latency_slo:
  target: 99.0
  threshold: 200ms
  window: 30d
  query: |
    sum(rate(http_request_duration_seconds_bucket{le="0.2"}[30d]))
    /
    sum(rate(http_request_duration_seconds_count[30d]))
    * 100

Error Budget 計算：

SLO 99.9%（スリーナイン）：
  年間：365日 x 24時間 x 60分 x 0.001 = 525.6分（8時間45分）
  月間：30日 x 24時間 x 60分 x 0.001 = 43.2分
  週間：7日 x 24時間 x 60分 x 0.001 = 10.08分

SLO 99.95%（スリーアンドハーフナイン）：
  年間：262.8分（4時間23分）
  月間：21.6分
  週間：5.04分

SLO 99.99%（フォーナイン）：
  年間：52.56分
  月間：4.32分
  週間：1.01分

Error Budget ポリシー v2.0
最終更新：2025-04-14
承認：CTO、VP Engineering、SRE Director

1. 目的
   Error Budgetは安定性と革新の間のバランスを
   維持するための定量的フレームワークです。

2. 予算状態別の対応

   緑（予算50%以上残余）：
   - 通常の機能開発とデプロイ
   - カオス実験許可
   - 積極的なリリーススケジュール可能

   黄（予算20～50%残余）：
   - デプロイ速度を低減（週2回に制限）
   - 安定性改善作業の優先度を引き上げ
   - カオス実験はステージングのみ

   赤（予算20%未満）：
   - 安定性関連の変更のみデプロイ
   - 機能デプロイ凍結（Feature Freeze）
   - SREチームがデプロイのゲートキーパー
   - 根本原因分析と解決に集中

   消費済み（予算0%）：
   - すべての非必須デプロイを完全停止
   - インシデントレベルの対応
   - SRE/開発チーム合同安定性スプリント
   - 経営陣への報告と復旧計画策定

3. 例外事項
   - セキュリティパッチ：予算状態に関係なくデプロイ
   - 法的要件：予算状態に関係なくデプロイ
   - データ整合性の問題：即座に対応

重大度定義：

SEV1（クリティカル）：
  定義：コアサービスの全面障害、多数のユーザーに影響
  例：決済システム全体のダウン、データ漏洩
  対応：即座（5分以内）
  エスカレーション：VP + 全On-Callチーム
  コミュニケーション：15分ごとにステータス更新
  ポストモーテム：必須（48時間以内）

SEV2（高）：
  定義：主要機能の低下、相当数のユーザーに影響
  例：検索機能50%障害、APIレイテンシ10倍増加
  対応：15分以内
  エスカレーション：チームリード + On-Call
  コミュニケーション：30分ごとにステータス更新
  ポストモーテム：必須（1週間以内）

SEV3（中）：
  定義：部分的な機能低下、少数のユーザーに影響
  例：特定リージョンの画像ロード遅延
  対応：1時間以内
  エスカレーション：On-Callエンジニア
  ポストモーテム：任意（学習価値がある場合）

SEV4（低）：
  定義：軽微な問題、ユーザー影響最小
  例：内部ダッシュボードのロード遅延
  対応：翌営業日
  エスカレーション：該当チーム
  ポストモーテム：不要

インシデントライフサイクル：

1. 検出 (Detection)
   +-- 自動アラート（モニタリングシステム）
   +-- ユーザー報告（カスタマーサポート）
   +-- 内部発見（エンジニアが直接発見）
   |
   v
2. トリアージ (Triage)
   +-- 重大度判断（SEV1～4）
   +-- インシデントコマンダー指定
   +-- 対応チーム招集
   |
   v
3. 緩和 (Mitigation)
   +-- 即座に可能な緩和措置
   +-- ロールバック、スケールアップ、トラフィック転送
   +-- サービス復旧確認
   |
   v
4. 解決 (Resolution)
   +-- 根本原因の特定
   +-- 恒久的な修正のデプロイ
   +-- モニタリングで安定性確認
   |
   v
5. ポストモーテム (Postmortem)
   +-- タイムライン作成
   +-- 根本原因分析
   +-- アクションアイテム導出
   +-- 全社共有

インシデントコマンダーの責任：

1. 調整（Coordination）
   - 対応チームへの役割配分
   - 作業の優先順位決定
   - 重複作業の防止
   - 必要なリソースの確保

2. コミュニケーション（Communication）
   - 内部ステータス更新（Slackチャンネル）
   - 外部ステータス更新（ステータスページ）
   - 経営陣への報告
   - カスタマーサポートへのブリーフィング

3. 意思決定（Decision Making）
   - ロールバックの可否判断
   - エスカレーションの判断
   - リソース追加要請
   - インシデント終了宣言

4. 記録（Documentation）
   - 主要イベントのタイムスタンプ記録
   - 意思決定の理由を記録
   - ポストモーテムのための情報収集

ICコミュニケーションテンプレート：

"インシデントステータス更新 - [時間]
 重大度：SEV[N]
 状態：[調査中 / 緩和中 / モニタリング中]
 影響：[影響範囲の説明]
 現在の対応：[進行中の対応]
 次のステップ：[計画された次の対応]
 次の更新：[時間]"

インシデント対応ワークフローツール：

アラート：
- PagerDuty：On-Call管理とアラート
- OpsGenie：アラートルーティングとエスカレーション
- Grafana Alerting：メトリクスベースのアラート

コミュニケーション：
- Slack（専用インシデントチャンネル自動作成）
- Zoom/Google Meet（War Room）
- StatusPage（外部ステータスページ）

インシデント管理：
- Incident.io：Slack統合インシデント管理
- Rootly：自動化されたインシデントワークフロー
- Blameless：インシデント + ポストモーテムプラットフォーム
- FireHydrant：インシデント対応自動化

非難文化の問題点：

1. 情報の隠蔽
   「自分の間違いを報告すると罰せられる」
   → 本当の原因が隠される

2. 防御的な行動
   「自分の責任ではないことを証明しなければ」
   → システム改善より責任回避に集中

3. イノベーションの抑制
   「間違えてはいけないから変更を最小限に」
   → 必要な改善すらしなくなる

4. 信頼の破壊
   「同僚に非難されるかもしれない」
   → チーム協業の阻害

Blameless文化：
「人ではなくシステムを直そう」
- すべての人は正しいと思う行動をとった
- 障害はシステムの脆弱性を明らかにしたもの
- 間違いを共有することは安全である
- 根本原因は常にシステム/プロセスにある

ポストモーテム：[インシデントタイトル]
日付：YYYY-MM-DD
作成者：[名前]
レビュアー：[名前]

1. 概要
   [1～2文でインシデントを要約]

2. 影響
   - 期間：[開始] ～ [終了]（[N]分）
   - 影響を受けたユーザー：[数または割合]
   - 影響を受けたサービス：[サービスリスト]
   - 金銭的影響：[ある場合]

3. タイムライン（すべての時間はJST）
   14:23 - モニタリングアラート発生
   14:25 - On-Callエンジニアが確認
   14:28 - SEV2インシデント宣言、IC指定
   14:30 - インシデントチャンネル作成
   14:35 - 調査：DBコネクションプール枯渇を確認
   14:40 - 緩和措置：コネクションプールサイズ増加
   14:45 - サービス正常化を確認
   14:50 - モニタリング状態に移行
   15:15 - インシデント終了宣言

4. 根本原因
   [詳細な技術的説明]

5. 5 Whys 分析
   Why 1：なぜ決済が失敗したのか？
   → データベース接続を取得できなかったため

   Why 2：なぜ接続を取得できなかったのか？
   → コネクションプールが完全に枯渇していたため

   Why 3：なぜコネクションプールが枯渇したのか？
   → 遅いクエリが接続を長時間占有していたため

   Why 4：なぜ遅いクエリが発生したのか？
   → インデックスのないテーブルへのフルスキャン

   Why 5：なぜインデックスがなかったのか？
   → 新テーブル追加時のインデックスレビュープロセスがなかった

6. 良かった点
   - アラートが2分以内に発生
   - ICがチームを迅速に調整
   - 緩和措置が効果的だった

7. 改善すべき点
   - DBコネクションプールのモニタリング不足
   - 遅いクエリの検出アラートなし
   - 新テーブルのインデックスレビュープロセスが必要

8. アクションアイテム
   [HIGH] DBコネクションプール使用率アラートの追加
   担当：DBチーム | 期限：2025-04-21

   [HIGH] 新テーブル/クエリのインデックスレビューチェックリスト導入
   担当：バックエンドチーム | 期限：2025-04-28

   [MED] 遅いクエリ自動検出・アラートシステムの構築
   担当：SREチーム | 期限：2025-05-15

On-Callローテーション設計：

基本原則：
1. 最低2名が常にOn-Call（Primary + Secondary）
2. 1週間交代（月曜09:00開始）
3. 連続On-Call禁止（最低2週間の間隔）
4. 祝日はボランティアまたは追加報酬

ローテーション例（6名チーム）：
週1：Alice (P) + Bob (S)
週2：Charlie (P) + Diana (S)
週3：Eve (P) + Frank (S)
週4：Bob (P) + Alice (S)
週5：Diana (P) + Charlie (S)
週6：Frank (P) + Eve (S)

スワップルール：
- 最低48時間前の通知
- 自分で交代者を見つける責任
- チームリードにスワップを通知
- On-Callカレンダーの更新

エスカレーションポリシー：

Level 1：On-Call Primary（即座）
  → 5分以内に応答がなければ

Level 2：On-Call Secondary（5分）
  → 15分以内に解決しなければ

Level 3：チームリード（15分）
  → SEV1または30分以内に解決しなければ

Level 4：エンジニアリングマネージャー（30分）
  → SEV1が1時間以上続く場合

Level 5：VP/CTO（1時間）

自動エスカレーション設定（PagerDuty）：

escalation_policy:
  name: "payment-service"
  rules:
    - targets:
        - type: "user_reference"
          id: "PRIMARY_ON_CALL"
      escalation_delay_in_minutes: 5
    - targets:
        - type: "user_reference"
          id: "SECONDARY_ON_CALL"
      escalation_delay_in_minutes: 15
    - targets:
        - type: "user_reference"
          id: "TEAM_LEAD"
      escalation_delay_in_minutes: 30

On-Call疲労管理戦略：

1. アラート品質の改善
   問題：アラートが多すぎる → アラート疲労 → 本当の問題を見逃す
   解決策：
   - 週次アラートレビュー：不要なアラートを無効化
   - アラートの重複排除
   - アラートにコンテキストを追加
   - 目標：On-Call 1週間あたりアラート数 < 20回

2. ランブックの作成
   すべての繰り返しアラートに対するランブック作成
   ランブック構造：
   - 症状の説明
   - 影響範囲の確認方法
   - ステップバイステップの対応手順
   - エスカレーション基準
   - 関連ダッシュボードリンク

3. 報酬体系
   - On-Call手当（週あたりの固定金額）
   - 夜間/週末コール時の追加報酬
   - 代替休暇の提供
   - 長期On-Call時の特別報酬

4. メンタルヘルス
   - On-Call後のデブリーフィングセッション
   - 厳しいインシデント後のメンタルヘルスデー
   - On-Callでない日は完全に切り離す
   - チーム内でのOn-Call経験共有の文化

ランブック：payment-service 高エラー率

トリガー：payment-service HTTP 5xx率 > 1%

1. 状況把握
   - Grafanaダッシュボード確認：[ダッシュボードURL]
   - エラーログ確認：
     kubectl logs -l app=payment-service --tail=100 -n production
   - 最近のデプロイ確認：
     kubectl rollout history deployment/payment-service -n production

2. 一般的な原因

   原因A：データベース接続の問題
   確認：コネクションプールメトリクスの確認
   対処：コネクションプールのリセットまたは拡張
   コマンド：
     kubectl rollout restart deployment/payment-service -n production

   原因B：外部API障害
   確認：外部APIステータスページの確認
   対処：Circuit breakerの強制オープン
   コマンド：
     curl -X POST http://payment-service/admin/circuit-breaker/open

   原因C：最近のデプロイの問題
   確認：デプロイタイムラインとエラー開始時間の比較
   対処：以前のバージョンにロールバック
   コマンド：
     kubectl rollout undo deployment/payment-service -n production

3. エスカレーション
   - 15分以内に解決しない場合：チームリードにエスカレーション
   - SEV1と判断された場合：インシデント宣言

Toilの特性：

1. 手動的（Manual）
   人が直接実行する必要がある作業
   例：手動でのサーバー再起動

2. 繰り返し的（Repetitive）
   同じ作業を繰り返し実行
   例：毎週の証明書更新

3. 自動化可能（Automatable）
   機械が代わりにできる作業
   例：ディスククリーンアップスクリプトの実行

4. 戦術的（Tactical）
   長期的な価値のない即座の対応
   例：一時的な回避策の適用

5. サービス成長に比例（Scales with Service）
   サービスが大きくなるほど作業量が増加
   例：手動ユーザープロビジョニング

6. 持続的な価値がない（No Enduring Value）
   作業後にサービスが改善されない
   例：手動デプロイ承認

Toil測定方法：

1. 時間追跡
   - 2週間すべての業務時間を記録
   - Toil vs エンジニアリング時間を分類
   - 目標：Toil < 50%

2. Toilカテゴリ：
   カテゴリA：インシデント対応（緊急）
   カテゴリB：定期運用作業（予定済み）
   カテゴリC：手動プロビジョニング（リクエストベース）
   カテゴリD：手動モニタリング/検証（確認）

3. 測定テンプレート：

   チーム：SREチーム
   期間：2025-04-01 ～ 2025-04-14

   | 作業 | 頻度 | 所要時間 | Toil? | 自動化可能？ |
   |------|------|----------|-------|-------------|
   | 証明書更新 | 週1回 | 30分 | Yes | Yes |
   | ディスククリーンアップ | 日1回 | 15分 | Yes | Yes |
   | デプロイ承認 | 日3回 | 各10分 | Yes | Yes |
   | キャパシティレビュー | 週1回 | 2時間 | 部分的 | 部分的 |
   | インシデント対応 | 週2回 | 各1時間 | No | No |

   総時間：80時間（2週間）
   Toil時間：45時間（56%）
   目標：40時間以下（50%）

自動化優先順位マトリクス：

            高頻度          低頻度
高影響  | P1：即座に    | P2：計画的に |
        | 自動化        | 自動化       |
        |---------------|-------------|
低影響  | P3：バック    | P4：無視     |
        | ログに追加    | 可能         |

P1自動化の例：
- 証明書の自動更新（cert-manager）
- ディスクの自動クリーンアップ（cron job）
- デプロイの自動承認（CI/CDパイプライン）
- オートスケーリング（HPA/VPA）

# cert-managerによる証明書自動更新
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-service-tls
  namespace: production
spec:
  secretName: my-service-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com
    - www.example.com
  renewBefore: 720h  # 期限30日前に自動更新

# ディスククリーンアップ自動化 CronJob
apiVersion: batch/v1
kind: CronJob
metadata:
  name: disk-cleanup
  namespace: production
spec:
  schedule: "0 3 * * *"  # 毎日午前3時
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: cleanup
              image: busybox:1.36
              command:
                - /bin/sh
                - -c
                - |
                  find /data/logs -mtime +7 -delete
                  find /data/tmp -mtime +1 -delete
          restartPolicy: OnFailure

# HPAオートスケーリング
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payment-service-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

キャパシティプランニングフレームワーク：

1. 現在のキャパシティ把握
   - CPU：クラスタ全体の60%使用中
   - メモリ：クラスタ全体の55%使用中
   - ストレージ：月100GB増加
   - ネットワーク：ピーク時帯域幅の40%使用

2. 成長率分析
   - 過去12ヶ月のトラフィック増加率：月15%
   - 季節性パターン：ブラックフライデー3倍、正月2倍

3. バッファの確保
   - 一般的なバッファ：30～50%
   - N+1原則：ノード1台の障害時でもサービス維持
   - ピーク対応：通常トラフィックの3倍処理可能

# Argo Rollouts カナリアデプロイ
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
  namespace: production
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: payment-service-canary
      stableService: payment-service-stable
      trafficRouting:
        istio:
          virtualService:
            name: payment-service-vs
      steps:
        - setWeight: 5
        - pause:
            duration: 10m
        - setWeight: 20
        - pause:
            duration: 10m
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 50
        - pause:
            duration: 15m
        - setWeight: 100

Feature Flagデプロイ戦略：

フェーズ1：社内スタッフのみ（dogfooding）
   percentage: 0, whitelist: [社内スタッフID一覧]

フェーズ2：1%ロールアウト
   percentage: 1

フェーズ3：10%ロールアウト
   percentage: 10

フェーズ4：50%ロールアウト
   percentage: 50

フェーズ5：全体ロールアウト
   percentage: 100

各フェーズで：
- エラー率のモニタリング
- ユーザーフィードバックの収集
- ビジネスメトリクスの確認
- 問題発見時は即座に無効化

教訓1：100%可用性は間違った目標
  → 完璧なシステムは存在しない
  → 適切なレベルの安定性をSLOで定義せよ

教訓2：Error Budgetがイノベーションを可能にする
  → 予算があればリスクを取れる
  → 予算がなければ安定性に集中すべき

教訓3：Toilが50%を超えたら危険信号
  → SREの時間の50%以上がToilなら
  → 自動化に投資するかチームを拡大すべき

教訓4：モニタリングは症状ベースであるべき
  → 「CPUが90%」（原因）vs「レスポンスが遅い」（症状）
  → ユーザーが経験する症状をモニタリングせよ

教訓5：ポストモーテムはブレームレスで行え
  → 人ではなくシステムを直そう
  → 間違いを共有することが安全な文化を作れ

教訓6：シンプルさが安定性
  → 複雑なシステムは予測不可能に壊れる
  → 可能な限りシンプルに保て

教訓7：リリースエンジニアリングは安定性の核心
  → カナリアデプロイ、Feature Flag、自動ロールバック

教訓8：キャパシティプランニングは事前に
  → トラフィックが増加する前に準備せよ

教訓9：On-Callは持続可能でなければならない
  → アラート疲労を減らせ
  → 適切な報酬と休息を提供せよ

教訓10：SREは組織全体の責任
  → SREチームだけの仕事ではない
  → 開発チームも安定性の責任を負うべき

SREチームモデル：

1. 中央集中型モデル（Centralized）
   特徴：1つのSREチームが全サービスを担当
   利点：一貫した実践、知識共有が容易
   欠点：ボトルネック、サービス別の深さ不足
   適合：小規模組織（サービス10個未満）

2. 組み込みモデル（Embedded）
   特徴：SREが開発チームに内蔵
   利点：サービスの深い理解、素早い対応
   欠点：一貫性の不足、SRE孤立のリスク
   適合：大規模組織（サービス50個以上）

3. ハイブリッドモデル（Hybrid）
   特徴：中央SREチーム + 各チームSREチャンピオン
   利点：一貫性と深さのバランス
   欠点：調整コスト
   適合：中規模組織（サービス10～50個）

4. コンサルティングモデル（Consulting）
   特徴：SREが必要な時だけ介入
   利点：スケーラブル、コスト効率的
   欠点：継続的な関与の不足
   適合：SRE初期導入組織

理想的なSRE時間配分：

エンジニアリング作業：50%以上
  - 自動化開発
  - ツール改善
  - システム設計
  - コードレビュー

運用作業（Toil）：50%以下
  - On-Call対応
  - デプロイ管理
  - 手動プロビジョニング
  - 手動モニタリング

警告信号：
- Toil > 50%：自動化投資が必要
- Toil > 70%：チーム拡大またはサービス再設計が必要
- Toil > 90%：危機 - 即座の経営陣介入が必要