PCDE 合格対策
SECTION 3

セクション 3：
SRE プラクティス

Google が提唱した Site Reliability Engineering の実装。SLI / SLO / SLA / Error Budget の定量的信頼性管理、Four Golden Signals と Multi-burn-rate アラート、Cloud Service Mesh（旧 ASM）による SLO 計測、Quotas / Reservations / DWS による容量計画、MIG / Cloud Run / GKE HPA・VPA・CA のオートスケーリング、drain / redirect / capacity / rollback のインシデント緩和、Blameless Postmortem までを体系的に押さえます。

📊 出題 ~18% 📐 数値で信頼性を判断 🚨 Mitigate first, fix later 📘🔧🎯 全レベル対応
出題 ~18% 📘 基礎 🔧 応用 🎯 要点
🔑 TL;DR — このセクションの要約 SRE = DevOps の実装（class SRE implements DevOps）。SLI（実測）≥ SLO（内部目標）≥ SLA（顧客契約）、Error Budget = 1 − SLO。99.9% は月 43 分、99.99% は月 4 分、99.999% は月 26 秒。アラートは Multi-window Multi-burn-rate（Fast 14.4x / Medium 6x / Slow 1x）。Cloud Service Mesh（旧 ASM）でアプリ未改修 SLO 計測。容量は Quotas / Reservations / CUD / DWS、AI/ML の GPU/TPU は DWS calendar / flex-start。インシデントは Mitigate first（drain / redirect / capacity / rollback）→ RCA は後。最速の影響停止は Feature Flag OFF。Blameless Postmortem + Five Whys。Toil は 50% 以下。

🎯 学習目標

このセクションの達成度0 / 0









※ チェック状態はこのブラウザに保存されます。

🏛️ SRE 哲学 — class SRE implements DevOps

SRE は Google が 2003 年から実践している、ソフトウェアエンジニアリングの手法で運用問題を解決するアプローチ。DevOps が「理念・WHAT」なら、SRE は「実装・HOW」。

原則 1

SLI / SLO / SLA

ユーザに影響する指標を選び、定量的に信頼性を測る。

原則 2

Error Budget

1 − SLO で算出される「失敗の予算」。リリース判断の基準。

原則 3

Toil 削減

運用作業の 50% 未満をトイルに。自動化で減らす。超えたら開発へ返却。

原則 4

Blameless Postmortem

失敗を責めず、システム改善の素材に。Five Whys + Action Items。

原則 5

Four Golden Signals

Latency / Traffic / Errors / Saturation の 4 軸監視。最小監視セット。

原則 6

DORA 4 Metrics

Deployment Freq / Lead Time / MTTR / Change Failure Rate。

DevOps と SRE の対応関係

DevOps の理念SRE での具体的実装
Reduce organizational silosDev と SRE が 共通の SLO を持つ
Accept failure as normalError Budget で「許される失敗量」を数値化
Implement gradual changeCanary、Multi-burn-rate alert、Error Budget Policy
Leverage tooling and automationToil 50% 以下 を目標
Measure everythingSLI / SLO、Four Golden Signals

3.1 SLI / SLO / SLA / Error Budget

4 つの最重要用語

用語フルネーム内容例
SLIService Level Indicator信頼性の 測定値（実測）過去 28 日の HTTP 成功率 99.95%
SLOService Level Objective内部の 目標値月次 99.9% を維持
SLAService Level Agreement顧客との 契約値（罰則あり）99.9% を下回ったら 10% 返金
Error Budgetエラーバジェット1 − SLO（許される失敗量）99.9% SLO → 月 43.2 分

SLI ≥ SLO ≥ SLA の関係

SLI（実測）99.97% ← 一番高い（現実） SLO（内部目標）99.95% ← SLA より厳しく SLA（顧客契約）99.9% ← 契約上の最低保証 SLI ≥ SLO ≥ SLA（数値が大きい順）／ SLO は SLA を絶対下回らないバッファ

Error Budget の計算

99.9% SLO を 30 日間で達成 = 0.1% のエラーが許される 30 日 = 43,200 分 0.1% = 43.2 分 → 月 43.2 分まではダウンしてよい = Error Budget Error Budget を消費すること自体が悪ではない。 「Error Budget 内ならリリースしてよい」という取引材料。

