🎯 SRE プラクティス徹底深掘り

📚 参照する公式ドキュメント

本資料は以下の Google SRE Book / Workbook / Google Cloud 公式ドキュメント（2026 年時点）から技術詳細・計算式・SLA・ベストプラクティスを抽出しています。各章で都度引用と URL を併記します。

1SRE の哲学と DevOps

SRE（Site Reliability Engineering）は Ben Treynor（Google VP）が 2003 年に提唱した、ソフトウェアエンジニアリングの手法で運用問題を解く規律です。DevOps が「WHAT（理念）」なら、SRE は「HOW（具体的実装）」。試験では「SRE と DevOps の関係」「Toil 50% ルール」「Four Golden Signals」「Postmortem の Blameless 原則」「DORA 4 metrics」が頻出です。

「SRE is what happens when you ask a software engineer to design an operations team.」 — Ben Treynor Sloss, Google VP of Engineering

1.1 「class SRE implements DevOps」の正確な意味

DevOps の 5 つの原則に対し、SRE は 具体的な実装手段を提供します。「class」「implements」というプログラミング用語の比喩は、DevOps を interface、SRE を concrete class として捉えるという意味です。

1.2 Google SRE Book と SRE Workbook の違い

1.3 Toil（労苦）の定義と 50% ルール

Toil = SRE が削減すべき「無価値で反復的な手作業」。SRE Book Ch.5 が定義する 5 つの特徴のすべてを満たすものが Toil。1 つでも欠ければ Toil ではない（例：「自動化困難な調査作業」は反復的だが automatable ではないので Toil ではなく Overhead）。

SRE 1 人あたり Toil ≤ 50% × 1 週間の労働時間
       = 50% × 40h = 20h / 週

残り 50% (= 20h / 週) は engineering work
  ├ 信頼性改善コード
  ├ 自動化（runbook → script → workflow）
  ├ Postmortem の Action Items 実装
  └ アーキテクチャ改善

→ Toil > 50% が継続したら：
   1. オンコール rotation 拡大、
   2. プロジェクトを開発チームに pushback、
   3. SRE 増員、
   4. Toil 削減プロジェクト起票

1.4 Postmortem 文化 — Blameless が大前提

「The cost of failure is education.」 — SRE Book Ch.15 Postmortem Culture

Blameless Postmortem = 「誰が」ではなく「何が」「なぜ」を問う事後分析。個人攻撃を排除することで、本当の事実が表に出る。Postmortem が punitive（懲罰的）になると、エンジニアはミスを隠し、根本原因が永遠に見つからない。

Postmortem の Trigger（いつ書くか）

Five Whys の例

障害: 決済 API が 23 分間 503 を返した
Why 1: Pod が OOM Killed され続けた
Why 2: メモリ要求 (256Mi) に対し実使用が 2Gi に達した
Why 3: 新リリースで請求書 PDF を全件 in-memory ロードに変更された
Why 4: コードレビューでメモリ影響が見落とされた
Why 5: メモリ profiling が CI に組み込まれていなかった
→ Action Item:
   - [P0] Cloud Profiler を本番常時有効化（担当: SRE A, 期限: 2 週間）
   - [P1] PR テンプレートに「メモリ影響」項目追加（担当: Dev Lead, 期限: 1 週間）
   - [P1] VPA recommender を有効化して memory request の自動調整（担当: SRE B, 期限: 1 ヶ月）

1.5 The Four Golden Signals — 最小監視セット

Google SRE Book Ch.6 が示す、ユーザー向けシステムを監視する最小 4 シグナル。「これだけは必ず計測しろ」というベースライン。試験で「ユーザー影響を反映する最小監視セット」と問われたら即答 = Four Golden Signals。

1.6 DORA 4 metrics — 高成果チームのベンチマーク

Google Cloud 配下の DORA（DevOps Research and Assessment）が毎年公開する State of DevOps Report の中核指標。試験では「DORA」というキーワード単体でも問われる。CI/CD と SRE の橋渡し指標。

2023 年版から、5 つ目の指標として「Reliability」（SLO 達成率、または運用上の信頼性）が追加された。これにより DORA は「速度（DF/LT）」「品質（CFR/MTTR）」「信頼性（SLO）」の 3 軸を測る完全体に。

1.7 SVG ダイアグラム — SRE 組織モデル

