雲時代基礎設施的原則:壞了就重建,可靠性來自軟體
· tech
第一章說雲時代該擁抱變更,這章回答「憑什麼敢」。前提先翻轉:鐵器時代的可靠性是用錢買硬體——更貴的機器、雙電源、RAID、原廠保固;雲跑在海量便宜的 commodity 硬體上,供應商直白告訴你:任何一台機器、任何一個磁碟,隨時可能消失。 在這個前提下還想要可靠,只剩一條路——可靠性不再來自「元件不會壞」,而來自「壞了能多快變回好的」。整章的原則,全是為了把這條路鋪起來。
原則是一條因果鏈,不是一張清單
書裡的原則(假設系統不可靠、一切可重現、建立可拋棄的東西、最小化變異、任何流程都可重複)常被當成並列的口號背,但我讀完的體會是:它們是一條有方向的因果鏈——
這條鏈的讀法是由左往右的「依賴關係」:
- 任何流程都可重複:做過一次的事,要能用同樣的方式再做一次——這是最底層的紀律。手動修一次機器,就是在鏈條的源頭埋下一顆做不到重複的種子。
- 最小化變異:同一種需求只留一種解法。變異每多一種,上面每一層的成本不是加法,是乘法——十種 OS 版本配三種部署方式,你要維護的是三十條路徑。
- 一切可重現:前兩者到位,才可能「系統的任何部分都能從定義檔輕鬆重建」。這是消滅恐懼的原則——不敢動,本質上是因為弄壞了回不來。
- 建立可拋棄的東西:可重現之後,「修」就不再是唯一選項——直接砍掉,換一個新的上來。
- 於是「假設系統不可靠」不再可怕:元件會壞是常態,但壞了只是觸發一次例行重建。
牛,不是寵物
書裡引了那句流傳很廣的比喻:伺服器要當牛養,不是當寵物疼(cattle, not pets)。 這是「可拋棄」原則最好記的形狀:
判斷標準可以更狠一點:如果某台機器消失會讓你心痛,它就是寵物。 心痛的原因不是硬體多貴,是它身上累積了重建不回來的狀態——而那正是上一篇講的雪花與飄移的棲息地。可拋棄性不只服務故障恢復,也服務規模伸縮(縮容就是拋棄機器)和變更(升級就是換一批新的,而不是在舊的身上動手術)。
反思
「先恢復、再究因」是可拋棄性送你的禮物
寵物時代的 on-call,恢復時間取決於「多快找到病因」——SSH 進去、翻 log、試各種方法把它救活,壓力全在凌晨三點的腦袋上。可拋棄之後,恢復時間取決於「重建多快」,這兩者常常差一個數量級。這跟 SRE 事故處理的「先止血、再查根因」是同一個心法,但前提是基礎設施先給你這個選項:pod 砍掉重來、機器換新的上,壞的那台留著慢慢驗屍。我現在看一個團隊的維運成熟度,第一個看的就是這個:出事時他們的直覺是「修這台」還是「換一台」——直覺還在「修」,通常代表他們心裡清楚重建是不可靠的。
可重現要靠演習維持,不能靠信仰
「我們的機器都能從 playbook 重建」——這句話如果超過三個月沒驗證過,它就只是信仰。組態飄移不會通知你,它安靜地累積,直到你真的需要重建那天才攤牌,而那天通常是最糟的一天。所以我的立場是:可重現性要當成肌肉練,定期真的把東西砍掉重建一次——不敢做這個演習,本身就是最誠實的健康檢查結果。這也是打破恐懼螺旋的具體招式:與其猜自動化還跑不跑得動,不如讓「跑它」變成例行公事。
最小化變異是最難賣的原則,因為它擋人的興致
五個原則裡,技術上最簡單、政治上最難的就是最小化變異。工程師天然喜歡新工具——多一種資料庫、多一個語言、多一套部署方式,每一個提案單看都有道理。但維運成本是乘法:種類多一倍,要維護的路徑、要寫的自動化、要踩的坑就多一倍以上。我自己的做法是把「引進新種類」當成一個要付費的決策——誰引進、誰負責把它納入自動化、監控、備份、值班手冊,一路養到退役。這個規則一立,九成的「我們要不要試試 X」會自己消失;留下來的那一成,才是真的值得付維運稅的。