Four Golden Signals

Latency（遅延）

リクエスト処理時間。p50 / p95 / p99。平均は外れ値で歪む。

成功と失敗で別計測すること（失敗の方が速く返ることが多い）

Traffic（需要）

システムへの需要。RPS / QPS / TPS。負荷予測の基礎。

Errors（エラー率）

失敗したリクエストの割合。5xx 率、4xx 率、明示的失敗。

Saturation（混雑度）

サービスの混雑度。CPU / Memory / Disk I/O / Queue 長。100% 到達前に対処（予測指標）。

💡 覚え方「L T E S」（Late TEST → ラテス）。ユーザー向けサービスの最小監視セット。

SLI のタイプ

タイプ定義例
Availabilityリクエスト成功率HTTP 200 / 全リクエスト
Latency応答時間が閾値以下の割合p99 < 200ms の割合
Throughput処理スループット1 秒あたりのリクエスト数
Error rate失敗率5xx エラーの割合
Correctness結果の正しさ計算の正確性
Freshnessデータの鮮度バッチ処理の遅延が N 分以下
Quality提供品質レコメンド精度
Durabilityデータの保全性データロス率

🔧 Request-based vs Window-based SLI

観点Request-basedWindow-based
計算式Good Events / Total EventsGood Windows / Total Windows
用途HTTP API、トランザクション系バッチ、定期処理、データパイプライン
精度各リクエスト粒度ウィンドウ粒度
エラー突発即座に SLI 低下ウィンドウ内で平均化

🔧 Burn Rate の計算式

Burn Rate = エラー率 / (1 − SLO) 例: SLO 99.9%（Error Budget = 0.1%） - 直近 5 分で 6% エラー → Burn Rate = 60x (残予算を 0.5 時間で使い切るペース → Critical) - 直近 1 時間で 1.5% エラー → Burn Rate = 15x (2 日で使い切るペース → Fast burn alert) - 直近 6 時間で 0.7% エラー → Burn Rate = 7x (Medium burn alert)

🔧 Error Budget Policy（Step Function）

Budget 残量アクション
100% - 75%新規機能リリース自由、リスク変更可
75% - 50%通常リリース、Canary 小さく開始、監視強化
50% - 25%信頼性投資強化、新機能と 50:50
25% - 0%新機能凍結、信頼性タスク優先、Postmortem アクション最優先
枯渇（< 0%）完全フリーズ、全エンジニアが信頼性に集中、VP 承認のみ

🔧 Cloud Service Mesh での SLO（旧 Anthos Service Mesh）

サイドカープロキシ（Envoy）が 全リクエストをインターセプトし、メトリクスを自動収集。アプリ未改修で SLO 計測可能。

# Availability SLI（PromQL） sum(rate(istio_requests_total{ destination_service="payment.prod.svc.cluster.local", response_code!~"5..", reporter="destination" }[5m])) / sum(rate(istio_requests_total{ destination_service="payment.prod.svc.cluster.local", reporter="destination" }[5m])) # Latency SLI histogram_quantile(0.99, sum(rate( istio_request_duration_milliseconds_bucket{ destination_service="payment.prod.svc.cluster.local" }[5m])) by (le))

🔧 信頼性の機会費用（Opportunity Cost）

99% → 99.9% : 10x のコスト 99.9% → 99.99% : 10x のコスト 99.99% → 99.999% : 10x のコスト 過剰投資の代償: - メンテナンスウィンドウ激減 - リリース速度低下 - ホットスタンバイの追加コスト - オンコール疲弊
⚠️ 適切な SLO の決め方ユーザーが気づかない高信頼性は 過剰投資。社内ツールは 99.9%、決済 API は 99.99%、救急コールは 99.999% など、ユースケース別に。

🎯 SRE 用語 即答テンプレ

用語内容例
SLI信頼性の実測値HTTP 成功率 99.97%
SLO内部目標月次 99.95%
SLA顧客契約（罰則あり）99.9% を下回ったら 10% 返金
Error Budget1 − SLO99.9% → 月 43 分
Toil自動化可能な手作業（50% 以下目標）手動再起動、レポート作成
Burn RateError Budget の消費速度倍率14.4x = 1 時間で月予算 2%