2SLI / SLO / SLA 数学的定義

「SLI / SLO / SLA を 1 分で説明せよ」は SRE 試験のスタート地点。正しい数式と桁ごとのダウンタイム数値を暗記すれば、応用問題は機械的に解ける。逆にここがブレるとすべての問題で迷う。

2.1 正確な定義式

SLI (Service Level Indicator)
  = good_events / valid_events           ← リクエストベース
  または
  = good_windows / total_windows         ← ウィンドウベース

SLO (Service Level Objective)
  = SLI に対する内部目標値（target）
  例：SLI ≥ 99.9% を 30 日間 rolling で維持

SLA (Service Level Agreement)
  = 顧客との契約値 + 違反時のペナルティ（返金 etc）
  通常: SLA < SLO（バッファを取る）

Error Budget
  = 1 − SLO
  例：SLO 99.9% → Error Budget = 0.1% = 月 43.2 分

Burn Rate
  = 実際のエラー率 / (1 − SLO)
  例：実エラー率 1.44% / 0.1% = 14.4x（=  Fast burn）

2.2 SLI / SLO / SLA の数値関係（覚え方）

「文字並びは SLI < SLO < SLA だが、数値の大小は SLA < SLO < SLI」 という逆転関係を必ず把握する。

SLA  99.9%   ←  顧客契約（最も低い保証）  下回ったら返金
SLO  99.95%  ←  内部目標（バッファあり）    下回ったら信頼性投資
SLI  99.98%  ←  実測値（実際の運用）       現状

[なぜこの順？]
  - SLA は契約 → 絶対下回ってはいけない → 余裕を持って低く
  - SLO は SLA を絶対下回らないための内部ライン → SLA より高く
  - SLI は理想的にはずっと SLO 以上 → 実測が一番高くなるよう運用

2.3 リクエストベース SLI vs ウィンドウベース SLI

SLI = good_requests / valid_requests

例：直近 28 日の HTTP 成功率
  good   = HTTP 2xx + 3xx + 4xx(client error は除外可)
  valid  = 全 HTTP requests
  → SLI = good / valid

SLI = good_windows / total_windows

例：1 分ウィンドウで「成功率 99% 以上」が good
  ウィンドウサイズ = 1 分
  good = 「1 分内の成功率 ≥ 99%」のウィンドウ数
  → SLI = good / 全ウィンドウ数

2.4 良い SLI の 4 条件（SRE Workbook Ch.2）

2.5 SLI 設計のアンチパターン

2.6 桁ごとのダウンタイム数値表（必須暗記）

SRE 試験で最も頻出のテーブル。「SLO 99.9% で月どれだけ落ちて良いか」を即答できないと話にならない。

2.7 SLO 達成のコスト関数（指数的に増加）

「ユーザーが気づかない高信頼性は過剰投資」。たとえば社内管理ツールに 99.999% は無駄。逆に決済 / 医療 / 通信は 99.99% でも足りない。「ユーザーが本当に求める信頼性」を調査して決める。

2.8 SLO の Compliance Period（カレンダー vs ローリング）

「Cloud Monitoring supports compliance periods of calendar week, calendar month, or rolling 1〜30 days.」 — Cloud Monitoring create SLO

2.9 事故ケース集（SLI / SLO 設計）

3Error Budget 完全理解

Error Budget は SRE の最重要発明。「リリース速度」と「信頼性」のトレードオフを数値で議論可能にする。試験では Burn Rate の計算式、Multi-window Multi-burn-rate の 3 段、Error Budget Policy の発動条件がほぼ必ず問われる。

3.1 Error Budget の数式と意味

Error Budget = 1 − SLO

例：SLO 99.9% (rolling 30 days)
  Error Budget = 0.1%
              = 30 days × 24h × 60min × 0.001
              = 43.2 分（時間ベース）
  または
              = total_requests × 0.001（リクエストベース）

例：SLO 99.99%、月 100 万 req
  許容 bad req = 1,000,000 × 0.0001 = 100 req / 月

意味：
  「43 分（または 100 req）までは failure してよい」
  → リリース・実験のリスクテイク予算
  → ゼロ消費を目指すのではなく、計画的に使う

Error Budget は「消費を悪と考えない」のが鉄則。Error Budget が余っているのにリリースしないのは機会損失。新機能リリースには必ず信頼性リスクがあるため、Error Budget の範囲内ならリスクを取って早く出すべき。

