題幹與適用場景
面試官可能問：「系統設計中，你如何用錯誤預算平衡可靠性與發布速度？」題目要求你說明 SLI、SLO、錯誤預算如何落地到發布、回滾、容量和團隊協作。它適用於 SRE、平台、後端和高階系統設計面試，尤其是題目包含高可用、頻繁發布或多團隊依賴時。
面試官在考察什麼
核心考察不是背出 99.99%，而是把使用者體驗目標轉成可計算的決策規則。Google SRE 將錯誤預算定義為 SLO 的剩餘空間，用來協調可靠性投入和創新速度；預算耗盡時，團隊應暫停普通變更，優先恢復可靠性。面試官還會看你是否考慮測量窗口、資料品質、漸進式發布和例外稽核。
先釐清這幾個問題
先問清楚使用者是誰、關鍵旅程是什麼、服務邊界在哪裡，以及目標是可用性、延遲、新鮮度還是正確性。再確認 SLO 的時間窗口、是否有多區域、依賴是否由其他團隊維護、發布是否可回滾。若題目沒有給數字，可以聲明假設，例如四週窗口、99.9% 可用性和按使用者請求計量。
30 秒回答框架
用五步回答：
- 先定義一個使用者可感知的 SLI 和 SLO。
- 計算窗口內的錯誤預算，並說明預算消耗來源。
- 把預算連接到漸進式發布、自動回滾和變更門禁。
- 預算耗盡時凍結普通變更，投入可靠性修復；對安全和緊急修復保留明確例外。
- 用復盤、依賴歸因和預算趨勢調整下一週期目標。
逐步拆解深度解法
1. 先從使用者結果定義 SLI
不要直接用伺服器 CPU 或平均延遲當作可靠性目標。對請求型服務，可以選擇成功請求比例和滿足延遲門檻的請求比例；對非同步任務，可以選擇準時完成率或結果新鮮度。指標要區分使用者受影響的失敗、內部重試和無效流量，否則預算會被雜訊消耗。
2. 選擇可解釋的 SLO 與窗口
例如四週內 99.9% 的有效請求成功，則允許約 0.1% 的有效請求失敗。窗口決定團隊對短時事故和長期趨勢的敏感度。多 SLO 服務要說明合併規則：關鍵使用者旅程可以設為發布阻斷條件，次要指標用於告警和規劃，不能把多個百分比簡單平均。
3. 把預算消耗歸因到變更
預算應記錄總量、消耗速率和原因。發布、設定、依賴故障、容量不足和誤報要分開標記。只有歸因可信，團隊才知道該修程式、調整容量、改變依賴契約，還是修正監控。Google 的示例策略還區分了本服務故障、外部團隊故障和不在 SLO 範圍內的流量。
4. 設計發布門禁與漸進式回滾
普通變更先進入小比例流量或單個區域，觀察錯誤率、延遲和預算燃燒速率，再擴大範圍。門禁應同時檢查目前預算餘額和短窗口燃燒率，避免月底平均值看似安全卻正在快速惡化。發現異常時先回滾，再診斷，以縮短恢復時間；回滾本身也要有冪等和資料相容方案。
5. 定義預算耗盡後的策略
預算耗盡不等於永遠停止開發。凍結普通功能和非必要資料變更，把容量、測試、依賴隔離、降級和根因修復列為優先工作。安全修復和解決導致 SLO 下降的緊急缺陷可以例外，但必須記錄原因、審批人和後續復盤，防止「緊急」成為繞過門禁的常態。
6. 處理依賴和跨團隊責任
服務的 SLO 不應把所有外部失敗都隱藏掉。記錄依賴錯誤、用戶端錯誤和本服務錯誤的維度，明確誰能修復、誰負責溝通。若兩個團隊的預算規則衝突，先對齊使用者旅程和共享指標，再透過服務負責人升級；不要把責任轉移當作可靠性策略。
高品質示範回答
以下回答為虛構示例，候選人應替換題目中的數字與邊界：
我會先為最關鍵的使用者請求定義成功率和延遲兩個 SLI，假設四週窗口內有效請求成功率 SLO 為 99.9%，預算就是 0.1% 的失敗空間。監控同時展示預算餘額、近一小時燃燒率和失敗歸因，排除不在服務責任範圍內的流量。發布採用單一區域小流量、逐步擴大，任何階段超過燃燒門檻就自動停止並回滾。預算正常時，產品和 SRE 可以在風險範圍內發布；預算耗盡時凍結普通變更，優先做容量、測試、依賴隔離和根因修復，安全修復保留有記錄的例外。每次事故做無責復盤，把修復項加入下一週期計畫。這樣發布速度由剩餘預算和即時風險共同決定，而不是由團隊偏好決定。
常見失分點
把錯誤預算當作可隨意花費的額度
預算表達的是使用者可接受的失敗空間，不是鼓勵製造故障的配額。回答必須說明使用者影響、窗口、燃燒速率和修復責任。
只給一個可用性數字
沒有 SLI 定義、統計範圍和時間窗口，99.99% 沒有決策意義。補充有效請求、延遲或新鮮度，以及如何排除無關流量。
預算耗盡後永遠凍結發布
這會忽略安全修復、資料遷移和恢復工作的現實。應列出例外條件、審批、回滾和復盤，並保證例外不會變成預設通道。
忽略漸進式發布和回滾資料相容
只說「監控後發布」不夠。需要描述流量階段、自動停止條件、回滾順序，以及新舊版本讀寫相容。
追問與進階練習
SLO 達標但近一小時燃燒率很高，你會允許發布嗎？
比較長窗口餘額與短窗口趨勢。若短窗口顯示持續消耗，應暫停擴大流量，先確認是否為真實使用者影響、突發流量或監控異常，再決定是否回滾。
外部依賴導致預算耗盡，自己的團隊也要凍結嗎？
先確認服務承諾是否包含該依賴故障，再按使用者旅程決定。即使責任在外部，也要保護使用者、啟動降級，並與依賴團隊共享證據；是否凍結本團隊變更要寫進事先約定的策略。
多個 SLO 同時失敗，如何確定優先級？
按關鍵使用者旅程、影響範圍、燃燒速率和可逆性排序。先處理會擴大故障或阻塞恢復的指標，再處理局部效能問題，並說明取捨。
產品經理要求在預算耗盡時繼續發布，你怎樣溝通？
把爭論轉成資料：展示預算餘額、使用者影響、回滾成本和候選修復時間，提出小範圍實驗或延後方案。若確有緊急商業原因，走記錄完整的例外流程，並約定復盤和補償可靠性工作。