6.2 DevOps 與基礎設施即程式碼#

從「開發/維運對立」到 DevOps#

傳統軟體組織裡，有兩派人馬常有摩擦：開發（Dev） 想「盡快推出新功能」，維運（Ops） 想「系統穩定別出事」。開發者的「新東西」常是維運的「新麻煩」，於是兩邊互相指責，軟體交付又慢又常出意外。

DevOps 是一種打破這種對立的文化與實踐：讓開發與維運密切協作，共同承擔「從寫程式到上線維運」的整個生命週期。核心精神是「誰寫的、誰負責它跑」——開發者不只是交付程式碼，也要關心它部署、監控、故障處理。

flowchart LR
    subgraph Traditional[傳統分工]
        DEV1[開發] -->|交出去| OPS1[維運]
    end
    subgraph DevOpsMode[DevOps]
        TEAM[同一批人 : DEV + OPS 責任意義重疊]<br/>共同負責交付與維運
    end

DevOps 的三大支柱常被總結為：文化（協作態度）、實踐（自動化）、工具（支撐技術）。本節聚焦其中最「工程化」的部分——基礎設施即程式碼（IaC）。

基礎設施即程式碼（IaC）#

傳統上，伺服器、網路、資料庫等基礎設施是「人工操作」的：SSH 進去、敲指令、手動設定。這種方式有致命問題：不可重現、容易出錯、沒有版本紀錄、無法審計——而且做不到「任何人一鍵建立相同的環境」。

基礎設施即程式碼（Infrastructure as Code, IaC） 的答案是：把基礎設施的定義，「用程式碼描述」出來，並納入版本控制、可重現地建立。

就像「用 Dockerfile 描述一個容器」「用雲端 config 描述一台伺服器」，IaC 讓你能： - 重現（Reproducible）：同一份程式碼，建立出完全相同的環境 - 版本化（Versioned）：基礎設施的變更也進 Git，可追蹤、可回滾 - 自動化（Automated）：整合進 CI/CD 管線自動建立/銷毀 - 審計（Audited）：誰改了什麼基礎設施，都有歷史紀錄

容器化：輕量、可攜的執行環境#

理解 IaC 前，先理解現代部署的基石——容器（Container）。

容器把「應用程式 + 它的依賴 + 設定」打包成一個輕量、可攜、隔離的執行單元。最主流的是 Docker。容器解決的經典問題是「在我電腦上明明可以跑啊」——因為容器保證了「打包當下的環境」能原封不動地在別處執行。

# Dockerfile：描述如何建立一個容器
FROM node:20                      # 基底：Node 20 環境
WORKDIR /app
COPY package*.json ./
RUN npm install                   # 安裝依賴
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

容器 vs 傳統虛擬機（VM）：虛擬機模擬整個作業系統（重、慢、耗資源）；容器共享宿主機的核心，只隔離應用層（輕、快、啟動秒級）。容器也因此成為「可攜執行環境」的事實標準（在雲端、K8s、邊緣都能跑）。

編排：管理大量容器#

單一容器很好用，但真實系統往往有「很多個容器要協同」——多服務、縮放、負載平衡、自動復原。容器編排（Container Orchestration） 負責管理這些。最主流的是 Kubernetes（K8s）。

K8s 用宣告式的方式描述「希望系統處於什麼狀態」，它負責持續讓實際狀態趨向目標狀態（例如：保持有 3 個訂位服務實例在跑，一個掛了就自動補上）。這正是「基礎設施即程式碼」在規模化時代的體現。

現代 IaC 工具#

實務上，IaC 有多種層次的工具：

工具	層次	用途
Docker	容器	把應用打包成可攜執行單元
docker-compose	多容器	在本機/單機定義多容器應用
Kubernetes	編排	管理大型容器叢集、自動排程/擴展
Terraform	雲端基礎設施	用程式碼定義雲端資源（VM、網路、DB）
Ansible	設定管理	用程式碼配置伺服器狀態
GitHub Actions	CI/CD	自動化流程（6.1 節）

這些工具的共同哲學一致：「把基礎設施當程式碼管理」——可重現、可版本化、可自動化、可審計。

環境即程式碼：從測試到正式的一致#

IaC 有一個重要的衍生效益：環境一致（Environment Consistency）。

因為任何環境（測試、預發布、正式）都可以由同一份 IaC 建立，你可以保證「測試環境」與「正式環境」的基礎設施幾乎一模一樣。這解決了 6.1 節提到的「測試正常、正式壞掉」的環境差異問題——環境差異本身被消滅了。

再加上 6.1 節的「不可變建置產物」，整個交付就建立在一個關鍵原則上： - 軟體 = 不可變映像（同一個 Docker 映像跑到底） - 環境 = 可重現程式碼（同一份 IaC 建立）

兩者合起來，讓「哪個程式碼跑在哪個環境」變成可精確控制、可重現、可回滾的狀態——這是現代維運可靠性的基石。

AI 時代的 IaC 與 DevOps#

AI 對基礎設施與維運的影響同樣深刻：

AI 協助撰寫 IaC：Dockerfile、K8s 設定、Terraform 等宣告式文件，正是 AI 擅長的「有語法、有慣例、有明確結構」的產物。AI 能快速起草並修正 IaC 設定，大幅降低門檻。
AI 的自動化離不開 IaC：讓 AI Agent 執行「部署」這類動作（見第 9 章 Harness）時，必須有受控、可重現、可回滾的環境——IaC 正是提供這個「安全執行場域」的基礎。沒有 IaC 的「AI 自動部署」異常危險（怕它亂改、錯改）。
DevOps 文化與 AI 協作：一如 AI 需要「指揮官與品質把關」，自動化維運也需要人類定義「目標狀態」與「安全邊界」，AI 負責執行與最佳化例行工作。

一句話：IaC 讓「環境可以被程式碼化地建立與銷毀」，這既是現代維運的基石，也是讓 AI 安全地參與「部署與維運」的必要前提（13 章的工具安全會再討論這點）。

本章小結#

DevOps：打破開發/維運對立，共同承擔「寫到跑」的整個生命週期
支柱：文化、實踐、工具
基礎設施即程式碼（IaC）：用程式碼描述基礎設施 → 可重現、版本化、自動化、審計
容器（Docker）：輕量可攜執行單元；編排（K8s）：管理大量容器
現代工具：Docker、compose、K8s、Terraform、Ansible、Actions
環境一致消滅「測試正常、正式壞掉」的環境差異
AI 時代：AI 協助寫 IaC；IaC 也是讓 AI 安全自動部署的必要前提

想一想#

「開發/維運對立」造成的典型問題是什麼？DevOps 如何用「誰寫的誰負責跑」來解決？
容器為什麼能解決「在我電腦上明明可以跑啊」的問題？
為什麼說「讓 AI 安全地自動部署，必須先有 IaC」？沒有受控環境的 AI 自動部署風險在哪？