本章由 Ben McCormack (Evernote) 和 William Bonnell (The Home Depot) 撰寫，呈現兩家截然不同的公司在與 Google CRE (Customer Reliability Engineering) 團隊合作下，採用 SLO 和 error budget 方法的真實歷程。這些案例證明 SLO 的實作不限於 Google，任何組織都可以根據自身環境量身定制。

Evernote 的 SLO 故事#

Evernote 是一個跨平台應用程式，擁有超過 2.2 億使用者，儲存超過 120 億條資訊，後端由 750+ 個 MySQL 實例支撐。

為什麼 Evernote 採用 SRE 模式#

Evernote 在轉型之初採用傳統的 ops/dev 分離模式：營運團隊保護生產環境的穩定，開發團隊負責開發新功能。這兩個目標經常衝突——開發團隊感到被冗長的營運需求束縛，營運團隊則在新程式碼引入生產問題時感到沮喪。

在五年多時間裡嘗試了不同模式（「你寫的你跑」的開發模式、「你寫的我幫你跑」的營運模式）後，Evernote 最終轉向以 SLO 為中心的 SRE 方法。其轉型目標包括：

• 將工程重心從資料中心的「無差別化重勞力」轉向客戶真正關心的產品工程工作（為此遷移至公有雲）
• 修訂營運與軟體工程師的工作模式，以支持功能速度提升同時維持服務品質
• 改革 SLA 檢視方式，確保更加關注故障對全球客戶群的影響

Evernote 被 SRE 模式吸引，是因為它完全擁抱並接受營運與開發之間的差異，同時鼓勵團隊朝共同目標努力。Error budget/SLO 方法讓兩個團隊在面對相同事實時做出類似決策，移除了大量主觀性。

SLO 導入旅程#

SLO 導入分為兩個目標：

1. 在內部對齊所有團隊圍繞 Evernote 的 SLO
2. 將 SLO 納入與 Google Cloud 團隊的合作中，確保遷移至 GCP 不會稀釋對使用者的承諾

積極使用 SLO 約九個月後，Evernote 已經是第三版的 SLO 實踐。

第一版 SLO 文件#

Evernote 的第一版 SLO 文件包含：

• SLO 定義：99.95% 正常運行時間，以月曆窗口測量，針對特定服務和方法。選擇綁定到日曆月而非滾動期間，以保持服務審查的聚焦和組織性
• 測量什麼與如何測量：
  • 測量什麼：指定一個服務端點來測試服務是否正常運作——內建的狀態頁面會驗證大部分技術棧
  • 如何測量：使用完全獨立於自身環境外的第三方探測器（Pingdom），每分鐘從北美和歐洲多個地點探測。若首次探測失敗，由第二個地理位置分開的探測器確認
• 從監控資料計算 SLO：詳細記錄如何從原始資料計算 SLO。例如，維護窗口期間被視為停機時間，因為不能假設所有使用者都知道維護窗口

SLO 驅動的改善#

Evernote 使用 SLO/error budget 概念來分配未來資源：

• 每月由 Evernote 和 Google 團隊共同進行 SLO 表現審查
• 深入分析上月的任何故障，設定改善行動項目
• 指導原則是**「完美是好的敵人」**——即使 SLO 不完美，也足以引導持續改善

Evernote 確立了六個月的 SLO 審查週期，在變更太頻繁與讓 SLO 過時之間取得平衡。

打破客戶與雲端提供者之間的 SLO 牆#

Evernote 從一開始就不希望在自身與 Google 之間建立虛擬的牆。關鍵做法包括：

• 共享 SLO 和即時表現儀表板：Google CRE 團隊和 Evernote 使用相同的表現儀表板。這看似簡單，但已證明是驅動真正以客戶為中心行為的強大方式
• 具體化的通知：不再是泛泛的「服務 X 運行緩慢」，而是「此問題對 Evernote 的 SLO 造成 5% 影響」
• 聯合事件回應：當 SLO 影響足夠高時，雙方在共享的電話會議橋上快速動員，基於共同定義的 SLO 保持同步

目前狀態#

下一版 SLO 計劃從簡單的正常運行時間 SLO 進步到探測個別 API 呼叫，並納入客戶端指標以更好地呈現使用者服務品質。SLO 提供了標準化的服務品質測量方式，讓 Evernote 能夠進行資料驅動的對話，最終使支援團隊更有效、客戶更滿意。

The Home Depot 的 SLO 故事#

The Home Depot (THD) 是全球最大的家居裝修零售商，擁有 2,200+ 家門店、約 400,000 名員工，每年處理超過 15 億筆客戶交易，電商網站每年接收超過 20 億次造訪。

轉型背景#

THD 進行了兩項重大轉變：

1. 轉向 Agile 和微服務架構：從集中式支援團隊管理大型單體應用，轉變為由小型獨立營運的開發團隊領導的微服務架構
2. 「自由與責任文化」的全棧所有權：開發者可以自由推送程式碼，但也需共同負責服務的營運

這種聯合所有權模式要求營運和開發團隊說共同語言——服務水準目標。服務之間需要透明且一致地回答：

• 你的服務有多可靠？是三個 9、三個半 9 還是四個 9？
• 上限延遲是多少？
• 你能處理我要發送的請求量嗎？如何處理過載？

SLO 文化專案#

在轉型前，THD 沒有 SLO 文化。監控工具和儀表板雖多，但分散各處且不追蹤歷史資料。建立共同的 SLO 文化需要四個面向的策略：

