題幹與適用場景
服務的 SLO 是可用性 99.99%，月度錯誤預算為 0.01%。本月使用者側失敗率已超過預算，團隊仍有一項影響大客戶續約的功能等待發布。請說明如何定義指標、判斷預算是否確實耗盡、決定哪些變更暫停，以及怎樣恢復發布節奏。
Google SRE 將錯誤預算視為 SLO 允許的失敗空間：預算未耗盡時，團隊可在合理範圍內發布；預算耗盡後，通常凍結變更，保留緊急安全修復和解決目前事故的修復。這是風險決策輸入，不是無條件的產品禁令。
面試官考察點
高品質回答會從使用者體驗定義 SLI，再把錯誤預算與發布、回滾和恢復時間綁定。面試官會追問：伺服器指標為何不能代表使用者可用性、短暫尖峰與持續消耗如何區分、緊急功能如何證明值得破例，以及誰有權解除凍結。
只說「預算耗盡就停止所有開發」忽略安全修復、資料完整性和合規義務；只說「業務重要所以照常發布」又放棄了共同的風險語言。
回答前需要釐清的問題
使用者影響與指標邊界
確認 SLI 是否來自真實使用者路徑，是否包含客戶端、依賴和關鍵工作流。區分請求失敗、延遲、資料錯誤和不可用；一個聚合平均值可能掩蓋尾延遲或某類客戶的嚴重故障。
預算窗口與消耗速度
確認預算按月、季度還是滾動窗口計算，當前消耗速率和不確定性是多少。預算餘額應能回答「還能承受多久」，而不只是顯示一個百分比。
發布價值與風險
評估功能帶來的收入、合規或安全價值，發布是否可灰度、可回滾、可限制租戶。沒有可驗證收益與回退路徑時，不應用客戶壓力替代風險證據。
30 秒回答框架
「我先驗證使用者側 SLI、SLO 窗口和錯誤預算消耗，確認是持續問題還是採集誤差。若預算確實耗盡，預設暫停非必要發布，把容量和工程投入轉向恢復 SLO、修復根因和驗證監控。安全、合規或修復事故的變更可以例外，但要小範圍、可回滾、有明確負責人。對大客戶功能，我會嘗試隔離租戶的灰度或延遲發布，並用風險評審決定是否破例。恢復到約定的預算餘量後，再逐步恢復常規發布，並複盤 SLO 是否真正反映使用者價值。」
分步驟深入解答
第一步：把 SLI 定義成使用者結果
為核心工作流定義成功率、端到端延遲和正確性，優先使用客戶端或入口層資料。明確有效請求、維護窗口和多租戶分層，避免把內部健康探針當成使用者體驗。若使用者關心匯出完成時間，單獨建立工作完成 SLI，而非只看 API 200。
第二步：計算預算與消耗
99.99% 可用性表示給定窗口允許 0.01% 的失敗比例；具體可容忍分鐘數取決於窗口長度和統計方式。用統一查詢計算剩餘預算、消耗速率和信賴區間，並標註資料延遲。預算異常時先排除重複計數、採集遺漏和依賴歸因錯誤。
第三步：建立發布閘門
預算健康時允許常規發布，但仍要求自動回滾和監控。預算接近耗盡時提高評審級別、縮小批次和灰度比例。預算耗盡後凍結非必要變更，只允許故障修復、資料完整性、嚴重安全或合規風險的變更，並要求可回滾驗證。閘門規則寫入發布工具和責任矩陣，避免依賴口頭共識。
第四步：評估破例請求
對每個破例記錄使用者收益、風險、受影響租戶、暴露比例、回滾條件和觀察窗口。能否隔離到單一租戶、影子流量或內部使用者，是降低風險的重要證據。產品負責人、變更負責人和 SRE 共同簽署，不能由銷售承諾單獨決定。
第五步：優先恢復而非追求指標完美
凍結期間先修復根因、容量瓶頸和監控盲區，設定恢復 SLO、錯誤預算餘量和截止時間。若 SLO 過於嚴格導致長期英雄式操作，應在複盤中調整目標，但不能為了發布而事後修改窗口或排除失敗請求。
第六步：向客戶與團隊溝通
用受影響工作流、時間範圍、目前緩解措施和下一次更新點說明決策。對客戶功能提供可驗證替代方案或時間表，不承諾未經驗證的恢復時間。內部以同一份預算看板、事件時間線和負責人清單溝通，減少產品與工程之間的政治爭論。
第七步：恢復後的複盤與治理
預算恢復到約定閾值後分階段放開發布，先小批次再擴大。複盤變更失敗、偵測延遲、回滾耗時和客戶影響；若 SLO 沒有代表使用者價值，提出有資料支援的調整。保留凍結、破例、批准和結果記錄，便於季度風險審查。
高品質示範回答
我不會先憑「銷售很急」或「預算歸零」做絕對決定。先確認使用者側 SLI、統計窗口、資料完整性和預算消耗速度，排除採集錯誤與重複計數。若預算確實耗盡，預設凍結非必要發布，把容量、修復和監控投入到恢復可靠性；安全、合規、資料修復和緩解當前事故的變更可申請例外。
大客戶功能若必須推進，我會優先隔離租戶、使用小比例灰度、設定自動回滾和明確觀察窗口。產品、變更負責人和 SRE 共同批准，記錄收益、風險和停止條件。預算恢復後逐步解除凍結，複盤 SLO 是否衡量真實使用者結果，再調整目標或發布流程。
常見錯誤
- 錯誤表現： 預算耗盡後凍結所有變更。→ 失敗原因： 安全修復、資料修復和事故緩解可能被延誤。→ 修正方法： 定義有限例外、審批人和回滾證據。
- 錯誤表現： 只看伺服器平均延遲。→ 失敗原因： 無法代表客戶端失敗、尾延遲或關鍵租戶體驗。→ 修正方法： 從使用者工作流定義端到端 SLI。
- 錯誤表現： 為了上線而修改 SLO 窗口或排除失敗請求。→ 失敗原因： 預算失去可比性，風險被隱藏。→ 修正方法： 保持當前窗口，複盤後按正式治理流程調整。
- 錯誤表現： 用一次成功灰度證明可以全面發布。→ 失敗原因： 暴露比例、依賴和長尾風險不同。→ 修正方法： 分階段擴大並保留自動回滾。
追問及應對
追問一：99.99% 的錯誤預算是多少？
在固定窗口內允許的失敗比例是 0.01%；換算成分鐘必須說明窗口長度、統計口徑以及按請求還是時間計算。面試中應強調預算是速率與剩餘量，不要脫離窗口給無條件數字。
追問二：銷售承諾的功能屬於例外嗎？
商業價值不足以自動破例。需要證明使用者影響、收入或合規風險，提供隔離、灰度、回滾和觀察證據，並由產品、變更負責人和 SRE 共同批准。若無法降低暴露，應延期並提供替代方案。
追問三：預算計算可能有誤怎麼辦？
凍結高風險發布，同時檢查埋點覆蓋、重複計數、時間延遲、依賴歸因和客戶端樣本。修正資料後重新計算，但結果不明時不應繼續擴大暴露。
追問四：何時調整 SLO？
在穩定運行和複盤資料表明目標與使用者價值、成本或能力不匹配時調整。變更前記錄舊目標、新目標、影響和批准人；不能把一次事故或發布壓力作為臨時調低目標的理由。
追問五：怎樣判斷凍結已經結束？
預先定義恢復條件，例如連續觀察窗口內 SLI 達標、預算重新累積到閾值、根因修復已驗證、回滾路徑可用。達到條件後先小批次發布並持續監控，而不是瞬間恢復全速。