Infrastructure as Code 是什麼?從「變更」的成本翻轉講起

開一個新系列:讀 Kief Morris 的 Infrastructure as Code,用的是第三版(2025)——副標從第二版的 Dynamic Systems for the Cloud Age 改成 Designing and Delivering Dynamic Systems for the Cloud Age,多出來的 Designing 正是這一版的重點,後面會講到。前一篇 Ansible 從雪花伺服器講起,講的是「一個工具怎麼解這個問題」;這本書則是把鏡頭拉遠——工具年年在換(CFEngine、Puppet、Ansible、Terraform……),但「用程式碼管基礎設施」背後的原則不會換。第一章回答最根本的兩件事:IaC 到底是什麼,以及為什麼雲時代的基礎設施非這樣管不可。

鐵器時代 → 雲時代:變更的成本翻轉了

書裡把基礎設施的歷史分成兩個時代,我覺得是全章最好的一個框架:

• 鐵器時代(Iron Age):基礎設施等於實體硬體。買機器、上架、接線,一次變更以週、月計價。變更又慢又貴,所以整套管理文化都在減少變更——預先做大設計、變更審批委員會、變更凍結窗口。錯不起,就少改。
• 雲時代(Cloud Age):基礎設施變成軟體。開一台機器是一次 API 呼叫,幾分鐘的事。變更本身變得又快又便宜——限制翻轉了,該最佳化的方向也該跟著翻轉。

書裡點出一個很普遍的病:很多組織已經上雲,管理文化卻還留在鐵器時代——開一台 VM 只要九十秒,但申請開這台 VM 的簽核流程要跑兩週。雲的速度被流程整碗吃掉,錢照付,好處沒拿到。

第三版的新戰場:從「要不要採用」變成「採用後的沉積層」

三個版本剛好對應三個階段:第一版(2016)在說服大家「基礎設施可以用程式碼管」,第二版(2020)在講雲時代該怎麼管,到了第三版,雲和 IaC 都已經是主流——新的問題反而是大家在數位轉型的浪潮裡衝太快,留下一大片蔓生、難以維護的基礎設施程式碼。 基礎設施程式碼一樣會累積技術債:複製貼上的 Terraform、沒人敢動的 module、改一個參數要動十個 repo。

所以副標才多了 Designing:這一版把重心從「採用」移到「把軟體設計的教訓——模組化、低耦合、可演進——用在基礎設施的程式碼庫上」,並回答基礎設施程式碼在整個平台策略裡的位置。用寫程式的類比說:前兩版教你「開始寫 code」,第三版教你「怎麼讓一個長大了的 codebase 不變成大泥球」。這也是我選第三版讀的原因——現在的痛點早就不是「要不要寫 IaC」,是「寫了三年之後怎麼收拾」。

IaC 的定義:把軟體工程的紀律搬到基礎設施上

書給的定義收斂起來是一句話:用管理程式碼的方式管理基礎設施——基礎設施寫成定義檔、進版本控制、由自動化工具執行,而且套上軟體工程的完整紀律:測試、code review、CI/CD。

關鍵在「紀律」兩個字。寫 script 自動化維運不是新鮮事,shell script 從 Unix 誕生就存在——IaC 的差別不在「有沒有寫 code」,而在基礎設施的變更從此走軟體的流程:有版本、可 review、可測試、可重現、可回滾。這也是為什麼書名不叫 Scripting Your Servers。

「要嘛快、要嘛穩」是假選擇題

反對自動化最常見的理由:「頻繁變更太危險,穩定要靠管制。」書直接引 DORA(Accelerate)的研究打臉:高績效組織是又快又穩,低績效組織是又慢又不穩——速度和品質不是二選一,是互相成就。衡量用的就是四個關鍵指標:

指標	量什麼
Deployment frequency	多常部署
Lead time	一個變更從提交到上線多久
Change failure rate	變更造成失敗的比例
MTTR	壞掉之後多快恢復

背後的機制其實很好懂:重審批的慢流程並不會讓變更更安全,只會讓變更累積成大批次——而批次越大、風險越高、出錯越難定位,形成惡性循環。反過來,小步、頻繁、每步都有自動化驗證的變更,批次小到出錯也好找、好回滾。穩定不是「少改」改出來的,是「常改而且每次都走同一條可靠路徑」練出來的。

自動化恐懼螺旋

第一章最扎心的一段。很多團隊明明有自動化工具,卻不敢對跑在線上的系統執行——因為不確定會發生什麼事。於是這次先手動改,組態飄移更大,自動化跟現況差得更遠,下次更不敢跑……

這個螺旋的殘酷之處在於:它不能靠「更小心」解,只能靠「更常跑」解。 自動化每天都在跑,定義和現況的差異就永遠只有一天份;三個月才跑一次,差異就大到沒人敢按下執行。信任是跑出來的,不是 review 出來的。

三個核心實踐

第一章結尾給出全書的骨架——IaC 的三個核心實踐,後面的章節全在展開它們:

1. 把所有東西定義成程式碼:不只伺服器,網路、DNS、權限、監控,全部進版本控制,可重現、可追溯。
2. 持續測試與交付每一份進行中的工作:不是寫完才驗,是每個小步驟都有自動化驗證跟著。
3. 用小而簡單、可獨立變更的元件組系統:小批次的前提是元件夠小、耦合夠低,才能各自獨立地改。

反思

「先建起來,之後再自動化」是我聽過最貴的一句話

書裡列的反對意見中,「build first, automate later」我最有感。我的經驗是:手動建的東西,三個月後就沒人敢動——從 console 點出來的資源沒有紀錄、沒有理由、沒有重現方法,它為什麼長這樣只存在當初那個人的腦袋裡。這跟 雪花伺服器 是同一件事,只是雲讓它更隱蔽:機器看起來是新潮的雲資源,管法卻是鐵器時代的手工藝。自動化債跟技術債一樣會生利息,而且利息用「恐懼」計價——欠越久,越沒人敢還。

半自動化比全手動更危險

恐懼螺旋我看過真實版,而且體會是:最危險的狀態不是全手動,是「有自動化但不敢跑」。 全手動的團隊至少知道自己在走鋼索,每一步都小心;有一份半年沒跑的 playbook 反而給人虛假的安全感——「我們有自動化」——直到某天真的執行,才發現它會把三個月來所有的手動修補全部蓋掉。所以我現在的立場很硬:一份自動化如果不敢隨時跑,它就不是資產,是負債。要嘛讓它成為唯一的變更路徑、頻繁地跑;要嘛刪掉,承認自己是手動維運,至少誠實。

跟 Error Budget 是同一個世界觀

「速度 vs 品質是假選擇題」這個主張,跟我在 SRE 讀到的 Error Budget 其實是同一個世界觀的兩面:SRE 用預算把「要快還是要穩」變成一道可以算的數學題,DORA 四指標則直接用資料證明快跟穩根本是同一群人做到的。兩本書共同的解法也一樣——小批次、快回饋、自動化的變更路徑,而不是用審批和凍結去買一個假的安全感。這也是我讀這本書想帶回團隊的判斷:下次有人提議「加一層簽核讓部署更穩」,我會先問——這層簽核會讓批次變小、回饋變快嗎?如果只是讓變更變慢、累積得更大,那它買到的不是穩定,是延後爆炸。