3.2 Burn Rate の計算式

Burn Rate = 観測期間の実エラー率 / (1 − SLO)

例：SLO 99.9% (Error Budget = 0.1%)
  観測期間 1 時間で実エラー率 1.44%
  Burn Rate = 1.44% / 0.1% = 14.4x

意味：
  Burn Rate 1x   = SLO 期間全体（30 日）で予算をちょうど使い切るペース
  Burn Rate 2x   = 15 日で使い切る
  Burn Rate 14.4x = 約 50 時間で使い切る（30d / 14.4）
  Burn Rate 6x   = 5 日で使い切る
  Burn Rate 60x  = 12 時間で使い切る

Burn Rate ↔ 予算消費率 ↔ 残時間の早見表（SLO 30 日）

3.3 Multi-window Multi-burn-rate Alerting（SRE Workbook Ch.5）

SRE Workbook Ch.5 の推奨アラート設計。1 つのウィンドウだけだと「短期スパイクで誤検知（false positive）」または「長期で見落とし（false negative）」が起きるため、複数ウィンドウを AND で組み合わせる。

「For example, an alert configured for a 1-hour window with a 14.4 burn rate fires when 2% of the budget is consumed in 1 hour.」 — SRE Workbook Ch.5 Table 5-8

SRE Workbook 推奨：99.9% SLO の 3 段アラート

判定ロジック（疑似コード）

def should_alert_fast_burn(slo, errors, window_long='1h', window_short='5m'):
    burn_long  = error_rate(window_long)  / (1 - slo)
    burn_short = error_rate(window_short) / (1 - slo)
    # AND 条件：両方 14.4x を超えた時のみ発火
    return burn_long > 14.4 and burn_short > 14.4

# 効果：
#  - long のみだと 5 分で復旧した spike も 1 時間後まで発火継続
#  - short のみだと 30 秒の一時 burst でも発火 → false positive
#  - AND にすることで「長期傾向 AND 現在も継続」のみ通知

Burn Rate Alert の SVG ロジック図

3.4 数値計算例：実際にアラートが発火するか

ケース B・C が重要。「片方だけ高くても発火しない」のが Multi-window の本質。B はかつての大障害が収束したケース（過去 1h に蓄積したが現在は OK）、C は瞬間 burst（5m だけ悪化、1h で見ると無視できる）。

3.5 Error Budget Policy（消費レベル別対応）

Error Budget Policy = 「予算残量に応じた事前合意ルール」。障害時に「リリースして良いか」を感情で議論しないために、平時に合意しておく。Dev / SRE / プロダクトオーナー が署名する。

3.6 Cloud Monitoring SLO の作成手順

Cloud Monitoring の Service Monitoring 機能で、コンソール / API / IaC で SLO を作成。Burn Rate Alert は自動生成可能。

Service Monitoring API 定義例

# SLO 定義（Cloud Monitoring API）
displayName: "Checkout API availability"
serviceLevelIndicator:
  requestBased:
    goodTotalRatio:
      goodServiceFilter: |
        metric.type="loadbalancing.googleapis.com/https/request_count"
        AND metric.label.response_code_class="2xx"
        AND resource.label.url_map_name="checkout-lb"
      totalServiceFilter: |
        metric.type="loadbalancing.googleapis.com/https/request_count"
        AND resource.label.url_map_name="checkout-lb"
goal: 0.999                    # SLO 99.9%
rollingPeriod: 2419200s        # 28 日 (rolling)
# またはカレンダーアライン
# calendarPeriod: MONTH

---
# Burn Rate Alert（Fast Burn）
displayName: "Checkout SLO Fast Burn"
conditions:
- displayName: "Fast burn over 1h AND 5min"
  conditionThreshold:
    filter: |
      select_slo_burn_rate("projects/PRJ/services/checkout/serviceLevelObjectives/avail", "3600s")
    comparison: COMPARISON_GT
    thresholdValue: 14.4
    duration: 300s             # 5min 継続でトリガ
notificationChannels:
  - "projects/PRJ/notificationChannels/pagerduty-prod"

3.7 事故ケース集（Error Budget / Burn rate）

4Cloud Service Mesh の SRE 機能

