本章從 SRE 團隊的視角出發，探討如何有效地與開發團隊和產品團隊建立合作關係，在服務生命週期的各個階段提供可靠性支援。SRE 原則的雙重目標是最大化開發團隊的工程速度，同時保持產品的可靠性。然而在微服務架構日益普及的今天，單一 SRE 團隊無法涵蓋所有服務，必須策略性地選擇投入重點。

服務生命週期#

SRE 團隊對服務可靠性的貢獻貫穿服務生命週期的所有階段。團隊可能在任何階段開始參與，不一定從頭開始。

Phase 1：架構與設計#

SRE 可在最早期影響系統架構，包括：

• 建立最佳實踐（如單點故障的韌性設計）
• 記錄特定基礎設施系統的注意事項，讓開發者避免已知陷阱
• 提供早期諮詢，討論具體架構與設計選擇
• 加入開發團隊參與開發工作，或共同設計部分服務

架構錯誤在開發後期修復的成本極高。早期 SRE 參與可避免系統面對真實使用者和成長需求時需要的昂貴重新設計。

Phase 2：積極開發#

產品成形期間，SRE 開始生產化（productionalization） 服務，包含：容量規劃、冗餘資源設置、尖峰與過載處理、負載均衡、監控告警與效能調校等。

Phase 3：有限可用性#

進入 Beta 階段後，使用者數量與使用強度增加。SRE 在此階段協助：

• 在 GA（General Availability）之前定義 SLO，提供客觀的可靠性衡量
• 建立容量模型、取得資源、自動化上線流程
• 確保監控覆蓋率並建立符合 SLO 的告警
• 與開發團隊共同分擔事件回應與操作工作

Phase 4：正式上線（GA）#

服務通過 Production Readiness Review（PRR）後接受所有使用者。SRE 執行大部分操作工作，但開發團隊應繼續承擔一小部分操作與事件回應，避免失去對這些面向的了解。可考慮讓一位開發者永久加入 on-call 輪值。

Phase 5：棄用（Deprecation）#

當更好的替代系統出現時，現有系統不再接受新使用者，工程重心轉向使用者遷移。SRE 在幾乎無需開發團隊參與的情況下運營現有系統，但實際上同時支援兩個完整系統，人力配置需相應調整。

Phase 6：被放棄（Abandoned）#

開發團隊通常恢復操作支援。SRE 以盡力而為的方式支援服務事件。

Phase 7：不支援（Unsupported）#

不再有使用者，服務已關閉。SRE 協助刪除生產配置和文件中的服務引用。

建立合作關係#

溝通業務與生產優先級#

SRE 需要深入理解產品和業務目標，並能清楚表達 SRE 參與如何幫助開發者實現這些目標。SRE 與開發團隊的領導層應定期會面，交流技術和優先級的挑戰。

識別風險#

SRE 團隊專注於系統可靠性，因此能有效識別潛在風險。準確評估風險的可能性和影響很重要，因為打斷正常開發和功能交付的成本很高。

對齊目標#

開發和 SRE 團隊都關心可靠性、可用性、效能、可擴展性與功能交付速度，但 SRE 更偏好服務的長期可行性而非新功能發布。兩個團隊應維持各自的焦點，同時明確支持對方的目標：

• SRE：「我們會支持你在安全範圍內盡快發布」（安全意味著在 error budget 之內）
• 開發者：承諾投入合理比例的工程時間修復和預防影響可靠性的問題

New York Times 的共享目標模型#

New York Times 的 SRE 團隊採用共享目標模型（shared goals model） 來平衡自動化積壓與團隊參與：

• 參與前先審查整體積壓，明確定義工作項目
• 優先考慮能同時減少 SRE 積壓的聯合參與
• 兩種參與模式：全職嵌入或兼職短期專案
• 共同撰寫目標並分解為里程碑
• 使用到期評估（point-in-time assessment） 衡量參與前後的成熟度差異

設定正確的期望至關重要。應強調應用程式擁有者（而非 SRE）直接負責對應用程式進行變更；SRE 的參與應產生公司層面的效益，避免一次性腳本開發。

設定基本規則#

每個 SRE 團隊有兩個主要目標：

• 短期：滿足產品的業務需求，提供穩定可用且可擴展的系統
• 長期：將服務運營優化到不再需要持續人工介入的程度，讓 SRE 團隊能轉向下一個高價值參與

團隊應就以下原則達成共識：

• 操作工作的定義與硬性上限
• 商定並衡量的 SLO，用於排序工程工作的優先級
• 商定的季度 error budget，決定發布速度和安全參數
• 開發者參與日常運營，確保問題可見並優先修復根本原因

規劃與執行#

建議在兩個層級進行規劃：

• 與開發領導層設定產品和服務的優先級，發布年度路線圖
• 定期審查更新路線圖，制定與之對齊的季度目標

路線圖不僅關注產品改進，也可涵蓋如何應用和改善通用 SRE 技術與流程以降低運營成本。

路線圖的缺失可能是一個信號：SRE 團隊可能需要合併、將服務管理工作交還開發團隊、擴大範圍或解散。

維持有效的持續合作關係#

投入時間改善協作#

