🎯 什麼情境該想到我
當你「有幾台沒人敢動的機器，設定靠多年手動變更累積、沒有文件，壞掉就重建不回來」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：讓基礎設施重建比修復容易（make infrastructure easier to rebuild than to repair），出事時直接重建而不是修理，讓變異無法滲入生產環境。
適用門檻（不要誤以為這是大公司專屬）：這雖然是幾乎所有大型 web 營運（即超過一千台伺服器）都在做的事，但即使你的生產環境只有一台伺服器，也應該採用這個做法。
核心規則：
- 每當做生產變更（組態變更、打補丁、升級等），該變更必須被複製到所有生產與預生產環境，以及任何新建立的環境。
- 不要手動登入伺服器改東西。變更必須以「能自動複製到所有地方、且全部進版控」的方式進行。
- 可以靠自動化組態系統確保一致性（Puppet、Chef、Ansible、Salt、Bosh 等），或從自動化建置機制產生新的虛擬機／容器部署到生產，然後銷毀舊的或把它移出輪替。
- 不可變基礎設施就是後者：不再允許對生產環境做手動變更——唯一能做生產變更的方式，是把變更放進版控，然後從頭重建程式碼與環境。
兩種強制手段（防止不受控的組態變異）：
- 停用生產伺服器的遠端登入
- 例行地殺掉並替換生產實例，確保手動套用的生產變更被清掉
這些手段會驅使每個人用「正確的方式」——透過版控——來提交變更，系統性地減少基礎設施偏離已知良好狀態的途徑（configuration drift、fragile artifacts、works of art、snowflakes 等）。
配套：預生產環境必須保持最新，要讓開發者跑在最新的環境上。開發者常想留在舊環境，因為怕環境更新弄壞既有功能；但正因如此才要頻繁更新，才能在生命週期最早期就發現問題。
原文：「Although this is something that almost all large-scale web operations do (i.e., more than one thousand servers), we should also adopt this practice even if we have only one server in production.」（L4808–4810）
原文：「the only way production changes can be made is to put the changes into version control and re-create the code and environments from scratch. By doing this, no variance is able to creep into production.」（L4838–4841）
原文（Bill Baker，微軟 distinguished engineer 的 pets vs cattle 比喻）：「You name them and when they get sick, you nurse them back to health. [Now] servers are [treated] like cattle. You number them and when they get sick, you shoot them.」（L4813–4815）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 沒有可重複的環境建立系統就先做「禁止遠端登入」，只會讓事故無法排除；必須先有隨選環境與基礎設施即程式碼。
- 「重建比修復容易」的前提是所有建置素材都在版控裡，否則重建只是換一種方式失敗。
- 書中提到這也是水平擴充（horizontal scaling）的基礎——加機器進輪替就能擴容；若你的服務有大量本機狀態，先處理狀態外部化。
🔗 相關工具
- 隨選環境與基礎設施即程式碼（重建能力的來源，先有它才談得上不可變）
- 版本控管一切（版控是唯一合法的生產變更入口）
- 藍綠部署（用新實例替換舊實例的部署形態）
- DevOps手冊