環境的期望狀態應由版控的組態定義，基礎設施應能自我修正回期望狀態，而你應隨時能監測到它的實際狀態。一個好的檢驗問題：如果生產環境災難性故障，佈建一份新副本要多久？
🧠 Intuition
TIP
組態要宣告式（declarative）且冪等（idempotent）——不管初始狀態為何、同一組態套幾次，最終結果都相同。你描述「想要什麼」，工具負責把系統收斂到那個狀態。
- 三大原則：期望狀態進版控、基礎設施自主收斂、透過監測與監控掌握實際狀態。
- 測試環境要像生產（production-like），且用完全相同的技術手段管理，才能在進生產前就撞出環境問題。
- 該進版控的不只應用碼：OS 安裝定義、Puppet/Chef/CfEngine 組態、DNS zone/DHCP/防火牆設定、管理腳本——全都是部署管線的輸入。
- 中介軟體拆成二進位、組態、資料三部分，生命週期不同、應分開處理。
⚖️ Tradeoffs
手動登入『隨手修修看』 — 藝術品伺服器
- 完全手動佈建無法可靠重複、無法擴展，養出一台台獨一無二、沒人敢動的「藝術品」伺服器。
- 出問題時有人直接登生產環境手改，通常招致更多中斷，且因無記錄而難以追根究柢。
- 必須鎖定生產環境防止未授權存取——不只擋外部人，連內部維運人員也要擋；變更一律走流程。
宣告式組態 + 自動化流程 — 標準做法
- 集中式、版控的組態管理帶來一致性：新環境輕鬆比照既有環境佈建，硬體故障可全自動快速重建。
- 變更走統一流程：開工單 → 腳本化並簽入版控 → 在類生產環境測試 → 自動推送生產 → 記錄稽核。作者偏好自動化勝過文件（文件無法保證真的照做）。
- 代價：導入成本不低，且增加系統複雜度；但對多組態點的大型系統，手動管理在整個生命週期的成本遠高於此。
🔑 Takeaways
- 三原則：期望狀態進版控、基礎設施自主收斂、隨時可監測實際狀態。
- 組態要宣告式且冪等，測試環境用與生產相同的手段管理，才能提早撞出環境問題。
- 用自動化流程取代手動登入與紙本文件；鎖定生產（連維運也擋），變更全走統一、可稽核的流程。
No notes yet — jot your takeaways or Q&A here.