週一大家好！今天繼續來閱讀第二條 SRE 方法論：在保障服務 SLO 的前提下最大化迭代速度，這裡是今天讀的原文出處：Introduction，話不多說，我們開始囉！

在保障服務 SLO 的前提下最大化迭代速度

產品開發部門和 SRE 之間可以通過消除組織架構衝突來構建良好的合作關係。在企業中，最主要的矛盾就是迭代創新的速度與產品穩定程度之間的矛盾。

首先我們先建立一個共識：

一般來說，任何系統都不應該一味地追求 100% 可靠。因為對用戶來說，99.999% 和 100% 的可用性是沒有實質區別的，詳情可參考系統可用性

在這種狀況下，「錯誤預算」這個概念就誕生了！錯誤預算的訂立是開發團隊和 SRE 團隊之間決策的準則，若在錯誤預算足夠的情況下，開發團隊才能繼續釋出新的功能；反之，若是錯誤預算不足，團隊就應該停下來好好審視是否需要先讓系統穩定可用後，再釋出新功能。

今日思考題

錯誤預算怎麼訂立呢？需要找誰來一起討論？

根據 Google 提供的意見，可以和業務部門和產品部門一起從以下三種面向來討論：

• 基於用戶的使用習慣，服務可靠性要達到什麼程度用戶才會滿意？
• 如果這項服務的可靠程度不夠，用戶是否有其他的替代選擇？
• 服務的可靠程度是否會影響用戶對這項服務的使用模式？

補充筆記：SLO、SLA、SLI 差在哪呢？

如果用一個相對關係來描述，會像是顧客與廠商協議簽訂 SLA，而協議內會標明 SLO 以及沒有達成 SLO 會獲得的懲罰，廠商會根據 SLO 列出 SLI，因此如果畫成圖，會是下面這張圖：

舉個例子，

• SLA：在重大的購票季節（如春節、暑假等）期間，我們保證所有可售票種的可用性不低於 99.9%，如果沒達成，需要罰款 XXX 元。
• SLO：
  • 可用性：在重大的購票季節（如春節、暑假等）期間，我們將致力於確保所有可售票種的可用性達到99.9%的時間。
  • 計算方式： 可用性% = （總時間 - 無法提供售票服務的時間）/總時間 * 100%。
  • 例外處理： 如果售票無法可用的情况是由於使用者端或網絡供應商的問題導致的，則此類情況不在可用性計算範圍內。
• SLI：每 1000 分鐘內票種可用的時間。在重大購票季節期間，將每分鐘的可用性測試結果進行加總，若總時間達到 999.9 分鐘，則視為達成這個 SLI。

小補充：SLO 在定義範圍的時候，是有時間限制的，時間可以是一個月、一季、半年等等。

後記

一開始聽到要訂立錯誤預算的時候一陣茫然，然後開始上網找一些指標做參考 XD。
今天看到不用盲目地追求 100% 可靠真是太好了，以前只要遇到系統故障都會很緊張，然後一股腦地投入在要解決的問題上。在理解了錯誤預算的機制之後，除了可以找到藉口（誒？），也不會一直陷入系統不穩定卻一直新增更多不確定因素的負向迴圈了，面對錯誤的心情，反而會像是發現新的寶藏一樣，迫不及待地想將事故寫成報告，然後歸類進維運平台中。好拉！前進第三條！明天見！

參考資料

• SRE中的SLA/SLO/SLI
• SRE and SLAs, SLOs, SLIs