Cloud Service Mesh（旧 Anthos Service Mesh / ASM）は、Istio をベースにした Google Cloud マネージドサービスメッシュ。アプリ無改修で SLO 計測・mTLS・トラフィック制御を実現。試験では「アプリに手を入れずに SLI 収集」「マイクロサービス間の相互認証」が問われたら、ほぼ Cloud Service Mesh が正解。

「Cloud Service Mesh supports two SLI types: latency and availability, set and monitored on the Health page using service telemetry.」 — Cloud Service Mesh SLO Overview

4.1 アーキテクチャ（Istio Control Plane + Envoy Sidecar）

4.2 主要メトリクスと SLO 定義（PromQL）

Availability SLI（PromQL）

# 成功リクエスト / 全リクエスト（destination 側から見た）
sum(rate(istio_requests_total{
  destination_service="checkout.prod.svc.cluster.local",
  response_code!~"5..",
  reporter="destination"
}[5m]))
/
sum(rate(istio_requests_total{
  destination_service="checkout.prod.svc.cluster.local",
  reporter="destination"
}[5m]))

Latency SLI（PromQL）

# p99 レイテンシ
histogram_quantile(0.99,
  sum(rate(istio_request_duration_milliseconds_bucket{
    destination_service="checkout.prod.svc.cluster.local"
  }[5m])) by (le)
)

# あるいは「p99 ≤ 500ms の割合」を SLI に
sum(rate(istio_request_duration_milliseconds_bucket{
  destination_service="checkout.prod.svc.cluster.local",
  le="500"
}[5m]))
/
sum(rate(istio_request_duration_milliseconds_count{
  destination_service="checkout.prod.svc.cluster.local"
}[5m]))

4.3 SLO 定義例（Cloud Service Mesh コンソール / API）

# Cloud Console → Cloud Service Mesh → Services → SLO 作成
displayName: "Checkout latency p99 ≤ 500ms"
serviceLevelIndicator:
  basicSli:
    latency:
      threshold: 0.5s
    method: ["GET", "POST"]
    location: ["asia-northeast1"]
goal: 0.999
rollingPeriod: 2419200s

# Availability SLO
displayName: "Checkout availability"
serviceLevelIndicator:
  basicSli:
    availability: {}    # 自動で 2xx-3xx を good 扱い
goal: 0.9995
calendarPeriod: MONTH

4.4 mTLS / 認可ポリシー / トラフィック制御

mTLS STRICT 設定例

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT          # mesh 内通信は必ず mTLS、平文拒否

---
# 段階移行は PERMISSIVE → STRICT（legacy app を含む場合）
spec:
  mtls:
    mode: PERMISSIVE      # mTLS と平文の両方を受け付け

Canary トラフィック分割（VirtualService）

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: checkout
spec:
  hosts: [checkout.prod.svc.cluster.local]
  http:
  - route:
    - destination:
        host: checkout
        subset: v1            # 安定版
      weight: 90              # 90%
    - destination:
        host: checkout
        subset: v2            # 新版（canary）
      weight: 10              # 10%

4.5 Managed Cloud Service Mesh vs OSS Istio（インクラスタ）

4.6 事故ケース集（Cloud Service Mesh）

5オートスケール完全攻略

Google Cloud のオートスケーリングは MIG（VM）／ Cloud Run（サーバーレス）／ GKE（HPA + VPA + CA + NAP）の 3 プロダクトファミリ。試験では「適切な autoscaling 方式の選択」「HPA と VPA の併用禁止」「PDB 設定漏れ」「min-instances の使い分け」が頻出。

5.1 Managed Instance Group（MIG）— VM の自動スケール

MIG Autoscaling Policy の 5 種類

MIG 設定例（CPU + Custom metric）

gcloud compute instance-groups managed set-autoscaling app-mig \
  --zone=asia-northeast1-a \
  --min-num-replicas=3 \
  --max-num-replicas=50 \
  --target-cpu-utilization=0.6 \
  --custom-metric-utilization=metric=custom.googleapis.com/queue_length,utilization-target=100,utilization-target-type=GAUGE \
  --cool-down-period=90 \
  --mode=ON           # OFF / ONLY_SCALE_OUT で逆 scale 防止可

Predictive Autoscaling

