少有服務從第一天起就有 SRE 支援。Onboarding（接管） 是 SRE 評估服務、改善生產不足之處、最終承擔生產責任的過程。

但比起接管既有服務，有兩個更好的時機點：

• 設計階段就介入：與軟體工程的「越早抓 bug 越便宜」道理相同
• 提供 SRE 認證的基礎建設平台：讓產品團隊把心力放在應用層創新

本章依序介紹三種模式：Simple PRR Model → Early Engagement Model → Frameworks & SRE Platform。

Simple PRR Model（生產就緒度評估）#

PRR（Production Readiness Review） 是 SRE 接管服務前的前置步驟，目標：

• 驗證服務符合生產設定與運維就緒的標準
• 改善生產可靠性，減少未來事件數量與嚴重度

SRE 關心的「生產面向」#

• 系統架構與服務間依賴
• 儀器化、指標、監控
• 緊急應變
• 容量規劃
• 變更管理
• 效能：可用度、延遲、效率

其他支援形式#

SRE 不可能支援每個服務，因此提供替代：

• 文件（內部 Production Guide）
• 諮詢（LCE 為典型，廣度大於深度）

當諮詢不足以涵蓋一個服務（規模成長數量級、變成許多服務的依賴），就需要長期 SRE engagement。

Simple PRR 的階段#

1. Engagement：1–3 位 SRE 主導；確定 SLO/SLA、潛在設計改動、訓練計畫
2. Analysis：基於 PRR checklist 與 Production Guide 評估服務
3. Improvements & Refactoring：與開發團隊協商優先序，雙方並肩改造
4. Training：設計概覽、請求流深入、生產設定、實作練習
5. Onboarding：責任與所有權漸進轉移
6. Continuous Improvement：上線後仍持續精進

範例 checklist 問題#

• 更新會不會一次影響太大比例的系統？
• 服務是否連到正確類型的下游實例（如端使用者請求別連 batch 系統）？
• 是否要求足夠的網路 QoS？
• 是否把錯誤送到中央 log 系統？
• 使用者可見的失敗是否都有監控與告警？

Shakespeare 案例#

Shakespeare 服務原本由開發者揹 pager；隨營收成長後申請 SRE 支援，PRR 發現「儀表板沒涵蓋部分 SLO 指標」→ 修了之後 SRE 接 pager（2 位開發者一起 On-Call），每週生產會議共同檢視。

Early Engagement Model#

Simple PRR 的本質限制：SRE 介入太晚——服務已上線、大規模運行。提早介入可以從一開始就為可靠性設計。

適用情境#

• 重要的新功能且將成為既有受 SRE 管理系統的一部分
• 現有系統的重要重寫或替代品
• 開發團隊主動尋求 SRE 諮詢或接管

各階段的好處#

• Design：在「設計選擇還可逆」時介入，避免事後 retrofit
• Build：建議現成 library 與 control，建立操作熟悉度
• Launch：協助設計 dark launch、漸進 rollout 等模式
• Post-launch：穩定發佈讓開發團隊不必在「修穩 vs. 新功能」間掙扎

撤離也是好結果#

有時 SRE early engagement 後發現「這個服務根本不需要 SRE 完整接管」——這是好事：它被設計得足夠可靠且低維護成本，留給開發團隊即可。

反之若服務沒達到預期規模，SRE 投入算是 business risk 的一部分。

Frameworks & SRE Platform#

Early Engagement Model 仍受限於人力規模。要擴展 SRE 影響力，必須轉為**「設計為可靠（design for reliability）」**：把最佳實踐封裝進共用 framework。

為什麼需要 framework#

• 微服務化讓服務數量飆升、每個都有固定 SRE 成本
• 招募合格 SRE 困難且昂貴
• 多數服務無法獲得 SRE 直接支援，但仍需高品質生產實踐

設計原則#

• 編碼為程式碼的最佳實踐：「使用即生產就緒」
• 可重用的解法：規模化與可靠性問題的共用實作
• 共同生產平台與控制面：統一介面、運維控制、監控、log、設定
• 更易自動化：共同控制面讓「整合的事件視圖」可能

Framework 提供什麼#

針對 Java、C++、Go 等環境各自實作（同樣 API 與行為），覆蓋：

• 儀器化與指標
• 請求 log
• 流量與負載管理
• 業務邏輯的標準語意元件
• 監控的標準維度
• 設定的標準格式

開發者組合框架即可獲得正確的基建使用方式；SRE 只需審查業務邏輯而非基建黏合。

Framework 的多重好處#

• 顯著降低運維開銷：強規格 conformance、內建部署/監控/自動化、便於管多服務、idea 到 SRE 級生產品質僅需數天
• 設計即普惠支援：未獲完整 SRE 支援的服務也能用上 SRE 認證的基建——突破 SRE 人力的天花板
• 更快、更輕的 engagement：PRR 因框架內建特性而加速，單一 SRE 一季內可完成 onboarding
• 新的共享責任模式：SRE 負責「平台」基建，開發團隊處理應用功能 bug——擺脫「全有或全無」的二元選擇

員額（staffing）的轉變#

• 共用技術 → 每服務需要的 SRE 變少
• 平台團隊依「平台維護」員額而非「服務數量」員額——可被多產品共享

結語#

三種模式（Simple PRR、Early Engagement、Frameworks）在 Google 內部並存。

但 frameworks 是當前最有影響力的方向——它擴展了 SRE 的貢獻、降低服務管理成本、提升整體 Google 的基線服務品質。

從「把服務修好交給 SRE」演進為「從設計就把可靠性內建」——這是 SRE 模式的下一個十年。