簡介 (Introduction)
在數位服務無所不在的時代，系統的可靠性與安全性已成為基本要求。Google 的 (Site Reliability Engineering, SRE) 透過將軟體工程思維應用於系統維運，成功地支撐了全球最大規模服務的穩定運作，徹底顛覆了傳統的管理模式。本文將引導你探索 Google SRE 的核心理念與高效維運策略，透過權威著作開啟你的 SRE 學習之路。我們將主要參照三本 SRE 聖經：《網站可靠性工程》(SRE Concepts)、《網站可靠性工作手冊》(SRE Implementation) 和《建構安全可靠的系統》(Security Integration)。本文將聚焦於《網站可靠性工程》的第一章，涵蓋傳統 (Sysadmin) 方法與 SRE 之間的差異，以及 SRE 的核心原則。
「希望並非一種策略。」(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?)
傳統系統管理 (Traditional System Administration (Sysadmin Approach))
傳統的系統管理方法，雖然在某些情況下仍有其優勢，但也面臨著顯著的挑戰。
優點 (Pros)
- 實施容易 (Easy to implement)
- 人才庫廣泛 (Wide talent pool)
缺點 (Cons)
- 人力線性增長 (Linear Growth of Manpower)：系統複雜度與流量增加 （雲原生和微服務技術興起的背景），需要更多 (Sysadmins)，導致團隊規模與成本線性增長。
- 開發 (Dev) 與維運 (Ops) 之間的衝突 (Conflict between Development (Dev) and Operations (Ops))：開發團隊優先考慮快速發布功能，而維運團隊則優先考慮系統穩定性。這導致緊張關係，開發團隊規避流程，維運團隊實施更多檢查，損害組織效率。
Google 的系統管理方法：SRE (Google's System Administration Method: SRE)
Google SRE 將軟體工程的原則應用於系統維運，提供了一種更具擴展性和效率的方法來解決複雜的挑戰。- 核心理念 (Core Idea)：SRE = 由軟體工程師設計的維運團隊 (Operations team designed by Software Engineers)。SRE 將軟體工程思維應用於維運，傾向於編寫軟體來自動化任務，而非僅僅增加人力。
- 50% 自動化工作上限 (50% Automation Work Cap)：Google SRE 團隊嚴格限制最多 50% 的維運工作 (Ops Work)。這確保他們有足夠時間進行開發工作 (Development Work)，以自動化手動操作，持續優化系統。
- 錯誤預算 (Error Budgets) 的引入：為了解決開發 (Dev) 與 SRE 的衝突，引入了錯誤預算。一個系統的可靠性目標 (e.g., 99.99%) 並非 100%，因此允許一定量的停機時間。這個允許的停機時間就是
「錯誤預算」(Error Budget)。功能發布在預算範圍內是允許的；一旦預算耗盡，新的發布將暫停，直到系統恢復穩定。這將目標從「零故障」轉變為「在錯誤預算內最大化功能發布速度」(maximum feature release speed within the error budget)，促進了合作夥伴關係。
錯誤預算深度解析 (Error Budget Deep Dive)
- 錯誤預算是 SRE 核心策略之一，它重新定義了我們對系統可靠性的理解和管理方式。
概念 (Concept)
100% 可用性 (100% availability) 通常成本高昂且不必要。用戶無法區分 99.999% 和 100% 可用性，但實現後者會產生巨大的邊際成本。
想像你買了一台永不損壞的咖啡機，製造商保證它100% 不會壞。聽起來很棒？但這背後的代價是：這台咖啡機超貴，維修麻煩，還不能更新功能，因為任何改動都可能影響到它的「完美」。
確定「足夠好」的可靠性 (Determining "Good Enough" Reliability)
如何定義 SLO ，這是一個跨部門的產品策略問題，而非技術問題。
關鍵問題包括：
- 針對服務的定位，用戶希望的可用性到底是多高？
- 對於對服務可用性不滿意的用戶，有哪些替代方案可供選擇？
- 在不同的可用性等級下，使用者對產品的使用會發生什麼變化？
錯誤預算計算 (Error Budget Calculation)
一旦你搞清楚這些，就可以設定一個「夠用」的 SLO 目標，例如 99.99%。那麼，剩下那 0.01% 容許的故障時間，就是你的「錯誤預算（Error Budget）」
- 每月停機時間範例 (Monthly Downtime Examples)
- 99.99% SLO: 約 4 分 19 秒 (4.32 minutes)
- 99.95% SLO: 約 21 分 36 秒 (21.6 minutes)
- 99.9% SLO: 約 43 分 12 秒 (43.2 minutes)
錯誤預算是什麼？它可以幫你「買風險」
錯誤預算可用於
- 快速功能發布 (rapid feature releases)、
- A/B 測試 (A/B testing) 和
- 嘗試新的架構變革 (new architectural changes)。
每次的環境改動都有出錯的機會，但在預算範圍內，這些環境變更的風險是允許的。目標是策略性地允許錯誤，而不是完全避免它們。這彌合了開發團隊對速度的渴望和 SRE 對穩定性的需求之間的鴻溝。
SRE 的核心原則 (Core SRE Principles)
Google SRE 的成功基於一套明確的核心原則，這些原則指導著團隊的工作方式和決策過程。
確保對工程的持久關注 (Ensuring a Durable Focus on Engineering)
- 限制手動維運時間 (Limit Manual Ops Time)：50% 維運工作上限 (50% Ops Work cap) 防止人力線性增長，並確保有時間進行開發和自動化。
- 在超載時推回維運工作 (Push Back Ops Work When Overloaded)：當維運工作超出限制時，會將其退回開發團隊，激勵開發人員設計更穩定的系統。
變更速度與可靠性：錯誤預算 (Change Velocity and Reliability: Error Budgets)
- 100% 可用性不是目標 (100% Availability is Not the Goal)：可靠性目標 (SLOs) 應該是產品驅動的，而非盲目追求 100%。實現最後幾個「9」的可用性邊際成本是巨大的。
- 用錯誤預算協調衝突 (Coordinating Conflict with Error Budgets)：錯誤預算，計算為「1 - SLO」，讓 SRE 和開發團隊能夠協調在預算內最大化功能發布速度。當預算耗盡時暫停發布，確保穩定性。
監控 (Monitoring)
- 以行動為導向的監控結果 (Action-Oriented Monitoring Results)：監控輸出分為：
- 警報 (Alerts)：需要
立即人工干預。 - 工單 (Tickets)：需要人工干預但
非緊急。 - 日誌 (Logging)：
用於診斷或事後分析，預計無需立即人工審查。
- 警報 (Alerts)：需要
- 提倡監控自動化 (Advocating for Monitoring Automation)：SRE 強調監控系統應該自動判斷狀況，
僅在必要時通知人工。人類不應該花時間去解讀警報，而應該專注於處理需要立即介入的事件上。
緊急應變 (Emergency Response)
- 人工干預增加 MTTR (Manual Intervention Increases MTTR)：平均恢復時間 (Mean Time To Resolution, MTTR) 是關鍵效率指標。人工干預會增加延遲；理想系統應盡量減少此類延遲。
- 應急手冊和無責備文化 (Playbooks and Blame-Free Culture)：SRE 團隊準備
應急手冊 (Playbooks)以處理緊急情況，減少 (MTTR)，在警急情況時，有一個可以遵循的 SOP 進行排錯和修正系統，GOOGLE 內部統計，即使已經是最頂尖的工程師，是否使用Playbooks，在 MTTR 上也有三倍的差距。無責備事後分析文化 (Blame-free Postmortem culture)鼓勵從失敗中學習，並實施工程解決方案 (自動化、程式碼)，而非歸咎於人。
變更管理 (Change Management)
- 自動化變更流程 (Automated Change Processes)：部署 (更新、新功能) 是故障的主要原因。SRE 通過以下方式自動化部署：
- 漸進式發布（Progressive Rollouts）： 逐步將新變更部署到一小部分系統。
- 快速偵錯（Quickly and Accurately Detecting Problems）： 迅速發現問題。
- 安全回滾（Rolling Back Changes Safely）： 在問題發生時安全自動地回退版本。
需求預測與容量規劃 (Demand Forecasting & Capacity Planning)
- 準確的未來估計 (Accurate Future Estimation)：SRE 透過系統架構和平常的監控，推算未來資源消耗的需求，包括自然增長 (用戶) 和非自然增長 (行銷活動)，進行未來架構資源的拓展和規劃。
- 持續負載測試 (Continuous Load Testing)：定期負載測試確保硬體資源與服務容量之間的正確關係，已進行節費。
資源供應 (Provisioning)
- 資源供應作為高風險變更 (Provisioning as High-Risk Change)：資源配置涉及為系統增加新容量，這是一個風險較高的操作，因為它會對既有系統造成重大修改。SRE 謹慎處理，確保新配置在需要時能正常運作。
效率與性能 (Efficiency & Performance)
- 三個影響因素 (Three Influencing Factors)：服務效率受負載 (Load)、容量 (Capacity) 和軟體效率 (Software Efficiency) 影響。
- SRE 通過監控、需求預測、容量規劃和程式碼優化來控制成本和性能。
我的 TAKEAWAY
- 針對SRE 的核心原則的監控，真的感觸很深，無效告警不但無法解決問題，到最後值班的人員還會產生告警疲勞，真的發現服務問題，卻淹沒在告警通知中 。之前的經歷還在叡揚代理 dynatrace 的部門時，有客戶案例就是在客戶強烈要求下（已告知有告警疲勞的問題）將告警閾值設的很低，最終導致一天會發數千封告警信，而實際發現問題時，用戶根本不會去看那一些告警信了，反而是請我們協助或是教他們在平台上查找問題，這樣反而失去了告警的意義！
- 關於無效告警還不錯的 reddit 貼文討論，也放在下方。
- https://www.reddit.com/r/devops/comments/lh3wkw/what_are_your_best_tips_for_avoiding_alert_fatigue/
- 另外在目前的實務上擁有緊急事件的應對手冊（Playbook）也很重要，不論是公司有標準的流程，還是透過自己平常累積所撰寫的，能在系統有問題時更快的解決問題，在書中 google 內部的經驗，儘管 google 內的工程師幾乎都是最頂級的（清晰透徹的故障排除步驟和技巧），但有 應對手冊（Playbook）也至少減少了三倍以上的問題處理時間。
- 可以想像，如果是重要的服務造成 downtime，你根本沒有太多餘裕去一層一層的思考是網路層、應用層、還是哪一層面出現問題，cloudwatch insights query 應該怎麼寫去撈日誌，在時間緊迫的情況時，清晰透徹的應對手冊十分重要，至少馬上可以提供一些應急的解決辦法。
- 最後是基于公司產品的特性，應設立適當的 SLO 和 Error Budget，這是常常被忽略或是偷懶的部分，確實設立 Error Budget 可以讓開發和維運從傳統方式造成的對立關係脫離出來，成爲合作關係，甚至有時候 SRE 如果因應使用者增加，而需要改底層架構時，也有足夠的 SLO 和 Error Budget 等客觀的指標可以評估停機時間。
