SRE 是什麼?從 Error Budget 講起

「SRE」這個詞很紅,但很常被誤解成「高級一點的維運」或「會寫程式的 SysAdmin」。讀完 Google 這本書我的體會是:它的靈魂根本不在職稱,而在一個轉念 + 一個機制——「100% 可靠不是對的目標」,以及用 Error Budget 把「開發要快 vs 系統要穩」這場永恆戰爭,變成一道兩邊一起算的數學題。這篇是整個系列的脊椎,先把這兩件事講透。

SRE 是什麼:讓軟體工程師來做維運

Google 對 SRE 的原始定義很妙:「當你叫一個軟體工程師去設計維運團隊,會發生的事。」 一句話——把維運當成一個軟體問題來解,而不是用人力去堆。傳統維運遇到「事情變多」的答案往往是「加人」,人數跟著服務規模線性長;SRE 的答案是「寫程式把它自動化掉」,讓人力跟規模脫鉤。這個出發點,決定了後面所有實務的味道:能自動化的就別用人做、重複的手動操作被當成「待消滅的東西」而不是「認命要做的雜事」。

先破一個迷思:100% 可靠是錯的目標

大多數人直覺覺得可靠度當然是越高越好、最好 100%。但 SRE 的第一個反直覺是:追求 100% 不但不對,還有害。

為什麼 100% 是錯的?三個理由:成本——從 99.9% 每往上一個「9」,投入都要翻好幾倍;邊際效益——趨近於零;使用者根本感受不到——他家的網路、手機、Wi-Fi 本來就沒那麼穩,你把後端從 99.9% 拉到 99.999%,他那端的體感一點差別都沒有。所以正確的問法不是「怎麼不出錯」,而是「多可靠才算夠好」——訂一個目標(SLO,下一篇專講),剩下那段允許出錯的額度,就叫 Error Budget。

Error Budget:把 dev vs ops 的戰爭變成數學

Error budget 真正的威力,是它化解了一場幾乎每個團隊都在打的仗:開發想快、想多推功能;維運想穩、不想亂動。 這兩邊的目標天生對立,傳統上只能靠吵架、比職級、或 politics 決勝負。Error budget 給了一個客觀的公親:

機制很簡單:還有 error budget → 綠燈,可以大膽發布、上高風險功能,反正壞了還在預算內;預算燒光 → 紅燈,凍結所有新功能發布,全隊回頭把穩定度修回來。妙的地方是它讓兩邊利益一致了——維運不會再無腦擋所有變動(因為「還有預算」就沒理由擋),開發也不會再無腦硬推(因為燒光了大家一起被凍結)。大家都變成想「把有限的預算,花在最值得的功能上」。

反思

error budget 最強的地方,不是技術,是把「吵架」變成「看數字」

我在不同團隊都看過同一齣戲:要不要上這個有點風險的功能,開發和維運各執一詞,最後往往是誰嗓門大、誰職級高、誰跟主管關係好就贏。這種決策方式很消耗、也很不公平。Error budget 的設計之所以讓我拍案,是它把一個人的衝突,轉成了一個客觀的量化問題——「我們這個月的預算還剩多少?」兩邊不再是敵人,而是同一個預算的共同管理者。這是我看過最漂亮的「用機制化解人性衝突」的例子;它提醒我,很多團隊裡的爭執,根源是缺一把公認的尺,而不是缺道理。

「100% 不是目標」幾乎是所有工程判斷的通則

「別追求完美,追求夠好」這句話,遠不只適用於可靠度。過度追求任何指標——100% 覆蓋率、零技術債、極致效能——本質都是過度工程,把資源砸在邊際效益趨近零的地方。這跟我一直在講的 先確認痛點,再上重武器是同一種紀律:先問「多好才算夠」,再決定投入多少。 多數系統根本不需要五個九;把追求那兩個多餘的「9」省下來的力氣,拿去做真正會被使用者感受到的事,划算太多。SRE 用 error budget 把這個判斷制度化了,而我把它當成看任何工程取捨的預設問句。

SRE 的內核:維運可以、也應該被工程化

這本書最打動我的底層信念是:維運不是「認命要做的雜事」,而是一堆「還沒被工程化的問題」。 一旦你把重複的手動操作看成待消滅的 bug、而不是宿命,你的行為就變了——你不會再被 on-call 追著跑、疲於奔命,而會主動去想「這件事怎麼自動化掉、以後不用再有人半夜爬起來」。這個心態轉變,比任何工具或流程都重要,它決定了你是維運的奴隸還是主人。後面會講的消除 toil、監控、自動化,全都是這個信念的展開——而它的起點,就是這篇的 error budget:先量化「多穩才夠」,才談得上聰明地把力氣花在刀口上。