#reliability

是不是 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

Producer acks? Broker 複本 / ISR Consumer commit 時機 ① 丟失 / 重複 ② 機器掛了會不會丟 ③ 重做 / 跳過

Kafka 的投遞保證:acks、ISR 與 at-least-once / exactly-once

· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #3

第二篇講完事件「怎麼擺、誰來讀」,留了一個更尖銳的問題:崩潰重啟後,一筆事件到底會被重複處理、還是漏掉?這篇把 Kafka 的可靠性講透 —— acks、複本與 ISR、commit 時機,以及 at…

#kafka#data-engineering#reliability