🎯 Four Golden Signals 即答

  • Latency: p50 / p95 / p99
  • Traffic: RPS / QPS
  • Errors: 5xx 率、明示的失敗
  • Saturation: CPU / Memory / Queue 長

🎯 ひっかけパターン

ひっかけ正解
「SLA を SLO より高く設定」❌ SLO が SLA より高い（バッファ）
「内部 CPU 使用率を SLI に」❌ ユーザー影響を反映しない
「平均レイテンシを SLI に」❌ パーセンタイル（p95/p99）を使う
「Error Budget 枯渇でリリース早める」❌ 凍結して信頼性に集中

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

99% 99.5% 99.9% 99.95% 99.99% 99.999% 7 時間 18 分 / 月 3 時間 39 分 / 月 43 分 12 秒 / 月 ★ 21 分 36 秒 / 月 4 分 19 秒 / 月 ★ 25.9 秒 / 月 ★ two nines（簡易サービス） 中小規模 three nines（社内 SaaS / 一般 Web） E コマース four nines（決済 API / 基幹） five nines（救急 / 重要インフラ）
🚨 絶対暗記99.9% = 月 43 分 12 秒、99.99% = 月 4 分 19 秒、99.999% = 月 25.9 秒。試験で必ず問われます。手書きで再現できるレベルまで反復。

🔥 Multi-window Multi-burn-rate アラート（必須暗記）

1 つのウィンドウだけでは「短期スパイクで誤検知」または「長期で見落とし」が起きる。複数ウィンドウを AND で組み合わせる SRE Workbook 推奨パターン。

Fast burn Critical Burn Rate: 14.4x Long Window: 1 時間 Short Window: 5 分 予算消費: 2% / 1h 通知先: 📟 PagerDuty 即対応（深夜含む） → 重大障害発生中 Medium burn Warning Burn Rate: 6x Long Window: 6 時間 Short Window: 30 分 予算消費: 5% / 6h 通知先: 💬 Slack 数時間以内に対応 → じわじわ悪化中 Slow burn Ticket Burn Rate: 1x Long Window: 3 日 Short Window: 6 時間 予算消費: 10% / 3d 通知先: 🎫 Jira チケット 後日対応 → 慢性的劣化

📋 Multi-burn-rate 設定表

アラートBurn RateLong WindowShort Window予算消費通知先
Fast burn14.4x1 時間5 分2% / 1hPagerDuty（即対応）
Medium burn6x6 時間30 分5% / 6hSlack（数時間以内）
Slow burn1x3 日6 時間10% / 3dTicket（後日）
🔑 なぜ Multi-window？「長窓で長期的な悪化を検知」+「短窓で一時的回復時に発火停止」→ 誤検知削減 + 重要度に応じた応答 + オンコール負担減。

3.2 容量計画とオートスケーリング

容量計画の 4 つの仕組み

仕組み対象目的
Quotas（割当量）プロジェクトごとの上限課金事故防止、リソース枯渇予防（申請で引き上げ可）
Limits（制限）サービスごとのハード上限物理・アーキ的限界（変更不可）
Reservations（予約）VM 容量を事前確保ピーク時に確実にリソース確保
Dynamic Workload Scheduler (DWS)GPU/TPU の柔軟な確保AI/ML ワークロード

容量確保戦略の比較

戦略即時利用コスト用途
オンデマンド○高通常運用
Reservations○中（CUD 併用で割引）安定したワークロード
CUD（Committed Use Discount）○（予約と組合せ）低（最大 70% 割引）1〜3 年確約のワークロード
Spot VMs△（中断あり）最低（最大 91% 割引）中断可能なバッチ
DWS○ / 予約後中GPU/TPU AI ワークロード

DWS の 2 モード

Flex-start mode

開始時刻を柔軟に、最大 7 日間実行

バッチ学習、ファインチューニング

Calendar mode

開始日時を指定して長期確保（最大 90 日）

大規模事前学習、定期実行

オートスケーリング 3 大プラットフォーム

VM

MIG

Managed Instance Group。CPU / LB / Custom / Schedule / Predictive の 5 ポリシー。Cool-down 60 秒デフォルト。Stateful MIG で disk 保持可。

Serverless

Cloud Run

リクエスト数で自動。concurrency 80（デフォルト）、min-instances で Cold Start 回避、CPU always allocated でバックグラウンド処理可。

