SRE — SLO與Error Budgets

1. Service Level Objectives(服務水準目標)
2. Error Budgets
3. Error Budget policies

服務水準目標SLO

SLO是基於組織的業務所產生的。原因是我們需要從客戶的角度來看，我們對客戶的服務保證是甚麼。唯有從客戶的角度或與客戶交流過之後，我們才能去訂出SLO的技術細節。

什麼是SLO?

SLO 是產品或服務運作良好程度的目標。SLO 與使用者體驗緊密相關 — — 如果我們滿足 SLO，那麼使用者就會滿意。而設定和衡量 SLO 是 SRE 人員的主要面向。最常使用的SLO通常是服務的可靠度(availability)。我們的產品或服務通常會有(也應該要有)數個SLO。所SLO最終目的是要讓終端服務的使用者有更好的體驗。

基本上所有事情的可靠性目標 100% 都是錯誤的。因為這是不切實際的，因為從技術工程的角度來說不會有完美這件事情。因為人本身就是不完美的，不完美的東西怎麼可能創造出完美的事物。

範例

假設我們決定公司的Web service的http request每個月的的成功率為99.9%，這就是我們定義出的SLO。如果這個月有一千萬次的http request，哪根據我們定義的SLO。哪該月的http request失敗次數就是1萬次，這個1萬次則是我們的error budget。

但如果下個月的如果超標我們的error budget，我們需要採取相對應的行動來彌補該落差。這個稱為error budget policy。

Error Budgets

然而我們不可使用傳統的心態來運用Error budget，而是應該採用正確的心態來對應。

錯誤心態的error budget:
我們的 SRE 有Error budget，因為超出error budget通常意味著某個地方的某人必須加班或回應非上班時間的問題。 一個月內未達到 99.9% 的 http request通常意味著可擴展性問題，因此「維運人員」需要做些什麼。

正確心態的error budget:
我們應該策略性地將每個月的Error Budget降至零，無論是用於功能發布還是架構變更。 這樣我們就知道我們正在以盡可能快的速度運作，而不會影響可用性。

但我們需要注意 — — 高風險部署或「大霹靂式」的變更有可能出現問題，因此Error budget會有更多的機會被快速消耗殆盡。組織應該使用精實原則來進行小批量的變更以讓Error budget可以保持在我們設定的範圍內。

Error Budgets Policy

在某些情況下即是用了精實原則來進行變更，還是有可能會超出我們的Error budget。可能是因為需要使用複雜的佈署模式，但Error Budget的修改則需要開發、維運與業務單位三方面的同意。

一旦真的超出Error Budget，組織應該停止發布新功能。 團隊的Sprint planning只能從待辦事項中提取事後行動項目。而開發團隊必須每天與 SRE 團隊開短暫的會議，描述代碼的改進。

總結SLO、Error Budget、Policy的五個維度: