前言

在這個數位服務無所不在的時代，可靠性與安全性已成為最基本的期待。Google 所推動的 SRE（Site Reliability Engineering）體系，提供了一種以軟體工程思維為核心的系統運營方法，使全球級服務得以穩定運作並提升使用者體驗。

如果你曾好奇：SRE 的理論看似抽象，究竟如何在實務中落地？又該如何在保障系統可靠的同時，真正將「安全」融入整體設計？那麼以下三本書正好構成一條清晰的學習路徑，帶你從理念到實作，再到安全整合：

• 《Site Reliability Engineering》 — 理念篇：揭示 Google 如何透過 SRE 構建可靠基礎設施；
• 《The Site Reliability Workbook》 — 實作篇：具體案例與操作指南，教你如何實際部署 SRE；
• 《Building Secure & Reliable Systems》 — 安全可靠篇：教你如何在可靠性設計中完整納入安全機制。

更棒的是，這三本書都已由 Google 官方免費開放在線閱讀。這篇文章將聚焦於《Site Reliability Engineering》中的：

• Chapter 1 - Introduction

講解 傳統的系統管理方法（Sysadmin Approach）和 Site Reliability Engineering 的差別，和 Site Reliability Engineering 的核心原則有哪一些。

Hope is not a strategy.

It is a truth universally acknowledged that systems do not run themselves. How, then, should a system—particularly a complex computing system that operates at a large scale—be run?

傳統的系統管理方法（Sysadmin Approach）

過去業界普遍採用系統管理員 (Sysadmin) 的模式來運作系統。這個模式有其優點，例如易於實施、人才庫廣泛，但同時也存在根本性的問題：

• 人力的線性成長： 隨著系統複雜度和流量增加，運維工作量也隨之上升，因此需要增加更多的 Sysadmin，導致團隊規模線性擴大，成本也隨之增加。
• 開發（Dev）與運維（Ops）的衝突： 開發團隊追求快速發布新功能，而運維團隊則希望系統穩定，避免故障。這兩種截然不同的目標導致雙方經常處於「陣地戰」的緊張關係。開發團隊會繞過流程，而運維團隊則會設立更多審核門檻來保護系統，這種結構性的矛盾最終會傷害組織效率。

Google 的系統管理方法：SRE

為了打破傳統 Dev 與 Ops 的隔閡，Google 創造了 Site Reliability Engineering (SRE) 這個職位。SRE 的核心思想非常簡單：

• SRE = 軟體工程師設計的運維團隊： SRE 的核心是將軟體工程師的思維應用到運維工作中。這群人天生不喜歡重複的手動任務，因此他們會傾向於撰寫軟體來自動化這些工作，而不是單純地增加人力。
• 50% 的自動化工作上限： Google 嚴格限制 SRE 團隊的運維工作（Ops Work）比例不得超過 50%。這項政策的目的是確保 SRE 團隊有足夠的時間進行開發工作（Development Work），以撰寫程式創造能夠自動運作的系統，從根本上減少手動運維的需求。
• 錯誤預算（Error Budget）的引入： 為了化解 Dev 與 SRE 之間的衝突，Google 提出了錯誤預算的概念。系統的可靠度目標（例如 99.99%）並非 100%，這意味著系統可以允許一定程度的故障時間。這個允許的故障時間就是「錯誤預算」。只要開發團隊在預算內，就可以放心推出新功能；一旦預算用完，則需要暫停新功能發布，直到系統恢復穩定。這個機制讓 Dev 與 SRE 的目標從「零故障」轉變為**「在錯誤預算內追求最高的新功能發布速度」**，從而將雙方從對立關係轉為合作夥伴。

錯誤預算（Error Budget）

想像你買了一台永不當機的咖啡機，製造商保證它100% 不會壞。聽起來很棒？但這背後的代價是：這台咖啡機超貴，維修麻煩，還不能更新功能，因為任何改動都可能影響到它的「完美」。你真的需要它百分百不壞嗎？其實不太需要，因為你也不會 24 小時都在煮咖啡，而且就算壞個幾分鐘，你可能都沒注意到。