K8s

GKE

HPA（Pod 水平）、VPA（Pod 垂直）、Cluster Autoscaler（Node）、NAP（Node Pool 自動作成）。HPA + VPA を同メトリクスで併用は NG。

HPA / VPA / Cluster Autoscaler の使い分け

スケーラー対象軸
HPA（Horizontal Pod Autoscaler）Pod 数水平（CPU / Memory / Custom）
VPA（Vertical Pod Autoscaler）Pod の CPU/Memory 要求量垂直（Pod 再作成）
Cluster AutoscalerNode 数クラスタ（Node Pool 単位）
Node Auto-Provisioning (NAP)Node Pool 自体自動生成
⚠️ HPA + VPA を同メトリクスで併用は NG衝突する。HPA を CPU/Memory 以外（Custom / 外部メトリクス）にする、または VPA をメモリだけ、HPA を CPU だけに。

🔧 Reservations vs CUD vs Spot の使い分け

ニーズ推奨
安定運用のベース負荷Reservations + CUD（最大 70% 割引）
24/7 稼働の安定ワークロードCUD（1 or 3 年）
短期の変動負荷オンデマンド
ピーク容量を確実にReservations（即時消費可能）
中断可能なバッチSpot VM（最大 91% 割引）
GPU/TPU 確実確保DWS calendar mode
GPU/TPU 柔軟確保DWS flex-start mode
AI 学習で物理ラック近接Block reservation

🔧 MIG Autoscaling Policy 詳細

ポリシー用途
CPU utilization汎用（平均 CPU 使用率）
Load balancing utilizationWeb サービス（LB のバックエンド使用率）
Custom metricキュー長、RPS など Cloud Monitoring メトリクス
Schedule-based予測可能な負荷（営業時間）
Predictive過去パターンから予測（起動遅いアプリ）

🔧 Cloud Run の concurrency / CPU 判断

[concurrency 低（1-10）] - 重い処理（画像生成、AI 推論） - メモリ多消費 - インスタンス数が増える [concurrency 高（80-1000）] - 軽い処理（REST API） - I/O バウンド - インスタンス効率良い [CPU request 時のみ] - 通常の HTTP 処理 - コスト最適 [CPU always allocated] - バックグラウンド処理 - WebSocket、ロングポーリング - gRPC ストリーミング - 起動時の重い初期化を活用

🔧 Pod Disruption Budget（PDB）

spec: minAvailable: 2 # 最低 2 Pod 維持 # または maxUnavailable: 1 # 同時 1 Pod のみ退避可 # 対象: Voluntary disruption（drain、アップグレード） # 対象外: Involuntary（ノード故障、OOM） # 影響: Cluster Autoscaler の scale-down を制限

🔧 Pause Pod パターン

クラスタに 「常に削除可能な低優先度 Pod」（pause pod）を配置し、空き容量を維持する手法。高優先度 Pod が来たら追い出される。バースト時の遅延削減に使う。

🎯 容量計画 即答

要件答え
「ML 学習で GPU を確実に確保」Dynamic Workload Scheduler
「大規模 ML で 90 日確保」DWS calendar mode
「待てる ML バッチ」DWS flex-start mode
「中断可能で最安」Spot VM（最大 91% 割引）
「ピーク容量を事前予約」Reservations + CUD
「Quotas は変えられる？」○ 申請で引き上げ可（Limits は不可）

🎯 スケール選定 即答

場面答え
「Cloud Run cold start 解消」min-instances ≥ 1
「Cloud Run バックグラウンド処理」CPU always allocated
「GKE で Pod 数自動増減」HPA（Horizontal Pod Autoscaler）
「GKE で Pod の CPU/Memory 自動調整」VPA
「GKE でノード自動増減」Cluster Autoscaler
「Node Pool 自動作成」Node Auto-Provisioning（NAP）
「HPA と VPA を同じメトリクス」❌ NG（衝突）
「計画的中断時の Pod 保証」PDB（Pod Disruption Budget）
「バースト即応のスペース確保」Pause Pod + Cluster Autoscaler

🎯 重要な数値

