昨天說我們這個系列要在 30 天內從 0 開始學會可觀測性，但今天我們要先把腳步放慢，不實際動手安裝工具，先從我們到底會看哪些指標開始。

三個常被搞混的名詞

在剛開始學習的時候，一定會查到幾個專有名詞，「SLI、SLO、SLA」，在面試的時候這也是常被問到的問題。其中 SLI 和 SLO 會貫穿這 30 天，隨時在心中想現在觀察的 SLI 是什麼，才不會被一堆指標搞得暈頭轉向。

• SLI（Service Level Indicator）：量出來的數字，代表我們實際上有多好，例如網頁在 300 毫秒內回完的請求比例
• SLO（Service Level Objective）：訂給自己的目標，代表我們該有多好，例如上面那個比例要 ≥ 95%
• SLA（Service Level Agreement）：跟客戶簽的合約，沒達成要賠錢，所以一定訂得比 SLO 寬鬆

SLA 比 SLO 寬鬆是刻意的。SLA 訂 99.9% 的話，SLO 可能訂 99.95%，中間那段差距就是你的反應時間——先自己發現問題，而不是等客戶拿著合約來找你。

SLI

根據我們的系統不同，會有不同需要關注的指標。像是網頁使用者關心的是載入延遲，以及服務會不會掛掉的可用性，資料庫看的就是讀寫的速度。挑選適合的指標是很重要的事情，不然我們拉一堆圖表只是看起來有在做事而已。
有一點要注意，這裡的指標是一個「比例」，像是延遲的 SLI 不是直接計算延遲多少秒的平均數，而是計算「在 300 毫秒內回完的請求數 ÷ 總請求數」。假設 100 個請求裡有 99 個花 50 毫秒、1 個花 10 秒。平均是 149 毫秒，看起來很健康。但那個等了 10 秒的使用者已經關掉頁面了。改成比例就明顯得多：「300 毫秒內回完的比例是 99%」——你一眼就知道有 1% 的人體驗很差。

SLI = 好的事件數 ÷ 有效的事件數

挑 SLI 的兩個原則

1. 從使用者的角度出發：使用者只在乎網頁有沒有出現得又快又正確，不會在乎 server 的 CPU 使用率有沒有過高。在這裡 CPU 使用率就不是一個好的 SLI。
2. 數量要少：一個服務通常挑兩到三個就夠，挑了太多不會有人去看，過多的指標也容易造成誤判或者是資訊重複。

SLO

SLO 是給 SLI 訂的目標值，例如可用性 SLI 在 30 天內要 ≥ 99.9%。
光看數字可能沒什麼感覺，我們可以把它換成具體的時間。

這張表最有用的地方是體感校正。99.99% 代表整個月只能壞 4 分鐘——這意味著出事時人為介入幾乎來不及，你必須有自動化的容錯機制。所以 SLO 不只是一個數字，它決定了你要蓋多貴的系統。

Error Budget

其實這個概念更像是一個思維上的轉換，不是要去達成某個目標，而是可以允許多少錯誤的發生。SLO 訂 99.9%，反過來就是 0.1% 的容錯率，用上面的表格來看，就是每 30 天可以有 43 分鐘。一次 deploy 出問題、發現到 rollback 可能要花 15 分鐘的時間，這樣算起來的話，等於一個月有 3 次出錯的機會。

透過這一點，我們可以利用這個預算剩下多少，去判斷當前系統穩不穩定。這其實是一個平常很容易吵架的問題：現在該衝新功能，還是該停下來修穩定性。當我們有 error budget 的餘裕時，我們可以大膽去上線風險比較高的變更，利用這個額度去試錯。預算燒完的話，大家就轉頭去維護系統修修補補。

另外我們也不會把 SLO 的目標訂到 100%，因為到 99.9% 要往上提一點就要花費非常多倍的資源和人力。再來使用者也感受不出這點微小的差別，追求 100% 只會導致你永遠無法去改動你的服務。

這個系列會用的 SLI 與 SLO

先寫在這裡，Day 6 的示範服務會照這個設計，後面每一天都會用到它：

SLO 僅設定在 99% 是刻意的：叢集跑在我的筆電上，會被我自己關機、被 Docker 重啟，訂太嚴只會得到一堆假的違規。SLO 要訂在「違規時真的會採取行動」的位置，訂太嚴格只會一直違規卻置之不理，那個數字就沒有意義了。

換算下來，我們每 30 天的錯誤預算是 7 小時 12 分——比前面舉例的 43 分鐘寬裕得多，這正是因為它跑在筆電上。

小結

今天沒有裝任何東西，但決定了三件事：要看什麼（SLI）、要好到什麼程度（SLO）、可以壞多久（Error Budget）。後面每一天要裝的工具、要畫的圖、要設的告警，都是為了回答這三個問題。

明天 Day 3 講三本柱——metrics、logs、traces 各自能回答哪一種問題。