同樣的道理也套用在我們做的軟體服務上。雖然「零故障」聽起來很迷人，但 追求 100% 可用性通常既昂貴又沒什麼意義。因為就算你的服務達到 100%，用戶端、Wi-Fi、ISP(網路提供商) 或電力供應可能都撐不到 99.999%。使用者根本分不出 99.999% 和 100% 的差別，但內部的維運團隊為了那 0.001% 卻得花上無限的邊際成本，包含工時、人力和無限壓力。

所以問題來了：我們該追求多少「夠用」的可靠度？

這不是技術問題，反而是產品策略問題。你要問自己幾個問題：

• 針對服務的定位，用戶希望的可用性到底是多高？
• 對於對服務可用性不滿意的用戶，有哪些替代方案可供選擇？
• 在不同的可用性等級下，使用者對產品的使用會發生什麼變化？

一旦你搞清楚這些，就可以設定一個「夠用」的目標，例如 99.99%。那麼，剩下那 0.01% 容許的故障時間，就是你的「錯誤預算（Error Budget）」。

• 當可用性目標（SLO）設定為 99.99% 時，每個月可容許的中斷時間(錯誤預算)大約是 4 分鐘 19 秒（約 4.32 分鐘）。
• 當可用性目標（SLO）設定為 99.95% 時，每個月可容許的中斷時間(錯誤預算)大約是 21 分鐘 36 秒（約 21.6 分鐘）。
• 當可用性目標（SLO）設定為 99.9% 時，每個月可容許的中斷時間(錯誤預算)大約是 43 分鐘 12 秒（約 43.2 分鐘）。

錯誤預算是什麼？它可以幫你「買風險」

錯誤預算（Error Budget）可以用於快速上新功能、做 A/B 測試、嘗試新的架構變更。

• 每一次你冒險，都有機會出錯。但只要你不超過那個錯誤預算，這些風險就是「允許的」。

錯誤預算的核心：我們不是要做到不犯錯，而是要聰明地、策略性地容許錯誤。這樣，維運團隊跟開發團隊之間就不會吵成一團——開發團隊希望快點上新功能，維運團隊希望服務不要掛掉，錯誤預算剛好是這兩者的橋梁。

以前只要一出包，大家就開始指責：「你怎麼又 deploy 壞東西！」

現在反而變成一種「可控的實驗」：「這次我們花掉 0.002%，還有多少預算可以使用等等。」

SRE 的核心原則

SRE 擁有一套完整的運作準則，這些準則定義了他們日常工作的方式：

• 持續專注於工程工作（Ensuring a Durable Focus on Engineering）
  • 限制手動運維工時比重： 為了避免人力隨系統規模線性成長，Google 設定了 50% 的運維工作上限。這項政策確保 SRE 有足夠時間進行開發，以自動化重複性任務。
  • 運維工作超載時，回推給開發團隊： 當運維工作量超過上限時，SRE 團隊會將多餘的工作（例如解決 bug 或處理工單）回歸給開發團隊。這個機制能有效引導開發者設計出更穩定、更少需要手動介入的系統，形成正向循環。
• 變更速度與可靠性：錯誤預算（Error Budget）
  • 100% 可用性並非目標： 服務的可靠性目標（SLO，Service Level Objective）應該是基於產品需求來設定，而非盲目追求 100%。因為使用者無法察覺 99.999% 與 100% 之間的差異，而追求最後那一點點可用性需要付出巨大的邊際成本。
  • 用錯誤預算協調衝突： 錯誤預算（Error Budget）是「1 減去 SLO」得出的值，代表系統允許的不可用時間。擁有錯誤預算後，SRE 與開發團隊的目標不再是對立的，而是共同合作在錯誤預算內追求最高的功能發布速度（Feature Velocity）。當錯誤預算用盡，就必須暫停發布，直到系統恢復穩定。
• 監控（Monitoring）
  • 以行動為導向的監控結果： 監控的目的是為了讓人採取行動。SRE 將監控結果分為三類：
    • 警報（Alerts）： 需要立即人為介入處理的緊急事件。
    • 工單（Tickets）： 需要人為處理，但不緊急，可稍後處理的任務。
    • 日誌（Logging）： 純粹用於診斷或事後分析，不期待有人即時檢視。
  • 主張監控自動化： SRE 強調監控系統應該自動判斷狀況，並在需要時才通知人。人類不應該花時間去解讀警報，而應該專注於處理需要立即介入的事件。