項目値
CUD 割引1 年 25-37%、3 年 52-70%
Spot VM 割引最大 91%
DWS flex-start最大 7 日
DWS calendar最大 90 日
Cloud Run concurrency デフォルト80
Cloud Run 最大タイムアウト60 分
GKE 標準モード Pod 数上限110 / ノード
GLB connection draining timeout最大 3600 秒
Toil 目標50% 以下

3.3 インシデント緩和とロールバック

インシデント対応の優先順位（必須暗記）

1. Mitigate 影響緩和 最優先 2. Add Capacity 容量追加 scale out / 予約投入 3. Rollback ロールバック 前バージョンへ 4. RCA 原因究明 後で 📌 鉄則：まず止血、原因究明は後（Mitigate first, fix later） drain redirect capacity rollback MIG min-replicas ↑ HPA max ↑ Cloud Run max ↑ Reservations 投入 Cloud Deploy rollback Cloud Run revision kubectl rollout undo ★ Feature Flag OFF

4 つの緩和手段

1. Drain（ドレイン）

問題インスタンスへの新規トラフィック停止、既存接続は完了させる。

  • GLB バックエンド: Connection draining timeout（最大 3600 秒）
  • GKE Pod: kubectl drain <node>（PDB 尊重）
  • MIG: abandon-instances

2. Redirect（トラフィック切替）

  • Cloud DNS weighted / failover / geo routing
  • Multi-cluster Ingress でクラスタ切替
  • Global LB backend service 差し替え
  • Cloud Run traffic split で旧 revision へ

3. Add Capacity（容量追加）

  • MIG の min-replicas を引き上げ
  • GKE の HPA / Cluster Autoscaler max を引き上げ
  • Cloud Run の max-instances を引き上げ
  • Reservations を投入

4. Rollback（ロールバック）

  • Cloud Deploy: gcloud deploy targets rollback
  • Cloud Run: revision の traffic 100% を旧版に
  • GKE: kubectl rollout undo
  • Helm: helm rollback
  • Feature Flag: 無効化（コードは触らない・秒単位で停止）

🔧 緩和手法の選定

状況最初に試す
新機能が問題Feature Flag OFF（即時）
デプロイ直後の障害Rollback
トラフィック急増Scale Out
リージョン障害Cloud DNS で別リージョン / Multi-cluster Ingress
特定インスタンス問題Drain & Replace

🔧 ICS（Incident Command System）の役割分担

役割責任
Incident Commander (IC)全体統率、決断、優先度決定（修復はしない）
Communications LeadStatus Page、社内通知、顧客連絡
Operations Lead実際の修復作業
Planning Lead長時間障害の戦略
Scribeタイムライン記録
SME技術専門家（DB、NW、Security 等）
🔑 IC の役割IC は 決断と統率のみ、修復はしない。手を動かすと全体俯瞰ができなくなるため。

🔧 インシデントレスポンスの基本フロー

1. Detect（検知） ─ Alert / Uptime Check / 顧客連絡 2. Triage（トリアージ） ─ 影響範囲評価、IC 指名 3. Mitigate（緩和） ─ drain / redirect / capacity / rollback 4. Recover（復旧） ─ SLO 回復確認 5. Communicate（連絡） ─ Status Page、社内通知 6. Postmortem（事後分析） ─ Blameless、Five Whys、Action Items

🔧 Five Whys（なぜなぜ分析）

障害: 注文 API が 30 分応答停止 Why 1: DB 接続枯渇 Why 2: 接続プール上限 100 を超過 Why 3: 旧バージョンが接続を返さないバグ Why 4: 単体テストはあったが、長時間負荷テストがなかった Why 5: パイプラインに長時間負荷テストが組み込まれていなかった → アクション: CD パイプラインに 30 分の負荷テスト追加

🔧 Blameless Postmortem 必須項目

  • ✅ Blameless（人を責めない）
  • ✅ Five Whys（なぜを 5 回）
  • ✅ Timeline（検知→対応→復旧）
  • ✅ Impact（影響ユーザー数、SLO 消費）
  • ✅ Root Cause（根本原因）
  • ✅ What went well / wrong / lucky
  • ✅ Action Items（担当者・期限付き）
  • ✅ Lessons learned
  • ✅ 社内公開
⚠️ Do vs Don'tDo: 「何が」起きたかを問う / プロセス改善 / 教訓を組織で共有。Don't: 「誰が」やったかを問う / 個人攻撃 / 隠蔽。

