What SRE Solves
歡迎來到 Site Reliability Engineering
Site Reliability Engineering（SRE）於 2003 年在 Google 誕生。Ben Treynor Sloss 接管一個小型運維團隊，並將其重新打造為由工程師而非人工呼叫器來管理生產環境的模式。這個成果後來成為大型網際網路服務運行的標準典範。
傳統運維團隊透過人工操作來維持服務運行：重啟伺服器、呼叫工程師、撰寫操作手冊，並期望一切順利。這種模式在規模擴大時就會失效。一支五十人的運維團隊無法手動重啟五千台伺服器。當規模超過一定程度，手動操作就會變成一種稅，耗盡所有可用的生產力時間。
SRE 翻轉了這個模式。 當系統規模成長時，SRE 不會雇用更多運維人員，而是聘請軟體工程師，並告訴他們：撰寫程式碼來自動化運維工作。你的工作就是將軟體工程應用在運維問題上。你的產出是自動化、監控，以及工程化的可靠性，而不是手動介入。
SRE 實務由三個基礎理念驅動：
- Service Level Objectives (SLOs)：事先約定的數值化可靠性目標
- Error budgets：SLO 的反面，用來承擔風險
- Toil elimination：任何隨系統規模線性成長的營運工作都必須消除
這三個理念會延伸至所有 SRE 實務：事後檢討（postmortems）、值班輪替、容量規劃、監控以及發行工程。
傳統運維與 SRE 的比較
為什麼傳統運維無法因應規模成長
典型的運維團隊會隨著所管理的系統呈線性成長。伺服器數量加倍，運維人員也必須加倍。這對小型部署在財務上或許合理，但在大規模環境下卻是災難：你無法靠不斷招聘來解決二次方成長的問題。
SRE 將運維工作上限設定為工程師時間的百分之五十。其餘一半時間必須用於工程工作：建立工具、自動化流程、消除讓運維時間達到百分之五十的 toil。若 toil 長期超過百分之五十，團隊必須將部分工作交還給開發團隊，或是增聘 SRE。這個百分之五十的規則可避免 SRE 團隊在持續壓力下退化成傳統運維團隊。
比較兩者的失敗模式：
- 傳統運維：更多事件導致更多手動回應，進而減少預防工作的時間，造成更多事件，形成惡性循環。
- SRE：更多事件觸發事後檢討，進而發現自動化機會，降低下一次事件的回應時間，形成良性循環（若運作得當）。
SLI、SLO、SLA
驅動生產環境的三個字母
沒有量測的可靠性只是表面功夫。SRE 將可靠性轉化為一個事先約定、大家都能驗證的數字。
服務水準指標 (SLI)：對服務行為的量測。範例：請求延遲、錯誤率、吞吐量、佇列深度。SLI 是你可以繪製成圖表的項目。
服務水準目標 (SLO)：針對 SLI 設定的目標值或範圍。範例：「在滾動 28 天視窗內，99.9% 的 HTTP 請求成功。」SLO 是你對自己與使用者承諾的可接受服務品質。
服務水準協議 (SLA)：具法律效力的合約承諾，通常包含違約時的財務罰則。範例：「若月可用性低於 99.9%，我們將退款 10%。」SLA 是由律師執行的承諾。
關鍵區別：你的 SLA 必須永遠比 SLO 寬鬆。若內部目標為 99.9%，對外合約也訂 99.9%，你將毫無緩衝空間。SRE 通常會將 SLO 設定得比 SLA 再嚴格一個「9」：目標 99.95%，合約 99.9%。此差距可吸收不可避免的壞週期。
Error Budgets: The Inverse SLO
從可靠性目標到工程決策
An SLO sets a reliability target. The error budget is what is left over: the amount of failure you can spend before missing the target.
If your SLO promises 99.9% success over 28 days, your error budget is 0.1% of requests, or about 40 minutes of complete downtime per month. That budget is yours to spend however you want: on planned releases, on experimental features, on chaos engineering, on tolerating a misbehaving dependency.
Error budgets reframe the dev versus ops conflict. Without a budget, every outage starts an argument about who shipped the bad change and how to prevent the next one. With a budget:
- Budget remains: ship faster, take more risks, run experiments. The budget pays for it.
- Budget exhausted: stop launching new features, freeze risky changes, focus on reliability work until the budget rebuilds.
This converts reliability from an emotional argument into a measurable resource. Engineers can spend the budget deliberately, like any other production input.
定義 Toil
什麼算作 Toil
並非所有運維任務都算作 toil。SRE 對 toil 有精確定義：手動、重複、可自動化、戰術性、無持久價值，且隨著服務規模成長而線性擴展 的工作。
這六項屬性必須全部成立。一次性資料遷移是手動的，但不具重複性，因此不算 toil。高階工程師設計新的服務架構雖屬戰術決策，但能產生持久價值，因此也不算 toil。
以下是符合 toil 定義的範例：
- 服務因記憶體洩漏當機後，手動重新啟動
- 事件處理時，將日誌片段貼到聊天頻道
- 填寫工單表單以佈建新的資料庫
- 手動執行季度容量報告
- 逐一核准例行部署請求
百分之五十規則 將 toil 上限設定為 SRE 工作時間的一半。若超過 50%，團隊必須將責任交還給產品團隊，或是增聘工程師，但目標始終明確：透過以工程化系統取代人工操作，將 toil 逐步降至零。
自動化不僅節省時間，更能徹底消除一類人為錯誤。負責佈建資料庫的腳本，不會在長時間輪班後遺漏步驟。
Toil 稽核推論
你的團隊追蹤時間分配。上季的時間分配為：30% 部署、25% 事件回應、20% 容量工作、15% 功能開發、10% 來自產品團隊的一次性請求。
值班衛生
工程師，而非呼叫器
值班伴隨著真正的代價。睡眠會被打斷，週末會被中斷，而未知問題所帶來的壓力也會累積。SRE 將值班視為一種有限資源，必須保持可持續，而非由最關心的人承擔的英雄式負擔。
健康的值班輪替遵循以下原則：
- 補償時間：值班時數應對應補休、額外薪資或同等福利。無償值班會讓團隊 burnout。
- 合理的輪替深度：六人團隊同時負責 primary 與 secondary，意味著每位工程師大約每三週輪值一次。兩人輪替會摧毀職業生涯。
- 告警量預算：Google SRE 書籍建議每十二小時班最多兩次 paging 事件。若超過此數字，團隊必須投入工程時間降低告警量，而非只是忍受。
- 僅保留可行動的告警：每一次 paging 都必須需要人類介入。若某個告警會被忽略、已自動化，或在正常運作時反覆觸發，就不應該存在。告警疲勞是一種可靠性缺陷。
- 跟隨太陽的交接：全球分散的團隊在時區邊界交接班次，讓沒有人需要在凌晨三點被叫醒，除非系統真的無法等到早上。
Blameless Postmortems
How Outages Become Improvements
每一次重大事件都會撰寫一份事後檢討（postmortem）：書面分析事件經過、原因、修復方式，以及防止再次發生的改善措施。事後檢討是 SRE 領域的複利：每一份文件都會為系統累積永久的可靠性。
Blameless（無責怪） 意指文件將失敗歸因於系統與流程，而非個人。若工程師執行了錯誤的指令，事後檢討會追問：為什麼系統允許該指令執行？為什麼沒有任何防護機制攔截？應該如何調整系統、文件或工具，才能避免下一位工程師重蹈覆轍？
無責怪文化只為一個目的而存在：人們在害怕懲罰時會隱瞞錯誤，而隱瞞的錯誤往往成為下一次事件。相較於累積未揭露的缺陷，無責怪文化的成本顯得微不足道。
事後檢討通常包含：
- Summary：事件與影響的一段摘要說明
- Timeline：逐分鐘重建事件時間軸（含時間戳記）
- 根本原因分析：導致故障的技術與流程因素
- 偵測：團隊如何得知事件，以及花費多少時間
- 解決：恢復服務所採取的行動
- 經驗教訓：哪些做法有效，哪些無效
- 行動項目：具體、負責人、時限明確的工程任務
行動項目會放在追蹤系統中。它們會像其他工程工作一樣被排定優先順序。沒有行動項目的事後檢討只會淪為故事分享，工作不會帶來任何改變。
四大黃金訊號
每個服務都必須衡量的指標
Google 的 SRE 書籍提出每個面向使用者的服務都必須暴露四種訊號：latency、traffic、errors 和 saturation。它們共同從使用者的角度描述服務健康狀態。監控訊號過少會留下盲點；監控數百個指標則會讓團隊陷入警報疲勞。
Latency：請求所需的時間。應追蹤分佈而非平均值。p50（中位數）描述典型體驗，p99 描述最差 1% 使用者的情況。單看平均值會掩蓋長尾：一個中位數 50 ms、p99 達 5,000 ms 的服務，平均值看起來正常，卻會讓每百位使用者中有一位體驗極差。
Traffic：服務所承受的需求。對網頁服務而言，指每秒請求數；對串流服務而言，指同時連線數；對批次作業而言，指每分鐘處理的項目數。流量與容量決策相關，也能揭示工作負載異常。
Errors：失敗請求的比率。明確失敗（HTTP 500）、隱含失敗（HTTP 200 但資料損毀）以及政策失敗（回應過慢而無法達到 SLO）都應計入。區分這些失敗類型很重要：帶有錯誤酬載的 200 回應，往往比誠實的 500 回應對使用者造成的傷害更大。
飽和度：系統運行的滿載程度。包含 CPU 使用率、佇列深度、記憶體壓力、連線池佔用率。飽和度可預測未來的延遲：當系統 CPU 使用率達到 95% 時，幾乎沒有剩餘空間，容易導致面向使用者的延遲突然上升。
大多數 SRE 告警都源自這四個訊號。以症狀為基礎的告警（當使用者會察覺時才觸發）優於以原因為基礎的告警（當 CPU 超過 80% 時觸發）。這四個黃金訊號描述的是症狀。
SRE 職涯路徑
SRE 技能的價值所在
SRE 職涯會依據工程師最喜歡的領域而分化：
基礎設施 SRE：建置其他團隊運行的平台。Kubernetes、服務網格、內部雲端。著重系統工程、分散式系統理論與平台設計。在大型公司薪資極高，因為工作具有規模效益：一位基礎設施 SRE 可支援數百位產品工程師。
嵌入式 SRE：與產品工程團隊合作，提升特定服務的可靠性。半工程師、半教練。強大的溝通與程式碼審查能力與技術深度同等重要。適合喜歡教學的工程師。
可靠性工具開發：建置可觀測性堆疊：監控、告警、儀表板、事後檢討工具、事件管理平台。著重前端與資料工程工作。成果供所有團隊使用。
生產工程：Facebook/Meta 用語，指專注於容量、部署與流量管理的 SRE。著重網路與系統工作。
值得取得的技術認證：Google Cloud Professional Cloud Architect、AWS Solutions Architect Professional，以及 CNCF 認證（Kubernetes Administrator、Kubernetes Application Developer）都能展現雲原生能力。Linux Foundation 的認證則代表系統層面的深度。這些認證無法取代作品集，但有助於通過招募人員的初步篩選。
總結
你現在已了解的內容
網站可靠性工程（SRE）最初是 Google 為了解決規模擴展問題而提出的方案，後來發展成業界普遍採用的專業領域。你已學習：
- 從手動操作轉向工程化可靠性
- SLI、SLO、SLA，以及與 SLO 相反的錯誤預算概念
- Toil 的定義、50% 規則，以及以工程方式降低 toil
- 永續的值班輪替制度，以及無責怪的事後檢討實踐
- 四大黃金訊號作為服務監控的起點
- SRE 職涯發展軌道，以及能開啟機會的相關認證
Two ideas matter most. Reliability is a number, agreed in advance. And toil is a defect, not a job description. Carry those two forward and the rest of SRE follows naturally.
Recommended reading: Google's SRE Book (free online: sre.google/books/), the SRE Workbook for hands-on exercises, and Charity Majors' writing on observability. The geometry-of companion lesson goes deeper on the visual structure underneath SRE practice: latency distributions, error budget cones, dependency graphs, and dashboard layouts.