今天的工作

明天開始，我們要逐步增加流向 Canary 的 HTTP request 百分比。今天先把 Burn Rate 這套放量／退版的判斷依據建立起來。

1. 引入 SLO（服務等級目標）的 Error Budget 概念
2. 從 Error Budget 引導出 Burn Rate 概念
3. 用動態的 Burn Rate 做為放量閾值

SLO、Error Budget 和 Burn Rate

SLO（Service Level Objective，服務等級目標）

是團隊對自己服務品質訂下的目標值，是公司內部拿來衡量「服務做得好不好」的一把尺。當我們設定 某個服務的某項功能的 SLO = 99.9%，代表這個功能的目標是「在某段時間內，最少 99.9% 的執行結果會成功」，反過來說，也就是「在某段時間內，允許 最多 0.1% 的執行結果以錯誤/失敗結束」。例如，我們替本專案 Canary 的 5XX 代碼定下「一星期內的 SLO = 99.9%」，就表示在流量導入 Canary 之後的一週之內，99.9% 的 HTTP request 不會產生 5XX 代碼，換句話說，允許 0.1% 的 HTTP request 產生 5XX 代碼。

Error Budget（錯誤預算／容錯額度）

就是這「允許失敗的 0.1%」，可以當成一筆可以花的預算額度：「只要失敗率沒有超過它（沒把額度花完），SLO 就還沒被違反」。這筆額度不只是被動承受的風險，也包含主動運用的資源——上新版本、做壓力測試，都是在花這筆預算，只要沒超支就沒關係。

Burn Rate：Error Budget 額度多久被燒光

Error Budget 是一筆額度，但重點不是「還剩多少」額度可以花費，而是 燒（花費）的速度有多快。同樣是「已經用掉一半額度」，花了一整週才燒到一半，跟半小時內就燒掉一半，代表的緊急程度完全不一樣。後者再燒下去，很明顯 Error Budget 撐不到這週結束就會被花完。

但這裡有個問題：真要等一整週燒完才知道有沒有超支，那早就來不及退版了。實際的做法是只看一小段短窗口（例如過去 1 小時）量到的錯誤率，拿來推算——如果這個速度一直持續下去，這一週的額度撐不撐得住？這個「推算出來的倍數」就是 Burn Rate：把短窗口量到的錯誤率，拿去跟「剛好能撐滿一整週」的速度比，算出來的倍數越高，代表照這個速度燒下去，額度會被燒光得越快。

舉例來說：error_budget_rate 是 0.1%。如果過去 1 小時量到的錯誤率是 0.3%，Burn Rate = 0.3% ÷ 0.1% = 3——代表照這 1 小時量到的速度燒下去，是「剛好燒滿一整週」速度的 3 倍，這一週的額度只要 1/3 週（大約 2.3 天）就會燒光。這是拿短窗口的觀察去推算整週的結果，不是真的等 2.3 天發生了才知道。

用 Burn Rate 做為放量的「動態閾值」

Burn Rate 是「實際錯誤率」相對於「額度容許速度」的倍數。1x 代表剛好照 SLO 允許的速度在燒。Day25 用來判斷能不能放量的門檻，會抓在 0.5x——比 1x 更保守，要求消耗速度連 SLO 允許速度的一半都不到，才安心繼續推進放量進入 Canary。

Day26 會設定一個高很多的 Burn Rate 倍數（3x）當自動退版的門檻。燒得比允許速度快 3 倍，代表問題嚴重到不能再等人工介入，要立刻把流量切回 Stable。放量看的是「夠不夠安全」，退版看的是「夠不夠嚴重」。這個 3x 是怎麼定出來的，Day26 會完整說明，這裡先不展開。

參考資料

• Google SRE Workbook — Alerting on SLOs：Burn Rate／Error Budget 這套「用消耗速度而非瞬時數值判斷健康」的概念。