本章由 Niall Richard Murphy、Liz Fong-Jones 和 Betsy Beyer 撰寫，探討 DevOps 與 SRE (Site Reliability Engineering) 之間的關係。核心主張是：SRE 實作了 DevOps 所描述的哲學，兩者之間的共通點遠多於差異。

背景：營運的困境#

營運 (Operations) 作為一門學科，本質上是困難的。既有如何妥善運行系統的技術問題，也有如何管理營運團隊的組織問題。傳統企業常將營運視為成本中心 (cost center)，這種短視的做法使得有意義的改善變得困難甚至不可能。對此的不滿催生了 IT 領域的一場革命，而這場革命產生了兩個名字：DevOps 和 SRE。

DevOps 的背景#

DevOps 是一套鬆散的實踐、指引和文化，旨在打破 IT 開發、營運、網路和安全之間的孤島。其核心哲學可用 CA(L)MS 縮寫概括：

  • Culture（文化）：支持性的文化是一切的基礎
  • Automation（自動化）：透過自動化來改善流程
  • Lean（精實）：精實管理與持續交付
  • Measurement（量測）：透過客觀量測來建立事實基礎
  • Sharing（分享）：與同事分享改善成果，讓整個組織受益

DevOps 的關鍵理念#

  • 不再有孤島 (No More Silos)：打破傳統的開發與營運團隊分離架構，消除知識孤島和局部最佳化的負面影響
  • 事故是正常的 (Accidents Are Normal)：事故不僅是個人行為的結果，更是缺失安全防護的結果。與其懲罰犯錯者，不如專注於加速恢復
  • 變更應該是漸進的 (Change Should Be Gradual)：小而頻繁的變更比大批次變更更安全，搭配自動化測試和可靠的回滾機制，發展出 CI/CD 實踐
  • 工具與文化相互關聯 (Tooling and Culture Are Interrelated)：好的文化可以繞過不完善的工具，但反過來很少成立。文化勝過策略
  • 量測至關重要 (Measurement Is Crucial)：透過客觀量測來建立現實基礎，驗證變更是否如預期

SRE 的背景#

SRE 是由 Google 的 Ben Treynor Sloss 創造的術語和職位角色。如果將 DevOps 視為哲學和工作方法，那麼 SRE 實作了 DevOps 所描述的部分哲學 (class SRE implements interface DevOps)，並且更接近一個具體的職位定義。

SRE 的核心原則#

  • 營運是一個軟體問題 (Operations Is a Software Problem)：SRE 的基本信條是用軟體工程方法來解決營運問題，涵蓋從流程變更到消除單點故障等各種問題

  • 以 SLO 管理 (Manage by Service Level Objectives)：SRE 不追求 100% 可用性，而是由產品團隊和 SRE 團隊共同選定適當的可用性目標 (SLO)，並據此管理服務。SLO 違規時，團隊會以無責 (blameless) 的方式回到討論桌

  • 最小化苦差事 (Work to Minimize Toil)：任何手動的、結構性強制的操作任務都應被消除。如果機器能執行某項操作，那機器就應該執行。花在操作任務上的時間意味著無法花在專案工作上

生產的智慧 (The Wisdom of Production)：從實際生產環境中獲得的智慧——系統真實的行為方式，以及軟體應該如何設計——而非白板上與事實脫節的理想化服務觀點。

  • 自動化今年的工作 (Automate This Year’s Job Away)：Google SRE 有明確的上限——團隊成員最多只能花 50% 的時間在苦差事上。這與其說是上限，不如說是一種保障——確保以工程方法而非重複勞動來解決問題

  • 透過降低失敗成本來加速 (Move Fast by Reducing the Cost of Failure)：SRE 參與的主要好處不一定是提高可靠性，而是改善產品開發產出。縮短常見故障的平均修復時間 (MTTR) 能提升產品開發速度

  • 與開發者共享所有權 (Share Ownership with Developers)：打破「應用開發」與「生產環境」之間的僵化界線。SRE 和產品開發團隊都應對整個技術棧有全面的了解，沒有任何團隊應該獨佔某個組件

  • 使用相同的工具 (Use the Same Tooling, Regardless of Function or Job Title)：無論組織角色如何，維護服務的團隊都應使用相同的工具。工具分歧越大，每次改善單一工具所帶來的效益就越小