🎯 ロールバック早見表

場面手段
最速の影響停止Feature Flag OFF（秒単位）
Cloud Deploy 経由デプロイgcloud deploy targets rollback
Cloud Runrevision の traffic 100% を旧版に
GKE Deploymentkubectl rollout undo deployment/<name>
Helmhelm rollback <release> <revision>
MIGrolling update を逆方向（古い template）

🎯 リダイレクト手段

手段用途
Cloud DNS weighted routing重み付け切替（90:10 等）
Cloud DNS failover routingプライマリ障害時
Cloud DNS geo routing地域別ルーティング
Multi-cluster IngressGKE マルチクラスタ切替
Global LB backend serviceバックエンド差し替え
Cloud Run traffic splitrevision 間切替

🎯 サービスライフサイクル

Planning → Deployment → Maintenance → Retirement
  • Planning: SLO 設計、容量計画、オンコール体制、Runbook
  • Deployment: Canary、Verify、Approval、Initial SLO 監視
  • Maintenance: SLO レビュー、Toil 削減、Postmortem、Game Day
  • Retirement: 顧客告知（6 ヶ月以上前）、移行支援、データ削除

👥 ICS と Postmortem 文化

ICS の役割（即答）

  • IC（Incident Commander）: 決断・統率（修復しない）
  • Comms: Status Page、社内通知、顧客連絡
  • Ops: 実際の修復作業
  • Planning: 長時間障害の戦略
  • Scribe: タイムライン記録
  • SME: 技術専門家

障害訓練と文化

  • Game Day: 障害想定訓練（月次推奨）
  • Wheel of Misfortune: ロールプレイ訓練
  • Blameless Postmortem: 人を責めない事後分析
  • Five Whys: 根本原因分析
  • Action Items: 担当者・期限付き再発防止策
  • Status Page: 公開（Statuspage.io 等）／ 内部

🎯 要点と暗記 — 一問一答

Q1. SLI / SLO / SLA の大小関係は？

A. SLI ≥ SLO ≥ SLA（数値が大きい順）。実測（SLI）が一番高く、SLO は SLA を絶対下回らないバッファ、SLA は契約上の最低保証。

Q2. 99.9% / 99.99% / 99.999% の月次許容ダウンタイムは？

A. 99.9% = 43 分 12 秒、99.99% = 4 分 19 秒、99.999% = 25.9 秒（月単位）。

Q3. Multi-burn-rate の Fast / Medium / Slow の数値は？

A. Fast burn = 14.4x（1h/5m）、Medium burn = 6x（6h/30m）、Slow burn = 1x（3d/6h）。SRE Workbook の標準。

Q4. Four Golden Signals は？

A. Latency / Traffic / Errors / Saturation。ユーザー向けサービスの最小監視セット。覚え方「L T E S」。

Q5. アプリ未改修でマイクロサービスごとに SLO を計測したい

A. Cloud Service Mesh（旧 Anthos Service Mesh）+ istio_requests_total。サイドカープロキシ（Envoy）が自動収集。

Q6. ML 学習で GPU を 90 日確保したい

A. Dynamic Workload Scheduler calendar mode。flex-start mode は最大 7 日。

Q7. Cloud Run で cold start を回避したい

A. min-instances ≥ 1。常時最小 1 インスタンスを温存。Java/.NET など起動が重い言語では特に重要。

Q8. Cloud Run でバックグラウンドタスクを実行したい

A. CPU always allocated。request 時のみ CPU 割当だと、リクエスト処理後に停止してしまう。WebSocket、gRPC ストリーミングも同様。

Q9. HPA と VPA を同じメトリクス（CPU）で併用したい

A. NG（衝突）。HPA を CPU/Memory 以外（Custom metric）にする、または VPA をメモリだけ・HPA を CPU だけに分ける。

Q10. 障害発生時に最初にすべきことは？

A. Mitigate first（影響緩和）。drain → redirect → capacity → rollback の順。原因究明は後。最速の影響停止は Feature Flag OFF。

Q11. IC（Incident Commander）の役割は？

A. 決断と統率のみ、修復はしない。修復は Operations Lead、連絡は Communications Lead が担当。

Q12. Postmortem で最も重要な原則は？