• 共同詞彙 (Common Vernacular)：在 THD 的脈絡中定義 SLO，以及如何一致地測量
• 佈道 (Evangelism)：創建培訓材料、路演、內部部落格、宣傳品（T 恤和貼紙）、培訓計畫（FiRE Academy: Fundamentals in Reliability Engineering）
• 自動化 (Automation)：實作指標收集平台，自動收集部署到生產環境的任何服務的 SLI
• 激勵 (Incentive)：為所有開發經理設定年度目標，要求為其服務設定和測量 SLO

VALET 框架#

THD 審視了跨服務監控的指標模式後，將 SLO 歸納為一個容易記憶的縮寫——VALET：

• V - Volume（流量）：我的服務能處理多少業務量？
• A - Availability（可用性）：服務在需要時是否可用？
• L - Latency（延遲）：服務回應快嗎？
• E - Errors（錯誤）：服務是否在使用時拋出錯誤？
• T - Tickets（工單）：服務是否需要手動介入才能完成請求？

第一組 SLO 的具體定義#

• 可用性和延遲：每個微服務必須為其被其他微服務呼叫的 API 設定 SLO
• 基礎設施利用率：決定不設定利用率 SLO（微服務不太關心，且即將遷移至雲端意味著成本規劃將取代容量規劃）
• 流量：追蹤平均 RPS、峰值 RPS 和報告期間的請求總量，依預期峰值容量設定 SLO
• 延遲：讓每個服務自定義延遲 SLO，要求至少達到 90th 百分位目標，面向使用者的服務偏好 95th 和/或 99th 百分位
• 錯誤：標準化 HTTP 回應碼的使用（4xx 為客戶端錯誤、5xx 為伺服器端錯誤），僅用 5xx 設定 SLO
• 工單：作為歷史延續，繼續追蹤工單作為「軟體營運水準」的衡量

佈道 SLO#

佈道活動從高層領導開始，然後逐一與開發團隊會面：

• 設立內部 WordPress 網站託管 VALET 和可靠性相關部落格
• 舉辦 Tech Talks（包括 Google SRE 客座講者）
• 舉辦 VALET 培訓工作坊（後來演變為 FiRE Academy）
• 創建 VALET 筆電貼紙和 T 恤支持全面的內部行銷活動
• 每週發送 VALET 格式的 SLO 報告給高層領導

自動化 VALET 資料收集#

TPS Reports#

建立在 GCP 的 BigQuery 平台上的框架，自動捕捉部署到新 GCP 環境的任何服務的 VALET 資料：

• 所有 Web 服務前端生成的日誌被送入 BigQuery 處理
• 新建立的服務自動註冊到 TPS Reports
• 整合了聊天機器人，可直接在聊天頻道中查詢服務的 VALET 資料

VALET 服務#

建立了 VALET 應用程式來儲存和報告 SLO 資料，以日、週、月的粒度追蹤 SLO。提供 API 讓不同平台（包括非 GCP 的本地應用平台）整合。

VALET Dashboard#

VALET Dashboard 提供以下功能：

• 註冊新服務（將服務指派到一個或多個 URL）
• 為五個 VALET 類別中的任何一個設定 SLO 目標
• 在每個 VALET 類別下添加新的指標類型
• 跨多個服務報告 SLO，並以多種方式切片和分析資料

SLO 的增長#

從年初追蹤約 50 個服務的 SLO，到年底增長至 800 個服務，每月約新增 50 個服務註冊到 VALET。

VALET 的擴展應用#

• 批次應用：Volume = 處理的記錄量、Availability = 工作在特定時間前完成的比例、Latency = 工作運行時間、Errors = 處理失敗的記錄、Tickets = 操作員手動修復資料和重新處理的次數
• 測試中的應用：搭配 TPS Reports 框架，可以自動執行破壞性測試（混沌工程），並記錄對服務 VALET 資料的影響

未來展望#

• 建立類似 Google 的 error budget 文化，當服務超出 SLO 時停止推送新功能
• 細化 VALET 以追蹤個別端點和消費者
• 追蹤終端使用者延遲 SLO，捕捉第三方標籤、CDN 快取等因素的影響
• 將 VALET 資料延伸到應用部署，在滾動發布前自動驗證 VALET 在容忍範圍內
• 收集服務依賴資訊，建立呼叫樹的視覺化圖表
• 讓**業務擁有者（產品經理）**根據服務對業務的重要性設定 SLO

THD 為產品經理提供了簡化的正常運行時間等級，以業務術語包裝：

• 99.5%：不被門店員工使用的應用或新服務 MVP
• 99.9%：THD 大多數非銷售系統的適當水準
• 99.95%：銷售系統（或支援銷售系統的服務）
• 99.99%：共享基礎設施服務

結論#

這兩個案例研究突顯了幾個重要觀點：

• SLO 文化是一個持續的過程，而非一次性的修復或解決方案
• 雖然 THD 和 Evernote 共享哲學基礎，但它們的測量風格、SLI、SLO 和實作細節截然不同
• SLO 實作不需要是 Google 特有的——正如這些公司根據自身環境量身定制 SLO，其他公司和組織也可以
• SLO 和 error budgets 幫助解決許多不同的問題集：拉近產品開發與營運、促進溝通、更好地支持開發決策，最終為客戶帶來更好的體驗

向大公司引入新流程甚至新文化，需要良好的策略、高層支持、強力的佈道、容易的採用模式，以及最重要的——耐心。這可能需要數年時間，但 The Home Depot 作為傳統企業的成功證明，如果他們能做到，你也可以。