過去 7-21 日のメトリクスパターンから「今後 N 分後の負荷」を予測し、事前にスケールアップする。起動時間が長い VM（Java / .NET / 大きな AMI）に有効。reactive scaling より遅延なくピークに対応できる。

--cpu-utilization-predictive-method=OPTIMIZE_AVAILABILITY
# またはコンソールで「Predictive autoscaling」ON

Stateful MIG

通常 MIG はステートレス（VM 置換自由）。Stateful MIG は VM 単位で disk・metadata を保持。自己ホスト DB（Cassandra、Elasticsearch）、stateful レガシーアプリで使う。

5.2 Cloud Run — サーバーレスの自動スケール

主要パラメータと推奨値

Cold Start を潰す 5 つのテクニック

1. min-instances ≥ 1：最も即効。常時 1 インスタンス温存（cold start 発生回数を激減）
2. Startup CPU Boost：gen2 で起動時 CPU を一時的に最大化（Java / Spring Boot で 30-50% 短縮）
3. 軽量ランタイム選択：Go / Python / Node.js は起動 100-500ms、Java は 5-15s
4. Lazy initialization：起動時の重い処理を最初のリクエスト後に delay（ただし最初のリクエストは遅い）
5. Container size 最小化：マルチステージビルド、distroless image、layer cache 最適化

min-instances = 1 で 24/7 常駐
  → 月 720h × (1 vCPU + 512Mi) = 月 $35-50 程度
  → cold start 回避できる代わりに、ピーク外でも常時課金

min-instances = 0
  → リクエストゼロ時は完全停止、コスト最小
  → cold start で p99 が +2-10 秒

判断軸：
  - ユーザー対面で latency SLO 厳しい → min-instances ≥ 1
  - 内部 API、バッチ起動 → min-instances = 0 で OK

CPU always allocated の判断軸

5.3 GKE Horizontal Pod Autoscaler（HPA）

HPA の Metric Types

HPA v2 の高度な behavior 設定

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: app }
spec:
  scaleTargetRef: { kind: Deployment, name: app }
  minReplicas: 3
  maxReplicas: 100
  metrics:
  - type: Resource
    resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300   # 5 分待って収まりを確認してから縮小
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60               # 1 分で 10% ずつ縮小
    scaleUp:
      stabilizationWindowSeconds: 0     # 即座に拡大
      policies:
      - type: Percent
        value: 100
        periodSeconds: 30               # 30s で倍増
      - type: Pods
        value: 4
        periodSeconds: 30               # または 30s で 4 Pod 増
      selectPolicy: Max                 # 両 policy の最大を選択

5.4 GKE Vertical Pod Autoscaler（VPA）

VPA はPod の CPU / Memory の requestを実使用量に基づき自動調整。Pod を再作成する。

VPA の Update Mode

5.5 GKE Cluster Autoscaler（CA）

CA の profile（GKE 特有）

CA の scale-down 判定条件

1. ノードのリソース使用率が 50% 以下（profile で変動）
2. そのノードの全 Pod が他ノードに移動可能
3. 10 分間 underutilized 継続（連続観測）
4. PDB（Pod Disruption Budget）を尊重できる
5. 削除禁止 annotation（cluster-autoscaler.kubernetes.io/safe-to-evict=false）がない
6. kube-system Pod に制約がない（CoreDNS、metrics-server 等）
7. local storage を使う Pod がない

Node Auto-Provisioning（NAP）

CA を超えて、Node Pool 自体を自動生成。Pending Pod の要求（CPU/Memory/GPU/特殊ハード）を読み、最適な machine type の Node Pool を新規作成。不要になれば削除。

gcloud container clusters update my-cluster \
  --enable-autoprovisioning \
  --min-cpu=10 --max-cpu=1000 \
  --min-memory=40 --max-memory=4000 \
  --autoprovisioning-scopes=https://www.googleapis.com/auth/cloud-platform \
  --autoprovisioning-service-account=nap-sa@PRJ.iam.gserviceaccount.com

5.6 HPA + VPA + CA + NAP 同時利用のベストプラクティス

5.7 PDB（Pod Disruption Budget）— CA を機能させる鍵

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: app-pdb, namespace: production }
spec:
  minAvailable: 2          # 最低 2 Pod を常時保つ
  # または: maxUnavailable: 1
  selector:
    matchLabels: { app: my-app }

