01

為什麼要用「程式碼」管基礎設施?

同一批伺服器,用滑鼠一台一台點出來,跟用一份檔案「宣告」出來——長遠差別大到不成比例

先想一個很煩的場景

假設你負責一個網站,某天流量暴增,你得臨時多開 20 台伺服器。你打開雲端主控台,一台一台按「新增執行個體」、選規格、設網路、裝軟體、改設定……點到眼花。過幾天流量退了,又得一台一台關掉。下個月同樣的事再來一次——而且你根本不記得上次到底怎麼設的。

這就是手動管理基礎設施的痛:慢、不可重現、容易出錯,人一走文件就斷。原文開門見山點出,把這件事做好——也就是可擴充的基礎設施佈建——能帶來四個明確的好處。

🧾
先給你一個畫面

手動點主控台,像每次出門都憑記憶重新收行李——常常漏東漏西。用程式碼管基礎設施,則像寫好一張「打包清單」存起來:下次照著清單,一秒生出一模一樣的行李,還能給同事照抄。

直接讀原文:好處與那把鑰匙

原文只用三句話就把「為什麼」講完了。逐句核對,先看它列了哪四個好處,再看它給的答案:

原文 · ByteByteGo Scalable infrastructure provisioning provides several benefits related to availability, scalability, repeatability, and cost-effectiveness. But how do you achieve this? Provisioning infrastructure using code is the key to scalable infra management.
白話翻譯

可擴充的基礎設施佈建,帶來好幾項好處,圍繞著四件事:可用性(availability)、可擴充性(scalability)、可重現性(repeatability)、以及成本效益(cost-effectiveness)。

但你到底要怎麼做到這些?

答案是——用程式碼來佈建基礎設施,這正是可擴充基礎設施管理的關鍵鑰匙。

💡
一句話抓住整篇的邏輯

整篇文章其實就是回答那個問句「But how do you achieve this?」——而答案是把基礎設施寫成程式碼。後面模組要講的那四層策略(容器化、容器編排、IaC、GitOps),都是在把這把鑰匙用到極致。

拆解那四個好處

原文只列了名字,沒展開。這裡幫你把每個好處對回一開始那個「臨時多開 20 台伺服器」的場景,一看就懂它在解決什麼痛:

🟢
Availability 可用性

當機器掛掉或流量暴衝時,系統能自動補上、繼續服務。基礎設施寫成程式碼後,重建一台等於重跑一份檔案,把「服務不中斷」變成可以自動達成的事。

📈
Scalability 可擴充性

需要 20 台就長出 20 台,退潮就縮回去。因為規格都寫在檔案裡,擴充只是「多跑幾份」,不必人工一台台點。

♻️
Repeatability 可重現性

同一份檔案,今天、下個月、換個雲端區域跑,長出來的環境都一模一樣。告別「上次到底怎麼設的」這種失憶症。

💰
Cost-effectiveness 成本效益

用完即關、按需增減,不再讓一堆閒置機器空轉燒錢;省下的人力工時也是實打實的成本。

⚠️
別把好處當成免費

原文列的是「做對之後會得到什麼」,不是「隨便寫寫程式碼就自動送你」。要真的拿到這四個好處,得靠後面那四層策略搭配得當——這也是這份速查表存在的理由。

小試身手

看懂「為什麼」之後,來一題確認你抓到重點了:

原文問「But how do you achieve this?」(要怎麼達成那些好處?)——它給的答案是什麼?
原文開頭列出「可擴充的基礎設施佈建」帶來的好處,下列哪一組完全符合原文所列?
🪜
下一站:四層演進的地圖

知道了「為什麼要用程式碼管」,接著看「怎麼一步步做到」。原文列了四個循序演進的策略——從打包一個 App,到自動化整套更新。往下捲,點開招牌互動的架構圖。

02

四層演進:從打包一個 App,到自動化整套更新

原文列的四個策略不是四個選項,而是一層疊一層、循序長出來的階梯

原文列的是「多個策略」,其實是一條演進路線

原文說「There are multiple strategies that can help」,接著編號列出四項。乍看是四個並列選項,但仔細看順序——它們是一層墊著一層往上長的:先能把單一 App 打包(容器化),有了很多包才需要調度(編排),再把整套機器與設定都寫成檔案(IaC),最後用 Git 流程把「改設定」這件事也自動化(GitOps)。

🧗
為什麼是「演進」而不是「選一個」?

你不會跳過打包直接玩 GitOps——沒有容器可調度,編排無事可做;沒把基礎設施寫成程式碼,GitOps 也沒有東西可以自動更新。所以請把下面的架構圖,由下往上讀成一段成長史。

招牌互動:點開每一層,看它解決什麼

下面這座階梯由下往上就是原文的四層策略。點任一層,下方會展開該層的說明——每一層的說明都忠實對應原文那一條的內容。

① Containerization 容器化(Docker)
② Container Orchestration 容器編排(Kubernetes)
③ IaC(Terraform/CloudFormation/Ansible)
④ GitOps(Git workflow + CI/CD)
第一層 · Containerization(容器化):把應用程式連同它的執行環境一起打包,是最早一批「用程式碼決定部署」的策略。Docker 是最流行的容器化方式之一。原文:Containerization is one of the first strategies to make application deployments based on code. Docker is one of the most popular ways to containerize the application.
🔍
注意第三層的一個小細節

原文特別補了一句「Ansible is more of a configuration tool」——Ansible 比較偏向「設定」工具(把機器裝好、設好),而 Terraform、CloudFormation 更偏向「佈建」(把機器生出來)。這個區別在下一個練習會用到,先記著。

動手分分看:這些工具屬於哪一層?

把下面的工具卡,拖到原文為它指定的那一層。拖完按「對答案」。(提示:原文每一條各自點名了哪些工具。)

Docker
Kubernetes
Terraform
AWS CloudFormation
Ansible(偏設定)
Git workflow + CI/CD
① 容器化 Containerization
拖到這裡
② 容器編排 Orchestration
拖到這裡
③ IaC(佈建與設定)
拖到這裡
④ GitOps(自動化更新)
拖到這裡
🧩
Terraform、CloudFormation、Ansible 都歸在第三層

原文把這三個工具全列在 IaC 那一條底下,所以它們都拖到「③ IaC」。差別在於原文補的那句:Ansible 比較偏設定工具——但它仍屬於 IaC 這一層,不要因為「偏設定」就把它拖到別層去。

小試身手

四層走完,來兩題檢查一下你有沒有抓到每一層在幹嘛:

根據原文,「容器編排(container orchestration)」是在什麼情況下成為必需的?
原文怎麼描述第四層的 GitOps?
🗺️
一張速查表收攏全篇

回頭看整篇的邏輯線:想要可用性、可擴充性、可重現性、成本效益 → 關鍵是把基礎設施寫成程式碼 → 循著容器化 → 編排 → IaC → GitOps四層一路長上去。這就是這份 Cheatsheet 要你記住的全部。

💬
原文留給你的一句話

文章結尾反問:「Have you used Infrastructure as Code for your projects?」——你自己的專案,走到這四層的哪一層了?下一次要往上爬哪一階,這張圖已經幫你標好順序。