A. Blameless（非難なき）。「誰が」ではなく「何が」を問い、プロセス改善に集中。Five Whys + Action Items（担当者・期限付き）。

💡 必殺フレーズ集（試験当日用）

状況即答
「DevOps を実装する具体的手法」SRE（class SRE implements DevOps）
「ユーザー影響の最小監視セット」Four Golden Signals
「信頼性の数値目標」SLI / SLO / Error Budget
「顧客との契約（罰則あり）」SLA
「ノイズ少ない SLO アラート」Multi-window Multi-burn-rate
「Error Budget 枯渇時」新機能リリース停止
「マイクロサービス間で SLO 計測」Cloud Service Mesh + istio_requests_total
「アプリ未改修で SLO」Cloud Service Mesh
「GPU/TPU 確実確保」Dynamic Workload Scheduler
「大規模 ML で 90 日確保」DWS calendar mode
「待てる ML バッチ」DWS flex-start mode
「中断可能で最安」Spot VM（最大 91% 割引）
「ピーク容量を事前予約」Reservations + CUD
「Cloud Run cold start 解消」min-instances ≥ 1
「Cloud Run バックグラウンド処理」CPU always allocated
「GKE で Pod 数自動増減」HPA
「GKE で Pod の CPU/Memory 自動調整」VPA
「GKE でノード自動増減」Cluster Autoscaler
「Node Pool 自動作成」Node Auto-Provisioning（NAP）
「HPA と VPA を同じメトリクス」❌ NG（衝突）
「計画的中断時の Pod 保証」PDB（Pod Disruption Budget）
「バースト即応のスペース確保」Pause Pod + Cluster Autoscaler
「障害時最初のアクション」Mitigate first（drain / redirect / capacity / rollback）
「最速の影響停止」Feature Flag OFF
「Cloud Run 旧版に戻す」revision traffic 100%
「GKE ロールバック」kubectl rollout undo
「Cloud Deploy ロールバック」gcloud deploy rollouts rollback
「GLB バックエンド安全削除」capacity-scaler 0 + connection draining
「リージョン切替」Cloud DNS weighted / Multi-cluster Ingress
「障害時の役割分担」ICS（IC / Comms / Ops / Planning）
「IC の役割」決断と統率のみ、修復はしない
「障害訓練」Game Day、Wheel of Misfortune
「事後分析の文化」Blameless Postmortem
「Toil 上限」50%（超えたら開発へ返却）
「サービス廃止告知の目安」6 ヶ月以上前
🔑 5 分で復習する箇条書きまとめ
  • SRE = DevOps の実装（class SRE implements DevOps）
  • SLI（実測）/ SLO（内部目標）/ SLA（契約）/ Error Budget（1 − SLO）
  • ダウンタイム: 99.9%=43 分、99.99%=4 分、99.999%=26 秒（月）
  • Four Golden Signals: Latency / Traffic / Errors / Saturation
  • Multi-burn-rate: Fast (1h/14.4x)、Medium (6h/6x)、Slow (3d/1x)
  • Error Budget 枯渇 → リリース全停止、信頼性集中
  • Cloud Monitoring SLO → Service Monitoring
  • Cloud Service Mesh → アプリ未改修で SLO（istio_requests_total）
  • 容量: Quotas（増やせる）/ Limits（不可）/ Reservations / DWS（GPU/TPU）
  • DWS: flex-start（7 日）/ calendar（90 日）
  • MIG オートスケール: CPU / LB / Custom / Schedule / Predictive
  • Cloud Run: concurrency、min-instances、CPU always allocated
  • GKE: HPA（水平）/ VPA（垂直）/ Cluster Autoscaler（Node）/ NAP（Pool 自動）
  • HPA + VPA 同メトリクス NG
  • PDB で計画的中断時の Pod 保証
  • インシデント緩和優先: Mitigate → Capacity → Rollback → RCA
  • 最速の影響停止: Feature Flag OFF
  • ICS: IC（決断）/ Comms / Ops / Planning
  • Blameless Postmortem + Five Whys + Action Items
  • Toil 50% 以下、超えたら開発へ返却
← セクション 2：CI/CD パイプライン セクション 4：可観測性とトラブルシュート → 📝 問題演習を解く 📖 用語集