維運中斷:殺死生產力的不是工作量,是被切碎的時間
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #17
On-call 那篇講「怎麼設計告警、誰值班」,Toil 那篇講「用 50% 護欄別讓維運吃光工程時間」。但這兩條之間,漏了一個每天都在發生、卻很少被當成問題來管的東西:中斷(interrupts)—…
#reliability
生產就緒審查(PRR):SRE 憑什麼接手一個服務
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #16
前面十五篇,講的幾乎都是「服務已經在線上了,怎麼讓它更可靠」——SLO、監控、postmortem、降級。但有一個更前面的問題一直沒問:一個新服務,憑什麼可以上線、憑什麼值得 SRE 接手扛 page…
分散式系統的麻煩:不可靠的網路、不可信的時鐘,與半死不活的節點
· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #8
上一篇結尾埋了個鉤子:當系統跨到多台機器,連「鎖」和「驗證」本身都變得不可靠。這章就是那個「不可靠」的總清算——也是我認為全書最該精讀的一章。核心一句話:單機世界是確定性的,要嘛全好、要嘛全壞;分散式…
Airflow 可靠性實戰:冪等、重試、SLA 與告警
· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #7
前面幾篇教你把 DAG 寫出來、排對區間。但 Production 的 DAG 是會在半夜出事的——來源系統延遲、網路抖一下、下游資料庫重啟。這篇講怎麼讓 DAG 扛得住失敗、能自己救、真救不了會大聲…
可靠的 cron:最單純的定時任務,一分散就變難
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #15
cron 大概是最單純的一種基礎設施:時間到,跑一個任務。單機上寫過 crontab 的人都覺得它理所當然。但只要加上兩個字——「可靠」(那台機器掛了,任務還是得照跑),它就從最簡單的東西,一夕變成一…
連鎖失效與過載:別讓一台倒下拖垮全部
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #10
第一篇說可靠度的目標是「出錯也能運作」。但有一種故障特別難纏,因為它會自我放大:一個小問題引發骨牌,幾分鐘內把整個系統拖垮——這就是連鎖失效(cascading failure)。它最可怕的地方,是系…
為可靠度測試:測試不是證明沒 bug,是讓你敢快
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #9
這篇講一個常被當成「開發的事」、其實是可靠度基石的東西:測試。關鍵觀念先講:可靠度不是靠「不改」得來的——你一定得改(修 bug、加功能、換設定),而每次改動都是一場賭。測試的意義,就是把這場賭變成有…
消除 Toil:把重複的維運當成待消滅的 bug
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #3
第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它…
SLI / SLO / SLA:一個量測、一個目標、一個合約
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #2
上一篇說 error budget = 1 − SLO。但 SLO 是什麼?它跟另外兩個幾乎人人混用的縮寫——SLI、SLA——又差在哪?這三個字分不清,可靠度就無從談起。一句話先記住:SLI 是你「…
SRE 是什麼?從 Error Budget 講起
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #1
「SRE」這個詞很紅,但很常被誤解成「高級一點的維運」或「會寫程式的 SysAdmin」。讀完 Google 這本書我的體會是:它的靈魂根本不在職稱,而在一個轉念 + 一個機制——「100% 可靠不是…
Kafka 的投遞保證:acks、ISR 與 at-least-once / exactly-once
· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #3
第二篇講完事件「怎麼擺、誰來讀」,留了一個更尖銳的問題:崩潰重啟後,一筆事件到底會被重複處理、還是漏掉?這篇把 Kafka 的可靠性講透 —— acks、複本與 ISR、commit 時機,以及 at…