PDB は「voluntary disruption」（CA scale-down、ノードアップグレード、kubectl drain）に対する保証。involuntary（ノード障害、OOM）には効かない。CA が PDB を満たせない場合、scale-down は停止する → ノードが減らず、コスト増。

5.8 Pause Pod パターン（バースト対応）

低優先度の pause Pod を意図的に配置 → クラスタに「空き容量を持つように見せる」 → 本物の Pod が来たら pause Pod を退避、CA が即時に新ノード追加。cold start を回避する高度なパターン。

5.9 事故ケース集（オートスケール）

6キャパシティプランニング

容量計画 = 「必要なリソース量を予測し、適切なタイミングで確保する」工学。試験では Quotas vs Limits の違い、Reservations の種類、Dynamic Workload Scheduler（DWS）、Little's Law と Erlang C の基礎が問われる。

6.1 Quotas vs Limits の違い

Quota 引き上げ申請のタイミング

6.2 Reservations（容量予約）

Compute Engine の VM 容量を事前に確保。起動時に「Stockout（在庫不足）」エラーを防ぐ。CUD（Committed Use Discount）と組み合わせて割引も可能。

CUD（Committed Use Discount）との組み合わせ

6.3 Dynamic Workload Scheduler（DWS）— GPU/TPU 専用

AI/ML ワークロードのための柔軟な容量確保サービス。希少な GPU（A100/H100）/ TPU を効率的に確保。

6.4 容量計画の数学（待ち行列理論の基礎）

Little's Law（リトルの法則）

L = λ × W

L : システム内の平均リクエスト数 (concurrent requests)
λ : リクエスト到着率 (RPS)
W : 平均応答時間 (秒)

例：
  RPS = 1000、平均レイテンシ 200ms (0.2s)
  L = 1000 × 0.2 = 200 concurrent requests

→ Cloud Run concurrency = 80 の場合、必要 instances = 200/80 = 3 (最低)
→ Pod 数 = 200 (concurrency=1 のとき)

Little's Law は「Cloud Run の min-instances」「Pod 数」「DB connection pool」を計算するときの基礎。p99 レイテンシを使えば「99% のリクエストを捌くのに必要な容量」も導ける。

Erlang C — トラフィック理論ベースの容量計算

コールセンター / 待ち行列での 「N 個のサーバで、Q% 以内に応答するのに必要な台数」を計算。Webサーバの容量計算にも応用可。GKE / MIG の min replica 計算に内部的に使われる。詳細は試験では不要、「Erlang C は容量計算の理論」程度で OK。

6.5 季節性のあるトラフィック予測

6.6 RTO / RPO と DR スケナリオ

「RTO is the maximum acceptable length of time that your application can be offline. RPO is the maximum acceptable length of time during which data might be lost.」 — DR Planning Guide

7インシデント対応の体系

SRE Workbook Ch.9 が体系化した Incident Command System（ICS）と、Mitigate first 原則がインシデント対応の核心。試験では「障害時に最初にやること」「IC の責務」「最速の止血手段」が頻出。

7.1 鉄則：影響緩和 → 容量追加 → ロールバック → 原因究明

優先順位（必ずこの順で考える）：

1. Mitigate（影響緩和）       ← 最優先・最速
   - Feature Flag OFF（秒単位で復旧）
   - Cloud DNS で別 region へ traffic 切替
   - LB connection draining
2. Add Capacity（容量追加）
   - HPA / max-instances 引き上げ
   - Reservations 投入
3. Rollback（ロールバック）
   - Cloud Deploy rollout rollback
   - Cloud Run revision traffic 100% 旧版
4. Root Cause Analysis（原因究明）  ← 後でよい
   - Postmortem で詳細分析

→ 「先に原因を突き止めよう」とすると、その間ユーザー影響継続
→ まず止血、診断は復旧後

7.2 Incident Command System（ICS）

米国の災害対応で使われる ICS を SRE に転用。役割を明確に分離することで、混乱の中でも判断を継続できる。大規模障害では役割分離が必須、小規模は兼任 OK。

役割の責務（試験頻出）

7.3 インシデントレベル（Severity）

7.4 影響緩和テクニック

GLB Connection Draining

HTTP(S) Load Balancer のバックエンドを安全に削除するための機能。新規 traffic を止めつつ既存接続を完了まで待つ。最大 3600 秒（60 分）。

