頸上有時鐘:事故中的 AI——重播一場毒藥訊息事故
· tech · 約 12 分鐘 · 📚 帶 AI 的手藝(2026) #2
上一篇講了漏斗:AI 吃掉寬層的量,人守住頸口的責任。這一篇把漏斗搬到它最極端的測試場——事故。事故是頸上有時鐘的場景:主播在罵、營運在催,而你必須在資訊不全的情況下做決定。AI 不能替你決定要不要在…
#sre
維運中斷:殺死生產力的不是工作量,是被切碎的時間
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #17
On-call 那篇講「怎麼設計告警、誰值班」,Toil 那篇講「用 50% 護欄別讓維運吃光工程時間」。但這兩條之間,漏了一個每天都在發生、卻很少被當成問題來管的東西:中斷(interrupts)—…
生產就緒審查(PRR):SRE 憑什麼接手一個服務
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #16
前面十五篇,講的幾乎都是「服務已經在線上了,怎麼讓它更可靠」——SLO、監控、postmortem、降級。但有一個更前面的問題一直沒問:一個新服務,憑什麼可以上線、憑什麼值得 SRE 接手扛 page…
沒有 SRE 的年代:backend lead 的上線日記
· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #15
上一章講尖峰怎麼打;這一章講打仗的人。當年團隊沒有 SRE 這個職稱——身為 backend lead,infrastructure 的仗自然全落在我身上。這章是那段提心吊膽日子的日記:全部家當一台 …
可靠的 cron:最單純的定時任務,一分散就變難
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #15
cron 大概是最單純的一種基礎設施:時間到,跑一個任務。單機上寫過 crontab 的人都覺得它理所當然。但只要加上兩個字——「可靠」(那台機器掛了,任務還是得照跑),它就從最簡單的東西,一夕變成一…
SRE 空降一間『什麼都自建』的公司,前 90 天怎麼站穩
· tech · 約 7 分鐘 · 📚 Google SRE 讀書筆記 #14.5
換工作最刺激的一種,是加入一間幾乎什麼都自建的公司:沒有現成的雲服務、連 Stack Overflow 都幫不上忙——因為這裡的基礎設施、部署工具,全世界只有這一家在用。你過去累積的「某某工具怎麼設定…
分散式共識:一群會掛的機器,如何對同一件事達成一致
· tech · 約 7 分鐘 · 📚 Google SRE 讀書筆記 #14
一群機器要對「同一件事」達成一致——誰是 leader?這把鎖在誰手上?最新的值是多少?——聽起來很簡單,卻是分散式系統最難的問題之一。難在哪?因為機器會掛、網路會斷、時鐘不可信,而你要在這些前提下,…
負載平衡:先選對機房,再選對機器
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #13
一個請求從使用者送出到被處理,其實要通過兩層負載平衡,回答兩個不同層次的問題:去哪個資料中心? 進了之後分給哪台機器? 這兩層顧的事情完全不同,把它們分開看,負載平衡就清楚多了。 前端這層要處理的是「…
自動化、發布工程與簡單性:讓『改變』又快又安全
· tech · 約 5 分鐘 · 📚 Google SRE 讀書筆記 #12
自動化、發布工程、簡單性,乍看是三個不相干的主題。但把它們擺在一起,會發現它們在回答同一個問題:怎麼讓「變更」既快又不出事?SRE 的三招答案分別是——用機器一致地做、把上線做成可重現的流程、以及讓要…
資料管線與資料完整性:有備份不等於能還原
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #11
一個資料系統的可靠度,除了前面講的「服務不掛」,還有一層更根本的東西——資料本身不能不見、不能錯。這篇講兩件事:資料管線的可靠度,以及一個會顛覆你直覺的觀念:「有備份」不等於「能還原」。 資料管線(p…
連鎖失效與過載:別讓一台倒下拖垮全部
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #10
第一篇說可靠度的目標是「出錯也能運作」。但有一種故障特別難纏,因為它會自我放大:一個小問題引發骨牌,幾分鐘內把整個系統拖垮——這就是連鎖失效(cascading failure)。它最可怕的地方,是系…
為可靠度測試:測試不是證明沒 bug,是讓你敢快
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #9
這篇講一個常被當成「開發的事」、其實是可靠度基石的東西:測試。關鍵觀念先講:可靠度不是靠「不改」得來的——你一定得改(修 bug、加功能、換設定),而每次改動都是一場賭。測試的意義,就是把這場賭變成有…
事件應變:大事故真正的敵人是混亂
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #8
前面你學會了 on-call 止血、也學會了系統化除錯——但那是「一個人對付一個問題」。當一場大事故爆發(多人捲入、影響大、時間壓力高),你會發現最大的敵人往往不是技術問題本身,而是混亂。 技術問題總…
DevOps vs SRE:一個是介面,一個是實作
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #1.5
前一篇講完 SRE 是什麼,順手補一個超常被問、但其實是假問題的比較:「DevOps 和 SRE 有什麼不同?要選哪個?」之所以是假問題,是因為兩者根本不在同一層。Google 用一句很工程師的話破了…
Blameless Postmortem:把故障變成組織的學習
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #7
上一篇講怎麼找到 root cause——但找到之後呢?Postmortem(事後檢討) 就是把一次昂貴的故障,轉化成整個組織的學習:記錄發生什麼、影響多大、時間軸、真因、怎麼修的、怎麼防止再發生。而…
有效除錯:除錯是方法,不是天分
· tech · 約 3 分鐘 · 📚 Google SRE 讀書筆記 #6
上一篇說 on-call 被叫到先止血;但止完血,總得找出為什麼。這篇講除錯——而它最重要的一個觀念是:除錯不是靠天分或運氣,是一套可以學的系統化方法。 新手和老手的差別,不在「知道答案」,而在有沒有…
告警與 On-call:什麼時候該把人吵醒
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #5
上一篇結尾留了一句:什麼時候該把人吵醒?這篇回答。它其實是兩件事:告警(什麼該響、響到誰)和 on-call(被叫到的人怎麼健康地扛)。核心觀念只有一句:告警的目的不是「通知」,是「該有人動手了」。 …
監控:四個黃金訊號
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #4
上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案…
消除 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% 可靠不是…