DevOps 與 SRE 的比較#

共同點#

  • 都需要接受變更是必要的這個前提
  • 協作對兩者都至關重要
  • 變更管理最好是小而持續的行動，且大多數應自動測試和應用
  • 正確的工具非常重要，但不應過度執著於特定工具；API 導向的系統管理哲學更為持久
  • 量測是兩者運作的核心——SRE 用 SLO 來決定改善行動，DevOps 用量測來了解流程產出
  • 兩者都實踐無責事後檢討 (blameless postmortems)
  • 兩者都是整體性的實踐，目標都是提升速度

差異#

  • DevOps 是更廣泛的哲學和文化，著重於打破組織中的障礙，但對如何在細節層面運行營運相對沉默
  • SRE 有相對狹窄的責任範圍，以服務和終端使用者為導向，帶來了一套有主見的智識框架（如 error budgets），但對孤島化和資訊障礙等主題相對沉默

SRE 和 DevOps 相信相同的事情，但出於略有不同的原因。SRE 支持 CI/CD 不一定是因為商業案例，而是因為改善的營運實踐。

組織脈絡與成功採用#

要成功採用 DevOps 或 SRE，組織中需要具備特定條件：

狹隘僵化的激勵會限制成功#

  • 不要將激勵措施狹隘地綁定在發布或可靠性相關的結果上
  • 讓團隊有自由找到正確的權衡
  • 早期 SRE 參與（理想情況下在設計階段）通常會使系統在部署後於生產環境中運行得更好

自己修復，不要歸咎他人#

  • 積極鼓勵工程師在需要時修改程式碼和配置
  • 支持無責事後檢討，消除掩蓋問題的動機
  • 允許支援團隊撤離操作上無可救藥的困難產品——這種威脅會激勵產品開發團隊修復問題

將可靠性工作視為專門角色#

  • 在 Google，SRE 和產品開發是獨立的組織，各有自己的重點和管理
  • 產品開發團隊透過成功時增加 SRE 新人來有效地資助 SRE 的成長
  • 不一定需要組織圖上的改變——只需要不同的實踐社群出現
  • 對於小型組織，完全撤離支援可能不切實際，但仍可採取 DevOps 風格的方法

「何時」可以替代「是否」#

  • 當組織或產品超過一定規模時，可以在支持什麼產品或如何優先排序方面行使更大的裁量權
  • SRE 與產品開發之間的強大夥伴關係至關重要：支援撤離或供應的決策可以基於客觀的營運特性資料

追求同等的尊重：職涯與薪資#

  • DevOps/SRE 組織應與產品開發同事享有同等的尊重
  • 各團隊成員應以大致相同的方法評估，並享有相同的財務激勵

結論#

DevOps 和 SRE 在實踐和哲學上都非常接近。兩者都需要討論、管理層支持和實際執行者的認同。實施任何一個都是一段旅程而非快速修復。簡單地重新命名團隊為 DevOps 或 SRE 而不做其他改變（rename-and-shame）不太可能產生效益。

  • SRE 因為是更有主見的營運實作方式，在旅程初期就有更具體的建議
  • DevOps 因為更廣泛的焦點，較難轉化為具體步驟，但也因此可能遇到較弱的初期阻力

最終，兩者的實踐者使用許多相同的工具、相同的變更管理方法和相同的資料驅動決策心態。無論我們被稱為什麼，我們都面對相同的持久問題：生產環境，以及如何讓它變得更好。

Backward Foundations Implementing SLOs Forward