• SRE 定期與對應服務的開發者會面
• 也應與上下游 SRE 團隊建立關係，以便在故障或分歧時快速升級

保持溝通暢通#

• SRE 每季向產品開發領導層提供**「生產狀態」報告**
• 開發者定期向 SRE 團隊提供**「產品狀態」報告**
• 讓雙方了解過去的成就與未來的方向

定期服務審查#

SRE 與開發團隊負責人每年至少面對面會議一次，分享未來 12-18 個月的路線圖。可搭配回顧練習，討論團隊想要停止、繼續和開始做的事情。

當基本規則開始鬆動#

當合作關係在任何約定領域出現倒退時，應根據緊急程度採取行動：

• 指定工程師放下低優先級任務，專注於問題
• 舉辦「可靠性 hackathon」
• 宣布功能凍結（feature freeze），大部分團隊專注於解決問題
• 技術領導層宣布產品可靠性面臨嚴重風險，全體動員

根據 SLO 和 Error Budget 調整優先級#

• 服務面臨錯過 SLO 的風險時，兩個團隊高優先級協作
• 服務在 SLO 範圍內且 error budget 充裕時，利用剩餘預算提升功能交付速度

妥善處理錯誤#

• 先冷靜再溝通：避免在疲憊或情緒高漲時進行後續對話
• 面對面解決問題：純粹透過 code review 或文件的互動容易變得冗長且令人沮喪
• 正向回饋：感謝他人的正面行為
• 理解溝通差異：不同團隊對資訊傳播有不同的內部期望

擴展 SRE 到更大環境#

單一 SRE 團隊支援多個服務#

Google 維持 SRE 與開發者的比例 < 10%。要將有限的 SRE 資源擴展到多個服務，這些服務最好：

• 屬於同一產品（提供端到端的使用者體驗所有權）
• 建立在相似的技術棧上（最小化認知負載）
• 由同一或少數相關開發團隊建構（減少關係管理成本）

建構多 SRE 團隊環境#

在 Google 內部，每個產品領域（PA）由多個產品群組組成，SRE 組織以層級方式對映開發者組織。分組方式有兩種：

• 按產品分組：減少與不同開發團隊的協調
• 按技術棧分組（如「儲存」或「網路」）：防止開發者重組時 SRE 團隊受到波動

建議按技術而非組織架構分組，以減少開發組織重組帶來的影響。

調整 SRE 團隊結構#

根據服務需求和工程/操作負載，透過建立、分拆、合併或解散 SRE 團隊來適應變化。偏好從現有團隊分拆而非從頭建立新團隊，以轉移文化和培養領導力。

運營分散式 SRE 團隊#

• 基於鄰近性和服務/技術相似性安排共址團隊
• 避免建立單人團隊
• 定期（每 12-18 個月）將全團隊聚集在一個地點
• 各地點之間輪換職責，避免將某項責任長期鎖定在單一地點

結束合作關係#

SRE 參與不一定是無限期的。當工作不再具有影響力，或大部分工作已偏向操作而非工程時，應重新評估。可能需要交還服務的情況包括：服務已優化至不再需要 SRE、服務重要性降低、服務即將停用。

案例研究 1：Ares#

Google 的 Abuse SRE 團隊與 Common Abuse Tool（CAT）團隊合作。濫用防禦需要快速適應性變更，這與 SRE 追求的計劃性開發產生衝突。

解決方案是在 CAT 內部建立專門的基礎設施團隊 Ares，通過交換計畫將生產管理知識從 SRE 轉移。Ares 重新設計了整個濫用防禦堆疊，轉向微服務模型，並建立抽象層讓開發者不需擔心底層生產細節。

成效：

• CAT 團隊擁有兼具生產知識和濫用防禦專業的「內部」專家，新功能上線時間大幅縮短
• Abuse SRE 從直接支援 CAT 中脫離，專注於底層基礎設施
• 開發速度提升，同時不影響可靠性

案例研究 2：資料分析管線#

有時維持 SRE 支援關係的成本高於其提供的價值。一個支援營收關鍵資料分析管線的 SRE 團隊在十年合作後面臨這個挑戰。

轉折點：開發團隊開始規劃新系統，高複雜度或高風險的變更被引導到新系統，現有系統的修改變得更加困難。

溝通斷裂：維護現有系統同時開發替代系統的壓力造成團隊間關係惡化。SRE 專注於舊系統維護，開發團隊專注於新系統，組織隔閡加深。

解散：最終將 SRE 和開發功能合併為單一團隊，讓管理層在新舊系統間靈活分配工程資源。雖然解散 SRE 團隊不是愉快的經歷，但消除了工程投入方向的持續張力。

如果工作關係更健康，SRE 會暫時交還生產工作，待系統穩定後再恢復責任。SRE 與開發團隊需要正面處理問題，識別需要重置的張力點。

結論#

SRE 參與的形式會隨服務生命週期的不同階段而變化。有效管理合作關係與做出好的技術設計決策同樣重要。建立有效關係的最佳實踐核心在於：共享的使命感和目標，搭配定期且開放的溝通。對於長期成功而言，投入時間對齊團隊目標和理解彼此的需求，與捍衛 SLO 同等重要。