• 緊急事件處理（Emergency Response）
  • 人工處理會增加平均修復時間（MTTR）： 評估應急處理效率的指標是平均修復時間（MTTR）。人為介入會增加延遲，因此理想狀況是避免需要人介入。
  • Playbook 與無責備文化： SRE 團隊會提前準備好應對手冊（Playbook），將緊急事件的處理步驟，避免即時通靈增加無謂的 MTTR ，並大幅縮短 MTTR。同時，Google 推廣無責備（Blame-free）的 Postmortem 文化，鼓勵團隊從故障中學習，找出根本原因，並透過工程方法(自動化、代碼化)解決，而不是互相指責。
• 變更管理（Change Management）
  • 自動化變更流程： 變更（版本更新、推出新功能）是導致故障的主因之一。SRE 透過自動化來管理變更，包含：
    • 漸進式發布（Progressive Rollouts）： 逐步將新變更部署到一小部分系統。
    • 快速偵錯（Quickly and Accurately Detecting Problems）： 迅速發現問題。
    • 安全回滾（Rolling Back Changes Safely）： 在問題發生時安全自動地回退版本。
• 需求預測與容量規劃（Demand Forecasting & Capacity Planning）
  • 精準預估未來成長： SRE 必須精確預測系統未來的需求，包含來自自然成長（使用者增加）和非自然成長（行銷活動）的需求。
  • 持續壓力測試： 透過定期對系統進行壓力測試（Load Testing），來確保硬體資源（如伺服器）與服務容量之間存在正確的關聯性。
• 資源配置（Provisioning）
  • 資源配置視為高風險變更： 資源配置涉及為系統增加新容量，這是一個風險較高的操作，因為它會對既有系統造成重大修改。SRE 必須謹慎對待，確保新配置在需要時能正常運作。
• 效率與效能（Efficiency & Performance）
  • 三大影響要素： 服務的效率受**需求（Load）、容量（Capacity）與程式碼效能（Software Efficiency）**三大要素影響。SRE 團隊透過監控、頻估需求、配置容量並優化程式碼，來有效控制運行服務成本和效能。

我的 TAKEAWAY

• 針對無效告警，真的感觸很深，不但無法解決問題，到最後值班的人員還會產生告警疲勞，真的發現服務問題，卻淹沒在告警通知中 。我還在 叡揚 代理 dynatrace 的部門時，有一個先前的案例就是客戶強烈要求下（已告知有告警疲勞的問題）將告警閾值設的很低，最終導致一天會發數千封告警信，而實際發現問題時，用戶根本不會去看那一些告警信了，反而是請我們協助或是教他們在平台上查找問題，這樣反而失去了告警的意義！
  • 有看到還不錯的 reddit 貼文討論，參考延伸閱讀 [1]。
• 另外在目前的實務上擁有緊急事件的**應對手冊（Playbook）**也很重要，不論是公司有標準的流程，還是透過自己平常累積所撰寫的，能在系統有問題時更快的解決問題，在書中 google 內部的經驗，儘管 google 內的工程師幾乎都是最頂級的（清晰透徹的故障排除步驟和技巧），但有 **應對手冊（Playbook）**也至少減少了三倍以上的問題處理時間。
  • 可以想像，如果是重要的服務造成 downtime，你根本沒有太多餘裕去一層一層的思考是網路層、應用層、還是哪一層面出現問題，cloudwatch insights query 應該怎麼寫去撈日誌，在回應高風險或時間緊迫的情況時，清晰透徹的應對手冊十分重要。
• 最後是基于公司產品的特性，設立適當的 SLO 和 Error Budget，這是常常被忽略或是偷懶的部分，但確實有 Error Budget 可以從 開發和維運傳統方式造成的對立關係拉出來，成爲合作關係，甚至有時候 SRE 如果因應使用者增加，而需要改底層架構時，也有足夠的 SLO 和 Error Budget 等客觀的指標可以評估停機時間。

參考連結:

1. Google SRE book- Comprehensive guide to site reliability

延伸閱讀

1. What are your best tips for avoiding alert fatigue?

This Content is Authored by the writer, with AI-assisted proofreading and SEO optimization.