SRE 可靠性指標簡介
網站可靠性工程 (Site Reliability Engineering, SRE) 是一門將軟體工程思維應用於系統運維的學科。SRE 的核心是三個縮寫詞，它們定義了我們如何衡量並承諾可靠性：SLI、SLO 和 SLA。
對於 Professional Cloud Architect 來說，理解這些對於平衡功能開發速度 (feature velocity)（快速移動）與穩定性（不破壞系統）的需求至關重要。
白話文解釋 SLI, SLO, SLA
比喻 1 — 披薩外送承諾
- SLI (指標 Indicator): 這就是秒錶。它精確衡量從電話打入到披薩送到你門口所花費的時間（例如：28 分鐘）。
- SLO (目標 Objective): 這是經理為員工設定的內部目標：「我們 95% 的披薩必須在 30 分鐘內送達。」如果達到了，經理就很開心。
- SLA (協定 Agreement): 這是對客戶的外部承諾：「如果您的披薩超過 30 分鐘才送到，則免費。」如果我們違反了這一點，我們就會賠錢。
比喻 2 — 考試成績
- SLI: 你在模擬測試中的實際分數（例如：85%）。
- SLO: 你想進入好大學所需的目標分數（例如：「我這學期的平均分數需要達到 90%」）。
- SLA: 獎學金要求。如果你的平均分數低於 80%，你將失去資助（後果）。
比喻 3 — 汽車的可靠性
- SLI: 當你轉動鑰匙時，汽車成功啟動的時間百分比。
- SLO: 你的個人期望：「我的車應該有 99.9% 的時間都能啟動，這樣我上班就不會遲到。」
- SLA: 製造商的保固。如果汽車因缺陷而無法啟動，經銷商將支付維修費用。
一個服務被允許的不可靠程度 (1 - SLO)。它代表了承擔風險的空間，例如部署新功能。
定義三大支柱
1. SLI (服務水準指標 Service Level Indicator)
對所提供的服務水準之某些方面的量化衡量。
- 常見 SLI: 可用性 (成功數/總數)、延遲 (回應時間)、吞吐量 (請求數/秒)、持久性 (數據持久化)。
- 格式: 通常是一個比例：
(良好事件數 / 總事件數) * 100%。
2. SLO (服務水準目標 Service Level Objective)
由 SLI 衡量的服務水準的目標值或數值範圍。
- 目的: 為系統定義一個「快樂狀態」。
- 範例: 「在 30 天的滾動窗口中，99.9% 的請求延遲必須小於 200 毫秒。」
3. SLA (服務水準協定 Service Level Agreement)
與使用者簽訂的明確或隱含合約，其中包括未達成 SLO 的後果。
- 後果: 通常是財務抵免、服務延長或法律處罰。
- 注意: SRE 通常關注 SLO，而法律/商務團隊關注 SLA。SLO 幾乎總是比 SLA 更嚴格（例如：SLO 是 99.9%，SLA 是 99.5%）。
錯誤預算：平衡風險與速度
錯誤預算 (Error Budget) 是 SRE 中最強大的概念。
- 公式:
100% - SLO% = 錯誤預算。 - 邏輯: 如果你的 SLO 是 99.9%，你就有 0.1% 的故障「預算」。
- 行動:
- 如果預算充足，你可以快速部署新功能並承擔風險。
- 如果預算耗盡，你必須凍結新部署，並 100% 專注於可靠性，直到預算恢復。
架構師洞察： 在 PCA 考試中，如果問題詢問如何處理「想要發佈功能的產品團隊」與「想要穩定性的運維團隊」之間的衝突，答案是建立錯誤預算。這提供了一種數據驅動的方法來決定何時快進、何時減速。 ::
選擇合適的 SLI：五大 SLI 家族
並非所有指標都適合當 SLI。Google SRE workbook 把使用者導向的 SLI 分成五大家族，PCA 題目經常考你怎麼為不同工作負載挑對家族。
Availability SLI（可用性）
請求成功的比率：successful_requests / total_valid_requests。在 Cloud Monitoring 的 SLO UI 中，這對應到以 loadbalancing.googleapis.com/https/request_count 為基礎、過濾 response_code_class != "5xx" 的 request-based SLI。適用於同步 HTTPS API、GKE Ingress、App Engine 前端。
Latency SLI（延遲）
請求延遲低於門檻的比率，例如：requests_with_latency_lt_300ms / total_requests。Cloud Monitoring 提供 loadbalancing.googleapis.com/https/total_latencies 作為分佈型指標——把門檻設在使用者可接受的第 95 或第 99 百分位數。
Throughput SLI（吞吐量）
針對批次與串流管線（Dataflow、Pub/Sub、Dataproc），以單位時間完成工作量對下限值來衡量，例如：「Dataflow 作業每分鐘處理 ≥ 50K 事件」。Pub/Sub 訂閱可用 subscription/oldest_unacked_message_age 作為新鮮度代理指標。
Quality SLI（品質）
對於採用 graceful degradation 的系統（推薦引擎、搜尋），衡量以完整模型路徑回應 vs. 以較便宜 fallback 回應的比率。對跑在 Vertex AI endpoint 並搭配快取 fallback 的個人化服務特別有用。
Correctness / Freshness SLI（正確性／新鮮度）
針對資料管線與 BigQuery scheduled queries，衡量 (通過驗證的列數 / 總列數) 或 data_age < freshness_target。對 Vertex AI Feature Store 的 ML 特徵儲存尤其關鍵，因為過期特徵會無聲無息地拖垮模型品質。
PCA 考試型樣：當題目說「使用者抱怨搜尋結果過時」或「儀表板顯示昨天的數字」，正確的 SLI 家族是 freshness／correctness，不是 availability。Availability 在這個情況下還會回報 100%，但系統從使用者角度已經壞掉。
Good Events vs Bad Events：精確定義分母
Cloud Monitoring 裡每一個 SLI 最終都是 good_events / valid_events。把分母搞錯，是 SLO 最常見的單一錯誤。
什麼算「valid」
- 排除 合成探針、內部健康檢查、壓測流量。uptime check 的 200 OK 不是真實使用者事件。
- 排除 由 client 端造成的 4xx（400、401、403、404），這些不是服務的錯。但 包含 429（rate limit），如果是你的 rate limiter 設錯了，那就是你的問題。
- 包含 5xx、timeout，以及透過
error_reporting浮上來的未處理例外。
視窗類型
Cloud Monitoring 支援兩種 SLO compliance window：
- Calendar-based：對齊週、月、季。適合對應計費週期的 SLA。
- Rolling：通常是 28 或 30 天。比較適合工程決策，因為它不會在每月一號歸零、把一個爛週藏起來。
Compound SLI（複合 SLI）
「session 成功率」這種 SLI 可能要求 login + search + checkout 全部成功。請用 Cloud Monitoring 的衍生指標或 Cloud Logging 的 log-based metric 實作，不要拿三個獨立 SLO 的乘積——那會重複計算相關聯的失敗。
依服務層級挑選 SLO 目標
「所有服務一律 99.9%」是反模式。請依使用者衝擊把服務分層，再分配目標。
Tier 0 — 營收關鍵的同步 API
範例：checkout、payment authorization、login。目標 99.95% availability、99% latency < 300ms，28 天 rolling window。錯誤預算約等於每月 21 分鐘停機——夠做一次季度的 rolling-restart 部署，但每週做就會爆。
Tier 1 — 使用者導向的讀取 API
範例：商品 catalog、search、由 BigQuery BI Engine 支撐的 dashboard。目標 99.9% availability。錯誤預算約 43 分鐘／月，足以容忍 canary 失敗與相依服務小抽風。
Tier 2 — 非同步／批次／內部
範例：Cloud Composer DAG、Dataflow 夜間彙整、Cloud Run 管理工具。目標 7 天內 99.5% job-success-rate，再加一條新鮮度 SLO（「資料須在 06:00 UTC 前可用」）。不要把工程預算燒在這層追 99.99%。
為什麼不全部都拉到 99.99%
99.99% 代表每月只有約 4.3 分鐘的不可用時間。在這個層級，服務的可靠性主要被你控制不了的相依方決定：GCE live migration、區域網路、第三方 DNS。把一層拉得比相依方還高，只是燒工程時間而不改善使用者體驗。
常見 PCA 陷阱： 題目描述一個 5 名員工使用的 B2B 內部管理工具，問你 SLO 目標。「最佳實務」答案 不是 99.99%。正確答案是配合停機成本——通常 99% 或 99.5% 就夠了，把錯誤預算留給面向客戶的那一層。
錯誤預算政策：把數字變成行動
沒有書面政策的錯誤預算只是個指標。政策把預算狀態翻譯成團隊行為，PCA 題目會考你各個狀態下該觸發什麼動作。
預算健康（剩餘 > 50%）
- 功能上線維持正常節奏。
- 高風險遷移（region failover 演練、schema 變更）排在這個階段。
- SRE 至少 50% 時間做專案性工作，不是 toil。
預算警戒（剩餘 10-50%）
- 放慢發版列車：canary 時間拉長，透過 Cloud Deploy 強制階段式 rollout。
- 暫停基礎建設實驗（例如新的 GKE node pool 遷移）。
- 啟動一個 postmortem action item 燒清單的 sprint。
預算耗盡（< 0%）
- 硬性凍結 功能部署，只有可靠性修正與安全 patch 能上線。
- 呼叫 SRE on-call 並通報 Product VP。
- Postmortem 變成 blocking——action item 沒落地之前，沒有新功能。
政策由誰背書
政策由 Engineering、SRE、Product 三方簽字後，SLO 才上線。當 PCA 題目問「要怎麼讓開發團隊跟 ops 不要每次出包就吵架？」，請提這套三方協議。
Burn Rate 告警：Multi-Window Multi-Burn
對「SLO 已經低於目標」發告警太晚——那時你已經違反承諾了。SRE 的最佳實務是 multi-window multi-burn-rate 告警，Cloud Monitoring 的 SLO alert 原生支援。
Burn rate 公式
burn_rate = (errors_in_window / window_length) / (1 - SLO)。burn rate 為 1.0 代表你以剛好會在 SLO 視窗內把預算燒完的速率消耗預算。burn rate 為 14.4 代表照這個速度，30 天的預算大約 2 天就燒光。
建議門檻（來自 SRE workbook）
| 嚴重度 | Burn rate | 短視窗 | 長視窗 | 觸發前已消耗預算 |
|---|---|---|---|---|
| Page（fast） | 14.4 | 5 min | 1 hour | 2% |
| Page（slow） | 6 | 30 min | 6 hours | 5% |
| Ticket | 1 | 2 hours | 3 days | 10% |
為什麼要兩個視窗
短視窗抓快速消耗（爛部署造成 error 飆升）。長視窗壓掉單一壞分鐘造成的誤報。Cloud Monitoring 的 SLO alerting UI 可以用一條 policy 同時設定兩個視窗，並透過 notification channel 路由到 PagerDuty／Opsgenie。
成本紀律
Multi-burn 告警的觸發頻率約為樸素門檻告警的 1/10——這就是重點。On-call 疲勞本身就是一種可靠性風險。
PCA 用的 burn-rate 速記表： Page fast 設在 1 小時 長視窗、burn-rate 14.4（消耗 30 天預算的 2%）。Page slow 設在 6 小時 視窗、burn-rate 6（5%）。Ticket 設在 3 天 視窗、burn-rate 1（10%）。記住三元組 14.4／6／1。
Cloud Monitoring 具體做法： 把 burn-rate alert 定義在 SLO 底下的 Services 區塊，而不是獨立的 metric alert。SLO-aware alert 會自動沿用同一份 SLI 定義與 good/valid event filter，避免「衡量的東西」跟「會 page 你的東西」漂移開。
Google Cloud 上的 Service Monitoring
Cloud Monitoring 的 Services 功能（前身為「Stackdriver Service Monitoring」）是 PCA 認可的 SLO 操作化做法。
自動偵測的服務
- App Engine service 與 version
- Cloud Run service
- 搭配 Istio／Anthos Service Mesh 的 GKE workload
- Cloud Endpoints／API Gateway
對這些服務，Cloud Monitoring 會基於 Istio request metric 或 HTTPS load balancer metric 提出預設 SLI——先接受作為起點，再去調門檻。
自訂服務
對 VM、BigQuery scheduled query、Dataflow 作業，建立 custom service 並掛上來源為以下類型的 SLI：
- 標準指標（例如
dataflow.googleapis.com/job/is_failed） - 在 Cloud Logging 定義的 log-based metric
- 由
OpenTelemetryexporter 寫入的使用者自訂 Monitoring metric
SLO API 與 Terraform
透過 google_monitoring_slo Terraform resource 把 SLO 定義為 code。把 SLO 放進版控，是避免工程師偷偷在 console 改門檻來躲告警的唯一方法。
錯誤預算消耗整合
Services dashboard 在同一個視窗顯示目前 SLO 合規率、剩餘錯誤預算、burn rate 趨勢。把這個 dashboard 連到 runbook，on-call 工程師在決定是否 rollback 前就會先看到預算狀態。
Toil 縮減與 50% 法則
SRE 把 toil 定義為手動、重複、可自動化、戰術性、且隨服務規模線性增長的工作。GCP 上的例子：手動輪替 GKE node pool、手動跑 BigQuery backfill、在 Cloud Logging 翻 log 逐條 ack 告警。
50% 上限
SRE 把 operational／toil 工作上限訂在時間的 50%。剩下的 50% 是工程性工作：自動化、容量規劃、SLO 精修。當 toil 超過 50% 時，SRE 團隊會 把服務交回 開發團隊，直到自動化補上。
GCP 自動化工具
- Cloud Workflows／Cloud Composer 把以前需要人工的 runbook 步驟編排起來。
- Cloud Functions 由 Eventarc 觸發來自動修復（例如在
kube_pod_status_reason="OutOfcpu"時自動擴 node pool）。 - Terraform + Config Sync 消除事件中製造 toil 的「雪花」叢集設定。
- Cloud Deploy 用自動 canary 分析取代人工把關的 promotion。
把 toil 當 SLI 輸入
把每位工程師每週的 toil 時數丟到 BigQuery 當指標追蹤。當趨勢往上走，它領先預測 SLO 退步 4-6 週，因為疲憊的人會推更多爛變更。
Blameless Postmortem 與 SLO 消費者契約
SLO 沒達標時的回應是 blameless postmortem，不是究責大會。PCA 把這當流程題：誰參加？產出什麼？誰負責 follow-up？
Postmortem 範本（Google 開源格式）
- Summary：2-3 句，不究責語氣。
- Impact：受影響請求數、消耗的錯誤預算、影響的營收／使用者。
- Root causes：促成因素，不寫「人為失誤」。
- Trigger：啟動事件的具體變更或事件。
- Resolution：什麼動作止血。
- Action items：每一條都有 owner、Jira／議題編號、到期日。
SLO 消費者契約
當你的服務是別人 SLO 的相依方時，你會簽一份 consumer compact：書面同意你的 SLO 比對方嚴格、且你會分享 burn rate dashboard。在 GCP 上常見做法是透過 IAM 共用 workspace 發佈 Cloud Monitoring dashboard，讓下游團隊即時看到你的錯誤預算。
觀測性預算
Log、metric、trace 都要花錢——Cloud Logging 每月每專案超過 50 GiB 就計費，Cloud Monitoring 高基數自訂指標累積很快。設一條 observability budget（例如雲端支出的 5%），像錯誤預算一樣追蹤。超支時就降採 debug-level log，不要等財務在事件中途把 log retention 關掉。
要壓低 Cloud Logging 成本，把高流量應用 log 透過 Log Router sink 路由到 BigQuery（便宜）或 Cloud Storage（最便宜），並從預設的 _Default log bucket 中排除。告警等級的 log 留在 Cloud Logging，其他全部歸檔。
FAQ — SLIs, SLOs, and SLAs
Q1. 誰應該定義 SLO？
SLO 應該由產品負責人（了解使用者需求）與 SRE/架構師（了解系統能力）共同努力完成。
Q2. 「100% 可用性」是一個好的 SLO 嗎？
不。 100% 絕非現實或理想的目標。它會使系統過於昂貴並阻礙任何變更（因為每次變更都帶有風險）。正如 Google 所說，「對於幾乎任何事情，100% 都是錯誤的目標。」
Q3. 如何在 Google Cloud 中衡量 SLO？
使用 Cloud Monitoring。它有一個專門的「服務 (Services)」區塊，你可以在其中定義 SLI（基於指標或記錄）並設定 SLO 目標。然後它會自動追蹤你的錯誤預算消耗率 (Error Budget burn rate)。
Q4. 什麼是「以使用者為中心」的 SLI？
以使用者為中心的 SLI 衡量使用者的實際感受。與其衡量「伺服器 CPU」，不如衡量「首頁加載時間」或「成功結帳率」。
Q5. 當 SLO 未達成時會發生什麼？
未達成 SLO 會觸發策略變更（例如：停止發佈），而不一定是半夜的呼叫（除非預算消耗太快，以至於你將違反 SLA）。