本章提供了一份 SRE 組織從零到成熟的完整路線圖，涵蓋從尚未有 SRE 人員但有志實踐 SRE，到建立穩健且可能跨地域分佈的多個 SRE 團隊的各個階段。無論組織目前處於哪個階段，都能從中找到適合的演進策略。
沒有 SRE 也能實踐 SRE#
即使組織中沒有任何 SRE 人員，仍然可以透過 SLO 來採用 SRE 實務。本章提出第一條 SRE 原則：
原則 #1：SRE 需要有後果的 SLO (SLOs with consequences)。服務相對於 SLO 的表現應引導商業決策。
在沒有任何 SRE 的情況下，組織可以採取以下關鍵步驟：
- 承認你不需要 100% 的可靠性
- 設定合理的 SLO 目標，衡量對使用者最重要的可靠性指標
- 制定 Error Budget Policy，用以引導戰術性的中斷緩解行動，以及長期的可靠性改善工作
- 實際量測 SLO 並承諾遵循 Error Budget Policy，這需要公司領導層的同意
啟動 SRE 角色#
尋找第一位 SRE#
第一位 SRE 可能不具備明確的 SRE 經驗，但以下領域的技能在面試中特別重要：
- Operations：實際運行生產環境應用程式的經驗
- 軟體工程：理解並改善所支援的軟體
- 監控系統：SLO 的量測與追蹤
- 生產環境自動化：擴展運維需要自動化
- 系統架構：擴展應用需要良好的架構設計
安排第一位 SRE 的位置#
可以選擇將第一位 SRE 嵌入以下三種位置之一：
- 產品開發團隊中
- 營運團隊中
- 橫向角色，跨多個團隊提供諮詢
選擇時需考量自身的影響力範圍、當前面臨的挑戰、未來 12 個月預期的挑戰、組織變革計劃，以及該 SRE 個人的背景與技能。
引導第一位 SRE#
第一位 SRE 的首要任務是熟悉服務，理解目前的問題、所需的 toil，以及維持 SLO 所需的工程工作。此時第二條原則登場：
原則 #2：SRE 必須有時間讓明天比今天更好。
初期專案工作可能聚焦於改善監控、處理事後檢討中的高優先級項目，或實作自動化以減少特定 toil。需要留意 SRE 工作異常的跡象，例如工作內容與其他工程師無異、承擔了不成比例的運維工作，或 SLO 未被認真對待。
分散式 SRE#
若組織沒有獨立的 SRE 團隊，務必為分散的 SRE 建立社群，倡導 SRE 的獨特角色，並推動跨團隊的一致性可靠性實踐。
建立第一個 SRE 團隊#
建立團隊的方式由簡到繁包括：
- 作為重大專案的一部分建立新團隊
- 建立橫向 SRE 團隊
- 將現有團隊（如營運團隊）轉型
第三條原則在此適用：
原則 #3：SRE 團隊有能力調節自身的工作負載。
Tuckman 團隊發展模型的應用#
本章以 Tuckman 的績效模型（Forming、Storming、Norming、Performing）來描述團隊建立的各階段。
Forming（組建） – 團隊應具備以下綜合能力：
- 修改應用程式軟體以提升可靠性和效能
- 編寫軟體以加速問題偵測、自動化手動流程
- 建立強健的軟體實務標準
- 對運維變更有條理且審慎的方法
- 理解分散式系統架構
Storming（磨合） – 團隊需要開始協作，與彼此及其他團隊良好合作。在此階段存在多種風險：
- 新團隊作為專案一部分：風險包括職責範圍過大、過度沉迷於完美的 SLO 定義、放棄 SRE 原則以滿足產品里程碑等。緩解方式包括先專注單一重要服務、盡早參與設計階段、明確定義 SRE 接手服務的條件。
- 橫向 SRE 團隊：風險在於被視為新的「關卡」組織。緩解方式是以受尊重的工程師為種子、聚焦交付對其他團隊有短期效益的工具、自視為賦能者而非守門人。
- 就地轉型團隊：風險包括團隊擔心自動化取代工作、缺乏軟體工程技能等。緩解方式包括取得高層支持、重新協商職責以創造餘裕、提供培訓、改變績效評估指標。
紐約時報案例：其 Delivery and SRE 部門將既有團隊轉型為 SRE 團隊。關鍵策略是反轉責任模型，賦能產品開發團隊自助推送變更，並透過每日 office hours 批量處理問題，最終達成 SRE 團隊超過 50% 時間用於專案工作的目標。
Norming（規範） – 團隊應達到以下成熟度：
- SLO 和 Error Budget 已就位，Error Budget Policy 在重大事件後被執行
- On-call 輪班制度已建立且可持續
- Toil 已被記錄、限制和管理
- 事後檢討文化已扎根
- 團隊定期進行訓練演練（如 Wheel of Misfortune 或 DiRT）
- 產品開發團隊持續參與 on-call 輪班
- 團隊定期產出利害關係人報告
Performing（展現績效） – 在最終階段，應期望：
- 參與所有架構設計與變更：SRE 從設計初期就定義軟體建構和可靠性的模式
- 完全的工作負載自主權：團隊持續應用原則 #3，並以系統整體健康為考量
SRE 團隊可以透過拒絕接手、降低 SLO、將運維工作轉移回開發團隊等方式來調節工作負載。若 SRE 已解決了服務的所有問題，應考慮接手新的可靠性挑戰或將服務交還開發團隊，否則團隊會因缺乏挑戰而流失人才。
擴展更多 SRE 團隊#
因服務複雜度而拆分#
當服務過於複雜時，可以按以下方式拆分：
- 架構拆分：例如前端/後端、計算/儲存/網路
- 語言拆分：依程式語言分組
- 地點拆分：與應用開發辦公室對齊
拆分時要注意「無主」元件的風險——確保每個元件都有明確的負責團隊。
SRE 推廣#
優先考慮以下服務提供 SRE 支援：
- 可靠性對財務或聲譽有高度影響的服務
- 產品正常運作所需的最小可行服務集合
- 服務不應僅因為不可靠就成為 SRE 優先項——SRE 應策略性地應用於對業務最相關之處
地理拆分#
Google 通常在不同大洲建立姐妹 SRE 團隊，原因包括：
- 服務可靠性：一個團隊因重大事件無法運作時，另一個可以接手
- On-call 壓力：12 小時輪班允許合理的休息
- 招募與留才：與正常工作時間重疊的 on-call 輪班擴大了招募基礎
- 生產成熟度：跨站責任分擔推動了文件、培訓和標準化的改善
時區選擇：6 到 8 小時的時差效果最佳，可避免凌晨 0 點到 6 點的 on-call 輪班。團隊人員應盡量通過內部調動來建立新站。
避免「夜班」效應：確保非共置辦公室的團隊不會承擔過多 toil、只被分配較不有趣的專案。實務建議包括：
- 平衡兩地的 on-call 負載
- 將開發領域與特定辦公室的 SRE 團隊關聯
- 在兩個辦公室之間公平分配最有趣和最有影響力的專案
- 跨站拆分專案以促進辦公室間的互動
- 允許工程師定期出差到另一辦公室
三班制的問題：Google 嘗試過三個站點的拆分，但發現無法召開所有人都能參加的跨站生產會議、更難確保知識和能力的均等、減少了自動化低價值工作的動機。
管理多團隊的建議實務#
Mission Control#
Google 的 Mission Control 計劃讓產品開發工程師在 SRE 團隊中嵌入六個月，學習生產系統和實務，最終參與 on-call。部分工程師選擇留在 SRE，其他人帶著對生產環境的更好理解回到原團隊。
SRE Exchange#
SRE Exchange 計劃讓一位 SRE 花一週時間在不同的 SRE 團隊中工作，觀察工作方式並分享實務經驗，結束後撰寫出差報告。
培訓#
建立標準化的 SRE 培訓課程。Google 的所有新 SRE 都參加為期一週的沉浸式 SRE EDU 訓練，數月後再參加第二系列課程，涵蓋管理重大事件的通用工具和流程。
橫向專案#
由於 SRE 團隊緊密對齊特定服務，容易建立專屬解決方案，導致跨團隊的重複工作。Google 透過橫向團隊（通常由資深 SRE 組成）來建構和運行標準解決方案。
SRE 流動性#
確保 SRE 可以在團隊之間自由調動，這對個人和團隊都很健康：工程師可以找到感興趣的角色、在個人情況變化時調整、在新團隊中擴展經驗、維護不同辦公室間的文化一致性。
Production Excellence#
隨著 SRE 團隊數量增長，Google 定期進行 Production Excellence 審查，由資深 SRE 領導者評估每個團隊的頁面負載、Error Budget 使用量、專案完成率等標準指標，表揚優異表現並為表現不佳的團隊提供建議。
SRE 資金與招聘#
Google 的兩項實務：
- SRE 資金大部分與產品開發團隊的資金來源相同——可靠性是產品開發的核心支柱
- SRE 的供給始終小於需求，確保定期審查和優先排序接受 SRE 支援的服務
Google 的 SRE 與產品開發團隊工程師比例從約 1:5（低層基礎設施服務）到約 1:50（使用標準框架的消費者應用），多數服務在 1:10 左右。
結論#
任何規模的組織都可以透過以下三條原則實踐 SRE：
- SRE 需要有後果的 SLO
- SRE 必須有時間讓明天比今天更好
- SRE 團隊有能力調節自身的工作負載
這些原則已在 Google 多年的大規模實踐中，以及與客戶合作導入 SRE 的經驗中得到驗證，適用於不同類型和規模的組織。