題幹與適用場景
請設計一個為多服務計算 SLO、錯誤預算和 burn rate，並觸發可靠性門禁與告警的服務。你如何處理資料延遲、視窗選擇、靜默、回填和策略例外？
這道題適合 SRE、平台、後端和系統設計職位。Google SRE 將錯誤預算作為平衡可靠性與發布速度的協作機制；burn rate 告警關注預算被消耗的速度。重點是把定義、計算、告警、決策和稽核連成可驗證的系統。
面試官考察點
- 是否區分 SLI 事件、SLO 目標、合規期、錯誤預算和 burn rate。
- 是否能解釋快燃燒與慢燃燒視窗的互補關係及雜訊取捨。
- 是否設計事件去重、遲到資料、重複樣本、回填和版本化。
- 是否把告警與發布門禁、值班回應、靜默和人工例外分開。
- 是否為多租戶隔離、查詢成本、歷史可追溯和權限設計邊界。
- 是否以資料品質指標和回放驗證策略，而非只展示一張儀表板。
30 秒回答框架
「我會把服務拆成 SLO 規範、事件攝取、視窗聚合、預算計算、策略評估和通知稽核。每個 SLO 固定成功事件、總事件、目標、合規期與版本；burn rate 是目前錯誤率相對於允許錯誤率的倍數。用快視窗捕捉突發、慢視窗確認持續問題，告警帶上證據和資料新鮮度。遲到或回填資料只產生版本化重算，不靜默改寫已稽核的發布決定。」
分步驟深入解答
第一步：定義 SLI 與事件契約
SLO 規範應聲明服務、指標類型、成功事件、總事件、目標比例、合規期、聚合維度和時區。計數器必須有穩定的去重鍵和採集時間；錯誤分類要避免把用戶取消、依賴失敗和平台故障混在一個 SLI 中。規範發布後版本化，歷史計算引用當時版本。
第二步：計算預算與燃燒率
若目標為 99.9%，合規期內允許的錯誤比例為 0.1%。目前視窗錯誤率除以允許錯誤率得到 burn rate；數值為 1 表示按預算速度消耗，數值大於 1 表示更快。儲存原始計數與聚合結果，保留分子、分母和時間邊界，便於重算而不是只存百分比。
第三步：組合快慢視窗
快視窗能迅速發現發布造成的尖峰，慢視窗能確認影響持續存在。策略記錄兩個視窗的長度、burn-rate 閾值、最小事件量和觸發次數；只有資料新鮮度和分母規模符合條件才觸發。不同服務可以有不同策略，但預設範本應明確目的，避免把所有告警壓成一個閾值。
第四步：處理遲到、重複與回填
攝取層按事件 ID 或時間桶冪等，聚合工作保存水位和校正版本。遲到資料進入允許的延遲範圍並觸發重算；超出範圍則標記資料不完整。回填不能無聲改變已發出的通知或門禁，系統應記錄舊值、新值、操作者、原因和受影響的決策 ID。
第五步：連接告警、門禁與人工例外
告警服務負責通知和升級，發布控制器負責暫停或要求批准，策略服務只輸出帶證據的狀態。例外必須有範圍、過期時間、審批人和理由；靜默只抑制通知，不得停止預算計算。每次門禁決定攜帶 SLO 版本、視窗、計數、資料新鮮度和規則版本，便於稽核。
第六步：保證規模與可觀測性
按服務、區域和租戶分片聚合，限制高基數維度並快取重複查詢。監控攝取延遲、遺失率、重複率、聚合滯後、計算耗時、通知成功率和策略評估錯誤。用歷史回放驗證快慢視窗，用故障注入驗證從事件到告警和門禁的端到端延遲；資料不完整時顯示不確定，而不是顯示健康。
取捨、邊界與資訊增益
錯誤預算服務的核心增益是把可靠性目標轉化為可稽核的工程決策。燃燒率越敏感，雜訊和告警負擔越高；視窗越長，回應越慢。系統應把計算事實、通知動作和發布決策分離，並允許回填重算但保留歷史版本。它不替團隊決定優先級，只提供共同證據。
高品質示範回答
「我會先建立版本化 SLO 規範，定義成功與總事件、目標、合規期、維度和去重規則。事件進入冪等攝取層，按服務和視窗保存分子、分母、時間邊界與水位；聚合層計算錯誤率、允許錯誤率和 burn rate。策略層用快視窗發現突發、慢視窗確認持續影響，並檢查最小樣本量與資料新鮮度。
通知、發布門禁和人工例外是三個消費者。通知可以靜默，但預算計算繼續；門禁輸出帶 SLO、視窗、計數、規則和資料版本的證據；例外必須審批、限時並可追溯。遲到資料觸發版本化重算，不能悄悄改寫已發出的決定。
規模上按服務、區域和租戶分片，限制高基數標籤，監控攝取延遲、重複、遺失、聚合滯後和通知成功率。用歷史回放與故障注入驗證策略。資料不完整時標記不確定並升級，而不是把缺失當成零錯誤。」
常見錯誤
- 只存 SLO 百分比 → 無法解釋樣本量和邊界 → 保留分子、分母、視窗和水位。
- 一個閾值覆蓋所有服務 → 不同風險和流量會產生雜訊 → 按目標、樣本量和視窗版本化策略。
- 靜默等於停止計算 → 團隊會失去預算事實 → 僅抑制通知，繼續計算並稽核。
- 遲到資料直接改歷史 → 發布決定無法復盤 → 版本化重算並保留舊、新值。
- 把缺失資料當健康 → 採集故障被掩蓋 → 顯示不確定並觸發資料品質告警。
- 門禁直接依賴通知狀態 → 通知重試會改變發布結果 → 門禁讀取不可變評估證據。
追問及應對
為什麼需要快視窗和慢視窗？
快視窗降低突發故障的發現時間，慢視窗過濾短暫雜訊並確認持續預算消耗。兩者組合比單一視窗更能平衡回應速度和誤報，但閾值必須結合事件量驗證。
回填後 burn rate 變了，舊告警怎麼辦？
保留舊評估和通知記錄，建立帶新資料版本的重算結果，並標註是否改變目前門禁。不要刪除歷史；值班人員需要知道當時系統依據的事實。
如何防止高基數維度拖垮系統？
限制可用標籤集合，對租戶或路徑做分層取樣，按需物化高價值切片，並為查詢設定成本和逾時。核心服務級 SLO 不能依賴無限維度才能成立。
例外策略如何避免永久繞過門禁？
例外必須綁定服務、變更或時間範圍，要求審批人、理由和自動過期；過期後恢復預設策略，並把例外覆蓋率納入稽核指標。