#sre

你的服務 ① Latency 延遲 請求要多久才回? 分開看「成功」與「失敗」的延遲 ② Traffic 流量 系統現在多忙? QPS / 每秒請求數 ③ Errors 錯誤 多少請求失敗了? 失敗率(含「回 200 但內容是錯的」) ④ Saturation 飽和度 離極限還有多近? 資源用了幾成 → 最能預警 前三個 = 使用者體感(可直接當 SLI);第四個「飽和度」= 還能撐多久的預警

監控:四個黃金訊號

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #4

上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案…

#sre#monitoring

是不是 toil?看這六個特徵 ✓手動 —— 要人一步步動手做 ✓重複 —— 做過很多次、之後還會再做 ✓可自動化 —— 機器能做,只是還沒有人去寫 ✓無長期價值 —— 做完,系統並沒有變得更好 ✓隨規模線性成長 —— 服務變大,它就跟著變多 ✓被動反應 —— 被觸發才做,不是主動規劃出來的 符合越多 → 越是 toil。注意:開會、規劃、寫文件是 overhead,不算 toil

消除 Toil:把重複的維運當成待消滅的 bug

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #3

第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它…

#sre#reliability

99.0% 100% SLA 99.5% 對外合約·違反賠錢 SLO 99.9% 內部目標(拚這個) 違約區 沒達標(但還沒違約) 健康區 ← SLI 99.95% 實際量到的 安全 buffer:內部先痛,別讓客戶先痛 門檻鬆緊:SLA(鬆) < SLO(嚴) ≤ SLI(健康時的實測)

SLI / SLO / SLA:一個量測、一個目標、一個合約

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #2

上一篇說 error budget = 1 − SLO。但 SLO 是什麼?它跟另外兩個幾乎人人混用的縮寫——SLI、SLA——又差在哪?這三個字分不清,可靠度就無從談起。一句話先記住:SLI 是你「…

#sre#reliability

可靠度目標訂在 99.9%,不是 100% 剩下的 0.1% 不是遺憾,是可以花的「預算」 Error Budget = 1 − SLO 服務成功 ≥ 99.9%(SLO 目標) 失敗 ≤ 0.1% (刻意放大顯示) ≈ 一個月約 43 分鐘可壞 追到 100%:成本爆炸、邊際效益趨近零——使用者還分不出 99.9% 和 100% (他手上的網路、手機、Wi-Fi 本來就沒那麼可靠)

SRE 是什麼?從 Error Budget 講起

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #1

「SRE」這個詞很紅,但很常被誤解成「高級一點的維運」或「會寫程式的 SysAdmin」。讀完 Google 這本書我的體會是:它的靈魂根本不在職稱,而在一個轉念 + 一個機制——「100% 可靠不是…

#sre#reliability