# 1. capacity-scaler を 0 にして新規トラフィック停止
gcloud compute backend-services update-backend my-bs \
  --instance-group=my-mig --instance-group-zone=asia-northeast1-a \
  --capacity-scaler=0

# 2. connection draining timeout を設定（既存接続を待つ）
gcloud compute backend-services update my-bs \
  --connection-draining-timeout=600  # 10 分

# 3. drain 完了を待ってから backend 削除
gcloud compute backend-services remove-backend my-bs \
  --instance-group=my-mig --instance-group-zone=asia-northeast1-a

Cloud DNS Weighted Routing / Failover Routing

DNS レベルで traffic を別 region に切替。weight を変更するだけ → TTL 内でクライアントに伝播。TTL を短く設定（60-300 秒）しておくのが運用の鍵。

# weighted routing（90/10 → 0/100 で即時切替）
gcloud dns record-sets create api.example.com. \
  --type=A --ttl=60 --zone=my-zone \
  --routing-policy-type=WRR \
  --routing-policy-data="90=1.1.1.1;10=2.2.2.2"

# 障害時：weight を 0/100 に変更
gcloud dns record-sets update api.example.com. \
  --routing-policy-data="0=1.1.1.1;100=2.2.2.2"

Multi-cluster Ingress（MCI）でリージョン切替

複数 GKE クラスタを 1 つの Anycast Global LB で公開。リージョン障害時に自動切替。Cloud DNS よりも切替が速い（DNS TTL 不要）。

Feature Flag による即時無効化

最速の止血手段。コードはデプロイしたまま、新機能だけを秒単位で無効化。試験で「最も早く影響を止める」と問われたらFeature Flag OFF。

7.5 ロールバック戦略の選択肢

7.6 Postmortem テンプレート

# Postmortem: [障害タイトル]

## Status
Draft / Review / Final

## Date
2026-03-15

## Authors
[Names]

## Executive Summary（経営層向け 3 行）
- 何が起きたか
- ユーザー影響
- 再発防止策

## Impact
- 影響ユーザー数: ~50,000 (全体の 12%)
- 失敗 transactions: 8,400 ($120k 損失)
- SLO 消費: 月予算の 65%
- Sev: 2

## Timeline (UTC)
2026-03-15 09:15 - Deploy 開始 (v2.4.1)
2026-03-15 09:23 - Cloud Monitoring alert 発火 (Fast burn 18x)
2026-03-15 09:25 - SRE Oncall がトリアージ開始
2026-03-15 09:31 - IC 指名、Operations Lead と Comms 着任
2026-03-15 09:33 - Feature Flag OFF（緩和開始）
2026-03-15 09:35 - 影響収束を確認、SLI 回復
2026-03-15 09:50 - Status Page 「Resolved」更新
...

## Root Cause（Five Whys）
[詳細]

## Trigger
[何が引き金を引いたか]

## Detection
- どう検知したか (alert / customer report)
- 検知から対応までの時間

## Resolution
- 何で復旧したか
- mitigation, rollback, fix の区別

## What Went Well
- Multi-burn-rate alert が 8 分で発火
- Feature Flag で即時止血できた
- IC 指名がスムーズ

## What Went Wrong
- Canary 段階で気づけなかった
- Status Page 更新に 17 分かかった
- Runbook が古かった

## Where We Got Lucky
- 偶然にも障害が日中で人員確保できた

## Action Items
| # | Action | Owner | Priority | Due |
|---|--------|-------|----------|-----|
| 1 | Canary verification を追加 | SRE A | P0 | 2 週間 |
| 2 | Status Page 自動更新導入 | SRE B | P1 | 1 ヶ月 |
| 3 | Runbook 四半期見直しプロセス | Eng Mgr | P2 | 3 ヶ月 |

## Lessons Learned
[組織として何を学んだか]

## Supporting Information
- Cloud Logging クエリ: ...
- Grafana dashboard: ...
- 関連 ticket: ...

7.7 Game Day / Wheel of Misfortune

7.8 事故ケース集（インシデント対応）

8事故ケース総集編 / 試験で問われる即答パターン

8.1 全章の事故ケース一覧（25 件）

8.2 試験で問われる即答パターン（30+ 行）

8.3 ダウンタイム計算ドリル

8.4 トラブルシュート意思決定フロー

8.5 次のステップ