GCP PCDOE 試験対策｜SRE / SLI / SLO / Error Budget 実装パターン完全ガイド

PCDOE 試験の中核である Site Reliability Engineering (SRE) 領域を、Cloud Monitoring 実装を絡めて深掘りします。SLI / SLO / Error Budget の理論から、Burn Rate アラート、Toil 削減、Blameless Postmortem まで網羅します。

SLI / SLO / SLA の階層

概念	定義	例
SLI (Service Level Indicator)	実測指標	HTTP 200 率、P99 レイテンシ
SLO (Service Level Objective)	社内目標	SLI 99.9% を維持
SLA (Service Level Agreement)	顧客契約	99.5% 未満で 10% 返金

SLI の選び方

サービス種別	推奨 SLI
リクエスト駆動 (Web/API)	Availability (成功率)、Latency (P95/P99)
パイプライン (バッチ/ストリーミング)	Correctness、Coverage、Freshness
ストレージ	Durability、Throughput
イベント駆動	End-to-end latency、Loss rate

Error Budget の計算例

SLO 99.9% / 30 日 = Error Budget 0.1% = 30 × 24 × 60 × 0.001 = 43.2 分
SLO 99.95% / 30 日 = 21.6 分
SLO 99.99% / 30 日 = 4.3 分

Burn Rate アラート (Multi-window Multi-burn-rate)

段階	Burn Rate	消費	用途
Fast burn	14.4x	1 時間で月間予算 2%	即時 PagerDuty (重大障害)
Slow burn	1x	長時間で予算消費	翌営業日対応 (傾向悪化)

Cloud Monitoring の SLO アラートでは Lookback window (1h / 6h / 24h / 3d) と Threshold (Burn rate) を組み合わせて Fast / Slow の 2 段階通知を設定するのがベストプラクティスです。

Cloud Monitoring の SLO 設定手順

Service を定義 (Cloud Run / GKE / 自前 Service)
SLI を選択: Availability / Latency / Custom Metric
Good event / Total event の定義 (例: HTTP 5xx を除く)
SLO Target (例: 99.9%) と Compliance Period (Rolling 28 日) を設定
Burn Rate アラートを Fast (14.4x, 1h) と Slow (1x, 24h) で作成
通知チャネル: PagerDuty / Slack / Email / Webhook

Toil 削減アプローチ

定期繰り返し作業を「Toil ログ」に記録 (週次集計)
自動化候補のスコアリング: 頻度 × 時間 × 重要度
Cloud Functions / Workflows / Cloud Scheduler で自動化
Anthos Config Management で GitOps 化
SRE チームの Toil 割合を 50% 以下に維持

Blameless Postmortem テンプレート

Summary: 1〜2 行
Impact: ダウン時間、影響ユーザー数、Error Budget 消費
Timeline: 検知 → 緩和 → 解決の時系列
Root Cause: 技術的原因 + 仕組み的原因
What went well: モニタリング、ロールバック等
What went poorly: 検知遅延、誤情報等
Where we got lucky: たまたま助かった要因
Action items: 担当者・期限つきタスク

頻出ひっかけ問題

SLA < SLO: 顧客契約 (SLA) より厳しい内部目標 (SLO) を設定するのが鉄則
SLI はユーザー体験: CPU 使用率ではなく、リクエスト成功率/レイテンシを採用
Error Budget Policy: 枯渇時は新機能リリース凍結 = ビジネス側と事前合意必須
Cloud Monitoring SLO 機能: Custom SLI に Log-based Metric も指定可能

SLI / SLO / SLA の違いは？

SLI は実測値 (例: 成功率 99.95%)、SLO は社内目標 (例: 99.9% を維持)、SLA は顧客との契約 (例: 99.5% 未満で返金)。SLA < SLO < 100% が定石。

Error Budget とは？

SLO で許される失敗の上限 (例: 99.9% SLO なら 0.1% = 月 43 分のダウン許容)。これを使い切るまでは新機能リリース OK、超えたら凍結というポリシー。

Burn Rate アラートとは？

Error Budget の消費速度。例: 1 時間で月間予算の 2% を消費 = 14.4x burn。Fast burn と Slow burn の 2 段階アラートが推奨パターン。

SLI はどう選ぶ？

ユーザー体験に直結する指標 — Availability (成功率)、Latency (P99 等)、Throughput、Correctness。リクエスト/イベント/データパイプライン別にテンプレが存在します。

Cloud Monitoring の SLO 機能で何ができる？

SLI 定義 → SLO 計算 → Error Budget 可視化 → Burn Rate アラートまでマネージドで実現。Custom Metric / Distribution / Log-based も対応。

Toil 削減のコツは？

繰り返し・自動化可能・運用に追われがちなタスクを定量化 (例: 週 X 時間)、Cloud Build / Workflows / Cloud Functions で自動化、SRE チームの 50% 以下に抑えるのが目安。

Postmortem の書き方は？

Blameless (人を責めない)、Timeline、Impact、Root Cause、What went well、What went poorly、Action items を構造化。Google の sre.google で公開テンプレート利用可。

PCDOE で頻出の SRE ツールは？

Cloud Monitoring (SLO / Alerting)、Cloud Logging (Log-based metric)、Managed Service for Prometheus、Cloud Trace、Cloud Profiler、Error Reporting、Incident Response (PagerDuty 連携)。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

GCP 試験対策ページを見る

この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。

GCP PCDOE 試験対策｜SRE / SLI / SLO / Error Budget 実装パターン