個人 Dotfile 跟團隊環境的邊界

兩者共用同一個核心思想（環境 as code、版控、可重現），但管理的對象和約定的範圍不同。個人 dotfile 是「我喜歡怎麼工作」，團隊環境是「這個專案需要什麼才能跑」。

Devcontainer：容器化的開發環境

Devcontainer 是微軟提出的開放規格（devcontainers.org），定義了怎麼用 Docker 容器作為開發環境。VS Code、GitHub Codespaces、JetBrains 都支援。

核心概念

專案 repo 裡放一個 .devcontainer/devcontainer.json，描述這個專案的開發環境需要什麼：

 1{
 2    "name": "My Project",
 3    "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
 4    "features": {
 5        "ghcr.io/devcontainers/features/go:1": {
 6            "version": "1.22"
 7        },
 8        "ghcr.io/devcontainers/features/node:1": {
 9            "version": "20"
10        }
11    },
12    "postCreateCommand": "go mod download && npm install",
13    "customizations": {
14        "vscode": {
15            "extensions": [
16                "golang.go",
17                "esbenp.prettier-vscode"
18            ]
19        }
20    },
21    "forwardPorts": [8080, 3000]
22}

打開專案時，IDE 自動啟動這個容器、在裡面安裝指定版本的 Go 和 Node、跑 dependency install、裝 VS Code extension。新人 clone repo → 打開 → 等容器建好 → 直接開始寫 code。

跟個人 Dotfile 的互動

Devcontainer 管的是「專案需要什麼」，但你在容器裡工作時還是會想要自己的 shell alias、Git 設定、editor keybind。兩者的整合方式：

• dotfiles repo 自動部署：devcontainer.json 支援 "dotfiles.repository" 欄位，容器啟動時自動 clone 你的 dotfile repo 並執行 install script
• 個人 vs 團隊設定分離：.devcontainer/ 裡放團隊共用的環境定義，個人偏好透過 dotfiles 機制注入，不互相干擾

1{
2    "dotfiles.repository": "https://github.com/you/dotfiles",
3    "dotfiles.installCommand": "scripts/install.sh",
4    "dotfiles.targetPath": "~/dotfiles"
5}

這是個人 dotfile 和團隊環境標準化最乾淨的接合點——團隊定義「環境長什麼樣」，個人 dotfile 定義「在這個環境裡我怎麼操作」。

Devcontainer 的限制

• Docker 是前提：團隊每個人的機器都要裝 Docker，macOS 上要跑 Docker Desktop 或 OrbStack
• GUI 應用不適合：devcontainer 定位是 headless 開發環境，不處理圖形桌面
• 效能折扣：檔案系統操作在 macOS 上的 Docker volume 有效能折扣（Linux 上幾乎沒差）
• 離線環境：建容器需要拉 image 和 feature，斷網環境要另外處理（見 Infra 斷網模組）

Nix：宣告式的環境管理

Nix 是另一條技術路線，用宣告式的方式描述整個開發環境，不依賴 Docker。

核心概念

Nix 的 flake.nix（或 shell.nix）宣告了開發環境需要哪些套件，nix develop 進入這個環境：

 1# flake.nix
 2{
 3  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
 4
 5  outputs = { nixpkgs, ... }:
 6    let
 7      pkgs = nixpkgs.legacyPackages.x86_64-linux;
 8    in {
 9      devShells.default = pkgs.mkShell {
10        packages = with pkgs; [
11          go_1_22
12          nodejs_20
13          postgresql_16
14          redis
15        ];
16        shellHook = ''
17          echo "Dev environment ready"
18        '';
19      };
20    };
21}

跟 Devcontainer 的差異：Nix 不用容器，直接在宿主機上建立隔離的環境（透過 Nix store 的路徑隔離）。優點是沒有 Docker 的效能折扣和額外層級；缺點是 Nix 的學習曲線陡峭、語法不直覺。

Home Manager：Nix 管理 Dotfile

Nix 生態裡的 Home Manager 可以用 Nix 語言宣告式地管理整個家目錄的配置——等於用 Nix 取代 stow/chezmoi 做 dotfile 管理：

 1# home.nix
 2{ config, pkgs, ... }:
 3{
 4  programs.git = {
 5    enable = true;
 6    userName = "Your Name";
 7    userEmail = "you@example.com";
 8    extraConfig = {
 9      init.defaultBranch = "main";
10      pull.rebase = true;
11    };
12  };
13
14  programs.zsh = {
15    enable = true;
16    shellAliases = {
17      ll = "ls -alF";
18      gs = "git status";
19    };
20  };
21
22  programs.neovim = {
23    enable = true;
24    defaultEditor = true;
25  };
26}

Home Manager 把「安裝軟體」和「寫配置」統一成一份宣告——改完 home-manager switch 就同時更新套件和配置。這是 dotfile 管理的極致形式，但代價是整個技術棧鎖定在 Nix 生態裡。

常見做法

最低限度：README + onboarding 文件

專案 repo 裡寫一份 CONTRIBUTING.md 或 wiki 頁面，列出環境需求和設定步驟。新人照著做。成本最低但最容易過時——文件跟實際環境的漂移很常見，沒有自動化驗證機制時尤其如此。

中間層：腳本化 + CI 驗證

把環境設定寫成 bootstrap script（同 Bootstrap Script 設計），新人跑一次就好。CI 裡用相同的 script 或 Docker image 確保環境一致。比文件可靠，但 script 本身的維護和跨 OS 相容性是挑戰。

Runtime 版本管理可以先從 mise（前身 rtx）或 asdf 開始：專案 repo 裡放一份 .tool-versions（或 mise 的 mise.toml），定義 Node/Ruby/Python/Go 的版本號，團隊成員跑 mise install 就對齊。這比完整 devcontainer 輕量、比純 README 可靠，適合「只需要統一 runtime 版本、不需要容器化整個環境」的小團隊。它的邊界是只管語言版本——系統套件、服務依賴（PostgreSQL、Redis）、OS 層差異不在它的守備範圍。

成熟層：Devcontainer / Nix / 標準化 VM image

環境定義進專案 repo（devcontainer.json 或 flake.nix），每個開發者的環境從同一份定義產生。新人 onboarding 從「照文件設定半天」變成「打開專案等五分鐘」。

企業層：受管裝置 + MDM + 內部套件 registry

大企業用 MDM（Mobile Device Management，企業裝置管理）控制開發機的安全基線，內部 registry 管理核准的套件版本，開發環境的「自由度」受限於安全政策。個人 dotfile 在這個層級仍然有效——它管的是「政策允許範圍內的個人偏好」。

跟 Infra 的銜接

Dotfile 心智模型把 dotfile 定位為「個人的環境 as code」、跟 Infra 的 IaC 平行。這裡的銜接點是：

• Infra IaC 管雲端資源（VPC、EC2、RDS）
• CI/CD pipeline 管建置和部署流程
• Devcontainer / Nix 管開發環境定義
• 個人 Dotfile 管開發者的操作偏好

四層從組織到個人、從基礎設施到桌面，各自版控、各自演進，但共用「環境狀態用代碼描述」的思想。

判讀：什麼時候該從個人 Dotfile 往上走

向管理層提案標準化時，量化基準有助說服力：手動 onboarding 通常要半天到一天（找文件 + 裝套件 + 跑設定 + 除錯差異）。導入 devcontainer 後要區分兩個階段：初次 build（拉 base image + 安裝 feature + 跑 postCreateCommand）取決於 image 大小和網路速度，企業 proxy 或 VPN 環境下通常 20-60 分鐘；但之後的 reopen（image 已在本機 cache）只需 1-5 分鐘。日常體驗是後者——第一次 build 是一次性成本，後續每次打開專案都在分鐘級。初始投入大約一到兩個工作天（寫 devcontainer.json + 測試 + 文件化），之後維護成本隨專案依賴更新而遞增、但遠低於每次 onboarding 的重複成本。具體數字要從團隊自己的 onboarding 紀錄和 DORA 指標取得——「上一個新人花了幾天才送出第一個 PR」是最直接的 baseline。

個人 dotfile 是起點，不是終點。當環境一致性的需求從「一個人的舒適」擴展到「團隊的生產力」，就是往上走的時機。

為什麼 infra 常推不動

infra 是一種看不到立即回報的投入，這是它在商業優先級裡天然吃虧的根本原因。產品功能上線當天就能看到使用者數字、營收曲線、客訴下降；infra 投入當天看到的只有「花了時間，但畫面上什麼都沒變」。把 state 搬上遠端後端、把 IAM 從長期 access key 換成 OIDC、把環境拆成獨立帳號 — 這些工作的價值要等到某次事故、某次稽核、某次擴張才會兌現。在價值兌現之前，它在排程會議上跟一個能立刻帶來轉換率的功能競爭，幾乎必輸。

回報曲線的錯位

徵兆很直接：當 infra 工作總是被排進「有空再做」的待辦、季度結束時總是第一個被砍，根源在於它的回報曲線跟決策者的時間視窗對不上，而不是團隊不重視。決策者看的是這一季的可交付，infra 的回報落在下一次危機，兩者中間隔著一段沒有反饋的真空期。

這個落差在三種組織場景裡特別明顯，各自有不同的困局與突破口。

第一種是早期新創：每個人都在趕功能，infra 被當成「等有規模再說」的奢侈品。創辦人或技術負責人在 Console 手動把環境點起來，跑得動就不再碰。結果等到規模來的時候 — 第一個客戶進來了、需要 staging 環境了、第二個工程師要動資源了 — 手動環境的債已經高到要花整個季度去還。這個場景的突破口通常是某次事故：誤刪了 production 的資源、或者安全掃描發現長期 key 外洩，這個事件才會把 infra 從「有空再做」推進「下一個 sprint」。

第二種是成長期的公司：已經有幾十個手動資源了，每次出事都靠一兩個人熟手救火，管理層看到的是「反正每次都救回來了」，結論是「所以現在不急」。這個結論會一直成立、直到那個熟手離職的那天。更隱蔽的版本是熟手沒離職但開始成為瓶頸 — 所有 infra 變更都排隊等他、他無法去做其他事、團隊的開發速度被他一個人的頻寬卡住。

第三種是大組織裡的平台團隊：infra 是跨團隊的公共投入，每個產品團隊都想用但沒人想出資源，因為投入算自己的 headcount、收益算大家的。這個場景的常見僵局是平台團隊建了一套 IaC 模組，但產品團隊不願意學、不願意遷移、也不願意從自己的 sprint 裡撥時間，因為遷移的收益算在平台團隊的 OKR 裡而非自己的。

歸因的陷阱

理解這個落差，就不會把推不動歸因成「同事不懂技術」。把它當成溝通態度問題去硬碰，結果是工程端越說越委屈、業務端越聽越像本位主義。也別矯枉過正 — infra 確實有一部分屬於可以延後的優化，不是每一項都該現在做。

常見的歸因錯誤有兩種方向。第一種是工程端把所有 infra 需求都當成「技術上正確所以該做」，忽略優先級與時機 — 在產品還沒找到 PMF 的階段要求花三週做完整的多環境 IaC，即使技術上正確，對組織也是錯誤的資源配置。第二種是管理端把所有 infra 請求都歸入「工程師的潔癖」，因為上次某個 infra 改造確實沒帶來可見的業務效果 — 但那次可能是一個優化級的工作，跟這次的地基級需求（例如長期 key 散落）風險等級完全不同。兩種歸因都把 infra 當成一個不分層的整體，而拆層正是解開這個僵局的關鍵。

真正該做的是把「哪些 infra 屬於不能延後的地基」跟「哪些屬於可排程的優化」分開談。這條線在模組零：infra 是什麼的成熟度階梯與 day 1 鐵律裡有完整討論 — 地基類資源（網路、身分、state）回頭改的代價極高，是接近「該照做」的硬判準；應用層資源可以容許暫時手動，等形狀穩定再納管。把這條線講清楚，決策者才有辦法區分「這真的急」跟「這只是工程師想整理」，而不是把所有 infra 工作當成同一類。

信任赤字下的兩難

信任赤字指的是團隊對「動 infra 會不會把東西弄壞」的預設懷疑。當一個服務運作正常，任何對它底層的改動在旁人眼裡都是多此一舉，一旦改出問題，責任全記在發起改動的人頭上。這種不對稱讓人傾向不動，於是技術債持續累積，而累積本身又讓下一次改動更危險，形成越不敢動就越不能動的循環。

兩難的具體形狀

大改動風險高、需要的信任額度也高，但信任正是現在缺的；小改動安全，卻又解不了結構性的問題。更尷尬的中間態是改到一半 — 把一半服務遷上 IaC、另一半留在手動。這時系統同時揹著舊流程的隨意性跟新流程的約束，兩邊的缺點都拿到、好處都沒拿滿。排查問題的人要先猜這個資源歸哪套管，認知成本比改造前還高。

一個常見的情境是：平台工程師花了兩週把網路地基寫進 Terraform，PR review 通過、plan 乾淨、apply 成功。但因為只做了網路、還沒做 IAM 和核心服務，團隊日常操作還是在 Console 手動改 security group。某次手動改動造成 drift，下一次 Terraform apply 把手動改的規則覆蓋掉了，服務斷線。這個事故的結論是「半套管的中間態比全手動更危險」— 這正是信任赤字的來源：團隊看到的是 infra 造成的新風險，而非 infra 的價值。

用可回退性換取授權

可操作的判準是用改動的「可回退性」換取授權，而不是用「保證不出錯」去爭取。把一次大遷移切成多個獨立可回退的 PR，每個 PR 都能單獨 review、單獨 apply、單獨 revert，這樣每一步的風險都是有界的，團隊願意給的信任額度也跟著提高。

切片的原則有兩個邊界。第一，每個切片都要讓系統落在一個自洽的狀態 — 不能切到一半的 security group 在 IaC 裡、另一半在手動，因為這個中間態正是信任消耗最大的狀態。一個常見的錯誤切法是「先 import VPC 但不 import 它底下的 subnet」，結果 Terraform 看到 VPC 歸自己管但 subnet 不歸，下次有人改 VPC 的某個屬性做 apply，plan 裡不會顯示 subnet 的相關影響，而實際上那些手動管的 subnet 可能依賴 VPC 的那個屬性。功能相關的資源要整批進、整批出。

第二，切片不能切到讓中間態長期懸著 — 如果第一個切片是「import 網路」，但第二個切片（import IAM）排在三個月後，這三個月裡網路由 Terraform 管、IAM 還是手動，drift 風險每天都在。比較安全的節奏是把緊鄰的兩三個切片排在同一個 sprint 或同一個月裡，讓中間態存在的時間越短越好。

一個實際可行的切片順序：先用 terraform import 把一組功能相關的資源（例如一個服務的 VPC + subnet + security group）整批納管，同一個 PR 裡完成。這批資源 import 完後跑 plan 確認零變更，就算一個完整的切片。這個切片的回退方式是 terraform state rm 把資源從 state 移除（資源本身不受影響），系統回到手動狀態。每完成一個切片且沒出事，下一步能拿到的授權就多一點，原本越不敢動就越不能動的循環才會倒過來轉。

切片的排序有一條實務經驗可以參考：先納管唯讀性質的地基（VPC、subnet、route table），再納管 security group 與 IAM role，最後才碰 stateful 資源（RDS、S3）。原因是地基層的 import 風險最低 — 即使 plan 出現非零差異，VPC 或 subnet 的 update-in-place 不會中斷服務。security group 的風險稍高但仍可控。RDS 是風險最高的，因為任何觸發 replace 的欄位差異都意味著資料庫重建 — 這類資源留到信任累積足夠之後再處理，屆時團隊已經對 import 流程有經驗、對 plan 輸出的判讀有信心。

把改動綁進 PR 流程取得 review 與自動護欄的做法，見模組七：infra 走 PR 流程。

期望值對齊

期望值對齊指的是在動工之前，先跟相關角色講好 infra 工作的價值、時程、以及它「慢」的原因，讓慢成為事前的共識而不是事後的指責。infra 的改造之所以慢，是因為它要動的是正在承載流量的地基 — 每一步都得確認沒有破壞既有服務、得保留回退路徑、得跨環境驗證。這種慢是風險控制的成本，不是效率問題。但如果沒有事先說明，旁人看到的只有「一個簡單的事情做了兩週」。

對齊三件事

第一：價值翻成對方語言。對 PM 講的是「這個改動讓未來新環境從三天縮到三十分鐘」，不是「我們把 state 上了遠端後端」。對財務講的是「這批 tag 上完後，下個月的雲帳單能拆到各產品線」，不是「我們需要統一 tagging 規範」。對 CTO 講的是「這讓下一次安全稽核只需要跑一條指令就能列出所有對外開放的端口」，不是「我們要把 security group 從手動改成 IaC」。翻譯的技巧是找到對方在意的度量 — 時間、錢、風險 — 然後用那個度量描述 infra 的效果。

第二：時程給範圍而非單點。infra 工作有很多步驟是不可壓縮的驗證：每一次 import 都要跑 plan 確認零變更、每一個環境都要各自 apply 再驗收、高風險的 stateful 資源要額外的 review 和手動確認。這些步驟佔了大部分時間但產出不可見。給時程時把「估計 2-3 週」拆成「1 週 import + 驗證、1 週跨環境推送、0.5-1 週 buffer 處理 drift」，讓每一段都有對應的產出。比起一個「3 週」的黑盒，分段時程讓進度可被追蹤、延遲可被歸因。

分段時程的另一個好處是讓「卡住了」的原因可被理解。infra 工作常被卡在非技術因素上：等某個人 review PR（那個人在趕自己的 deadline）、等 staging 環境空出來跑驗證（另一個團隊正在用）、等安全團隊確認 IAM 變更符合政策。如果時程只有一個總數，這些等待全部會被歸因為「infra 太慢」。分段後，卡在哪個環節、等的是誰，一目了然 — 這讓延遲的責任回歸到真正的阻塞點，而非無差別地歸到 infra 團隊身上。

第三：把「慢」的來源攤開。告訴對方哪幾步是在跨環境驗證（dev 跑通了才推 staging、staging 跑通了才推 prod）、哪幾步是在等 plan review（PR 送出到有人 review 可能隔一天），讓等待變成可理解的過程。這跟模組七：infra 走 PR 流程裡用 plan 預覽變更、讓改動在 apply 前就被看見是同一個邏輯，只是把對象從程式碼擴大到人。

對齊的自測

一個具體的自測：如果每次進度同步都要重新解釋「為什麼還沒好」，代表期望值沒對齊在前面。最常見的失手是把對齊做成單向報告 — 工程師把計畫寫好丟出去就算對齊了。真正的對齊需要對方有機會在動工前提出他的時間壓力，雙方各退一步排出優先序。有些 infra 工作可以拆成「先做不中斷服務的前半段（import + 驗證），高風險的後半段（切換 apply 流程）排到下一個季度」，這種拆法同時回應了業務的時間壓力跟 infra 的安全需求。

對齊也不等於承諾零風險。反而要在這個階段就把可能的失敗模式講清楚：「import 過程中如果發現某個資源的 Console 設定跟我們以為的不一樣，這個步驟會卡住，需要人工確認現況後才能繼續」。事先講比事後解釋便宜得多。

一個被低估的對齊技巧是拆半交付。有些 infra 工作可以拆成「先做不中斷服務的前半段（import + 驗證），高風險的後半段（切換 apply 流程）排到下一個季度」。前半段的產出是一份跟現況一致的 IaC 程式碼，它本身就有價值 — 新人讀 code 就能理解環境、稽核時有可查的描述。後半段才是讓後續變更走 PR 流程。這種拆法同時回應了業務的時間壓力跟 infra 的安全需求：前半段拿到的價值足以讓決策者看到回報，後半段就有信任基礎去爭取。

知識共享優於個人英雄主義

infra 知識要分散在團隊裡、並盡量沉澱進可執行的程式碼，這樣組織才不會把營運連續性押在單一個人身上。當只有一個人懂整套 infra 怎麼運作，這個人請假、轉組、離職的那一刻，組織就失去了安全改動地基的能力 — 剩下的人不敢動，因為沒人知道動了會牽連到什麼。這是一種典型的單點故障，只是故障點是人不是機器。

英雄主義的代價

個人英雄主義在短期看起來很有效率：一個熟手能繞過所有流程、直接在 Console 把問題解掉。但這種效率有三個隱性成本。第一，它不會留下痕跡 — 下一個人遇到同樣狀況時得從零重來，或者更常見的是直接去問那個熟手，而那個熟手變成了所有人的瓶頸。第二，它會阻礙流程建立 — 當「找某人手動修」比「走 PR 流程」快，團隊就沒有動力採用流程，於是流程永遠停在「有但沒人用」的狀態。第三，它對個人也是負擔 — 組織越依賴他，他越難抽身去做別的事、越難請長假、越難轉組。

判讀知識集中度的訊號是問一個問題：如果最懂 infra 的人下週離職，團隊還敢動 production 的網路設定嗎？如果答案是「得等他回來」或「只能凍結變更等新人到」，那不論工具鏈多完整，知識還在個人腦中，PR 流程只是形式。

可以用更細緻的分級來評估集中度：能不能看懂 plan 輸出（讀的能力）、能不能寫一個新的小資源（寫的能力）、能不能處理一次 import（操作的能力）、能不能在 apply 出問題時判斷該回退還是繼續（決策的能力）。這四級能力分布在幾個人身上，比所有能力集中在一個人身上，組織韌性高得多。

兩條互補的分散路徑

把知識搬出個人腦袋有兩條路徑，互補使用。

第一條是把運作邏輯寫進程式碼與流程。當環境的建立方式是一份 IaC、變更方式是一個 PR，知識就內建在可執行的物件裡，新人讀 code 跟 PR 歷史就能重建脈絡。PR 的描述不只是「改了什麼」，還要寫「為什麼這樣改」— 三個月後有人翻 git log，看到「把 NAT 從單一改成 per-AZ，因為上週 ap-northeast-1a 故障時全部 private subnet 出站斷了」，這個決策脈絡就永久保留了。這正是模組七：infra 走 PR 流程的核心價值之一。

第二條是刻意的輪替與配對。讓不同人輪流負責 infra 的 review 與 apply，用實際操作累積分散的熟悉度。具體做法包括：

• 第二 reviewer 制度：每次 infra PR 指定一個「非平常負責 infra 的人」做第二 reviewer。這個人不需要能獨立寫 HCL，但需要能讀懂 plan 輸出、問出「這個 replace 是故意的嗎」這類問題。review 本身就是學習。
• 輪值部署：每季度讓不同人負責一次環境部署或擴容。第一次由熟手配對帶著做，第二次獨立執行、熟手待命。兩次之後這個人就能獨立處理同類操作。
• on-call 不自動轉派：on-call 輪值時 infra 問題不自動轉給專家，先讓當值的人用 code 和文件嘗試處理，15 分鐘內搞不定再 escalate。這 15 分鐘裡他會學到的比任何文件都多 — 而且會發現哪些 runbook 缺了、哪些步驟寫得不清楚，這些回饋又改善了文件品質。
• infra 變更的 runbook：把常見操作（加一條 security group rule、擴容 RDS、加一個新環境）寫成 step-by-step 的操作文件，包含「跑這條指令」「確認這個輸出」「看到這個就停」。Runbook 降低的是「開始做」的門檻 — 有 runbook 的操作，非專家也敢接手。

這些做法的共同點是刻意把操作機會分散出去，讓知識透過做而非透過講來傳遞。

共享不必走到人人都是專家。只要關鍵操作有第二個人能接手、關鍵決策的脈絡留得下來，瓶頸就不再卡在單一個人身上。

把 infra 重要性翻成商業語言

infra 的重要性要翻譯成商業後果才能進入決策者的優先級，因為決策者用的是成本與風險的語言，不是技術術語的語言。「我們缺乏環境分離」對 PM 沒有重量，但「測試環境的一次誤操作可以直接打到正式資料庫、波及全部客戶」有重量，因為後者描述的是一個可以標價的損失。翻譯的本質是把抽象的技術缺口換算成一個具體的、會痛的場景。

缺口兌現時的商業後果

把地基失效時會發生什麼攤開來算。每一項 infra 缺口都有對應的失效情境：

這些場景的共同點是平時完全看不見、失效時一次性兌現巨大成本，這也正是模組零：infra 是什麼裡地基隱形、出事才現形的論證。把這條論證從技術語境搬到商業語境，就是這一章要做的翻譯。

準備這份表格時，數字不需要精確到小數點，但需要有依據。「重建要數天」可以改成「上次類似事故花了兩天半」；「影響所有客戶」可以改成「影響約 N 個帳號」。有具體數字的描述比泛泛的「可能很嚴重」有說服力得多 — 決策者每天處理的都是模糊的風險，一個有量級的損失估計才會從背景噪音裡跳出來。如果團隊沒發生過類似事故、沒有歷史數字可引用，可以用行業公開的事故報告作為參照（例如某知名服務因為 S3 bucket 公開導致的資料外洩事件），說明同類事故在別的組織造成的代價。

誠實分級

可操作的做法是替每一項想推動的 infra 工作，準備一句「不做的話，最壞情況是什麼、影響多少客戶、要救多久」。這句話本身就是一道篩子：講不出對應商業後果的工作，可能確實優先級不高、可以排到後面；講得出而且後果嚴重的，這句話就是排程的籌碼。

要小心的陷阱是把每件事都講成最嚴重的情況。幾次之後狼來了效應會讓所有警告失效 — 決策者開始把所有 infra 請求當成「工程師又在危言聳聽」。翻譯要誠實分級：

三種嚴重度對應三種論證語言：

地基級的工作用「最壞情況」爭取優先級 — 「如果這把外洩的 admin key 被拿去開一百台礦機，我們的帳號會在幾小時內燒掉整個季度的雲端預算，而且清理過程中所有服務都得暫停」。營運效率級的用「過去 N 次事故的累積成本」來論證 — 「過去半年因為 dev/prod 共用環境，已經發生了三次誤操作影響到正式客戶，每次修復花了半天到一天，加上客戶溝通的時間，累計約六個工作天」。優化級的用「投入 X 天、之後每次省 Y 小時」的 ROI 來排序 — 「導入 Terragrunt 需要三天，之後每次加新環境從兩小時縮到十分鐘」。

三種語言混著用、各自對應到正確嚴重度的工作，才能讓決策者建立「這個人的優先級判斷值得信任」的印象，而不是「這個人不分輕重」。

商業語言是用來爭取優先級、不是用來嚇人；爭取到之後，怎麼安全地做仍然回到本系列技術模組的判準。把成本量化的延伸方法，可參考 devops 模組八：成本管理 對基礎設施成本的拆解視角。

跨分類引用

• → 模組零：infra 是什麼：地基隱形、爆炸時才現形的論證，成熟度階梯與 day 1 鐵律
• → 模組七：infra 走 PR 流程：用流程把 infra 知識從個人腦裡搬進 code，PR 作為知識載體
• → devops 模組八：成本管理：把 infra 缺口換算成可標價成本的拆解視角
• → 團隊權限分級：權限分級讓知識不集中在 admin 一個人身上
• → 職務交接設計：交接的操作清單與結構性降低交接成本的設計

讀完本章後、你應該能判讀自己當前處在三層哪一階、要跨到下一階時需要補哪些議題、對應到 backend/07 哪些卡片。

本章目標

1. 區分個人 dev、團隊共用、production 三層 LLM 部署的安全議題差異。
2. 知道從個人 dev 跨到團隊共用時、需要補哪些控制。
3. 知道從團隊共用跨到 production 時、需要補哪些控制。
4. 認識每層演化對應的 backend/07 卡片清單。
5. 知道何時該停留在當前層、何時該主動升級。

三層演化的判讀軸

1個人 dev（本模組前五章）
2   ↓
3團隊共用（家裡 / 小團隊 / 內部部署）
4   ↓
5production 服務（對外服務 / SaaS / B2B）

三層的核心差異：

關鍵原則：控制機制應該跟需求對齊、不該過度設計也不該不足。個人 dev 不需要 SOC 2 audit、production 不能只靠 git track。

個人 dev → 團隊共用：要補什麼

從個人 dev 跨到團隊共用、典型的觸發場景：

1. 家裡跑模型給家人 / 室友用
2. 小團隊共用一台 LLM server
3. 公司內部部署、有 5 ~ 50 個工程師用

需要補的控制（在前五章的基礎上）：

團隊共用階段的常見 anti-pattern：

1. 把個人 dev 的 dotfile config 直接複製到團隊 server：API key、log 路徑、reset 機制都不對。
2. 依賴單一管理員口頭傳遞政策：沒寫下來、新成員不知道、人離職就失傳。
3. 跳過 auth 直接用「公司內網本來就安全」當理由：內網設備有訪客、有實習生、有 BYOD、有合作廠商；零信任的最低版本仍要做。

團隊共用 → production：要補什麼

從團隊共用跨到 production 服務、典型的觸發場景：

1. 把內部 LLM 服務開放給外部客戶（B2B）
2. 做 SaaS-like LLM API 對外賣
3. 把 LLM 嵌入產品給終端用戶用

需要補的控制（在前面兩層的基礎上）：

production 階段不是「把團隊共用放大」、是「另一個複雜度等級」。多數議題從 backend/07 既有卡片開始讀、LLM-specific 議題在 backend/07 的 LLM 相關章節（llm-*.md）補充。

何時該停留在當前層

不是所有工作流都需要升級。停留在當前層的合理判讀：

升級的兩個常見錯誤：

1. 過早升級：個人 dev 階段就上 enterprise stack（IAM、Vault、SIEM）、複雜度過高、自己用不到、維護成本反而傷工作流。
2. 過晚升級：團隊共用階段該補的控制沒補、出事才補、可能已經有資料外洩 / 法律責任。

判讀依據：控制機制對齊實際 threat model 跟 user 規模、不是「越多越好」。

跨層升級的常見 anti-pattern

從各層往上跨時、常見的意外：

1. 把個人 dev 的 LLM client config 直接放上 production：autocomplete model、default model、API key 都不對；production 場景需要重新設計 model 路由。
2. 把個人習慣的 prompt injection 防護當 production 防護：「我 git track 工作流」對個人 dev 夠、production agent 場景下、git 不在迴路裡、要改用 tool spec + review checkpoint。
3. production 場景仍然依賴使用者「看 prompt 內容」：使用者數量大、不可能每個 prompt 都人工看；production 需要自動化偵測訊號。
4. production 場景沒 tenant 隔離：所有用戶的 KV cache / log / context 混在一起、A 用戶能看到 B 用戶的 cache hit。
5. 沒有 vendor 政策的書面化承諾：team 階段口頭講「我們不訓練客戶資料」、production 階段要寫進條款 / SLA。

給讀者的層級判讀清單

判斷自己當前在哪一層：

1[ ] 只有自己用                                              → 個人 dev
2[ ] 1 ~ 5 個人共用一台 server                                → 個人 dev 或團隊共用初期
3[ ] 5 ~ 50 個人共用、內部部署                                → 團隊共用
4[ ] 對外提供 API 服務 / SaaS                                 → production
5[ ] 服務多個客戶 / 涉及客戶 PII                              → production
6[ ] 有 SLA / 合約承諾                                        → production

對應的「要補的議題」：

 1個人 dev → 團隊共用：
 2  [ ] auth                  ← backend/07 identity-access-boundary
 3  [ ] 入口治理               ← backend/07 entrypoint-and-server-protection
 4  [ ] TLS                    ← backend/07 transport-trust-and-certificate-lifecycle
 5  [ ] secret 集中管理        ← backend/07 secrets-and-machine-credential-governance
 6  [ ] 內部 supply chain      ← backend/07 supply-chain-integrity-and-artifact-trust
 7  [ ] 寫下 acceptable use 政策
 8
 9團隊共用 → production：
10  [ ] 多租戶 isolation       ← backend/07 llm-multi-tenant-isolation
11  [ ] deployment 供應鏈      ← backend/07 llm-deployment-supply-chain
12  [ ] agent prompt injection ← backend/07 llm-prompt-injection-in-agent
13  [ ] log / PII 治理         ← backend/07 llm-log-and-pii-governance
14  [ ] 偵測訊號               ← backend/07 llm-as-service-detection-coverage
15  [ ] workload identity      ← backend/07 workload-identity-and-federated-trust
16  [ ] 偵測平台               ← backend/07 detection-coverage-and-signal-governance
17  [ ] IR 流程                ← backend/07 incident-case-to-control-workflow
18  [ ] 合規                   ← backend/07 data-protection-and-masking-governance

下一步

本章是模組六的最後一章。下一步可以回到 模組六 _index 看其他章節、或進入 Backend 模組七 資安與資料保護 接 production 場景。

章節文章

跨分類引用

• → 模組零：Dotfile 心智模型：個人環境 as code 跟組織 IaC 的平行
• → 模組八：同步、Bootstrap 與環境重建：bootstrap script 是團隊腳本化層級的基礎
• → Infra 基礎設施建置指南：Infra IaC 是組織層的環境 as code
• → Infra 斷網模組：離線環境的 devcontainer 限制

為什麼 infra 常推不動

infra 是一種看不到立即回報的成本，這是它在商業優先級裡天然吃虧的根本原因。產品功能上線當天就能看到使用者數字、營收曲線、客訴下降；infra 投入當天看到的只有「花了時間，但畫面上什麼都沒變」。把 state 搬上遠端後端、把 IAM 從長期 access key 換成 OIDC、把環境拆成獨立帳號，這些工作的價值要等到某次事故、某次稽核、某次擴張才會兌現。在價值兌現之前，它在排程會議上跟一個能立刻帶來轉換率的功能競爭，幾乎必輸。

徵兆很直接：當 infra 工作總是被排進「有空再做」的待辦、季度結束時總是第一個被砍，根源在於它的回報曲線跟決策者的時間視窗對不上，而不是團隊不重視。決策者看的是這一季的可交付，infra 的回報落在下一次危機，兩者中間隔著一段沒有反饋的真空期。

理解這個落差，就不會把推不動歸因成「同事不懂技術」。把它當成溝通態度問題去硬碰，結果是工程端越說越委屈、業務端越聽越像本位主義。也別矯枉過正——infra 確實有一部分屬於可以延後的優化，不是每一項都該現在做。真正該做的是把「哪些 infra 屬於不能延後的地基」跟「哪些屬於可排程的優化」分開談，這條線在「模組零：infra 是什麼」的成熟度階梯與 day1 鐵律裡有完整討論。

信任赤字下的兩難

信任赤字指的是團隊對「動 infra 會不會把東西弄壞」的預設懷疑，它決定了一次改動能拿到多大的授權。當一個服務跑得好好的，任何對它底層的改動在旁人眼裡都是「沒事找事」，一旦改出問題，責任全記在發起改動的人頭上。這種不對稱讓人傾向不動，於是技術債持續累積，而累積本身又讓下一次改動更危險，形成越不敢動就越不能動的循環。

兩難的具體形狀是這樣：大改動風險高、需要的信任額度也高，但信任正是現在缺的；小改動安全，卻又解不了結構性的問題。更尷尬的中間態是改到一半——把一半服務遷上 IaC、另一半留在手動，這時系統同時揹著舊流程的隨意性跟新流程的約束，兩邊的缺點都拿到、好處都沒拿滿。排查問題的人要先猜這個資源歸哪套管，認知成本比改造前還高。

可操作的判準是用改動的「可回退性」換取授權，而不是用「保證不出錯」去爭取。把一次大遷移切成多個獨立可回退的 PR，每個 PR 都能單獨 review、單獨 apply、單獨 revert，這樣每一步的風險都是有界的，團隊願意給的信任額度也跟著提高。切片不能切到讓中間態長期懸著——每個切片都要讓系統落在一個自洽的狀態、而不是半套真相並存。每完成一個可回退的小步，下一步能拿到的授權就多一點，原本越不敢動就越不能動的循環才會倒過來轉。把改動綁進 PR 流程取得 review 與自動護欄的做法，見「模組七：infra 走 PR 流程」。

期望值對齊

期望值對齊指的是在動工之前，先跟相關角色講好 infra 工作的價值、時程、以及它「慢」的原因，讓慢成為事前的共識而不是事後的指責。infra 的改造之所以慢，是因為它要動的是正在承載流量的地基——每一步都得確認沒有破壞既有服務、得保留回退路徑、得跨環境驗證。這種慢是風險控制的成本，不是效率問題。但如果沒有事先說明，旁人看到的只有「一個簡單的事情做了兩週」。

對齊要對齊三件事。第一是價值要翻成對方語言：對 PM 講的是「這個改動讓未來新環境從三天縮到三十分鐘」，不是「我們把 state 上了遠端後端」。第二是時程要給範圍而非單點，並標出哪些步驟是不可壓縮的驗證、哪些是可以平行的。第三是把「慢」的來源攤開——告訴對方哪幾步是在跨環境驗證、哪幾步是在等 plan review，讓等待變成可理解的過程。

一個具體的自測：如果每次進度同步都要重新解釋「為什麼還沒好」，代表期望值沒對齊在前面。最常見的失手是把對齊做成單向報告，真正的對齊需要對方有機會在動工前提出他的時間壓力，雙方各退一步排出優先序。對齊也不等於承諾零風險，反而要在這個階段就把可能的失敗模式講清楚——這跟「模組七：infra 走 PR 流程」裡用 plan 預覽變更、讓改動在 apply 前就被看見是同一個邏輯，只是把對象從程式碼擴大到人。

知識共享優於個人英雄主義

infra 知識要分散在團隊裡、並盡量沉澱進可執行的程式碼，這樣組織才不會把營運連續性押在單一個人身上。當只有一個人懂整套 infra 怎麼運作，這個人請假、轉組、離職的那一刻，組織就失去了安全改動地基的能力——剩下的人不敢動，因為沒人知道動了會牽連到什麼。這是一種典型的單點故障，只是故障點是人不是機器。

個人英雄主義在短期看起來很有效率：一個熟手能繞過所有流程、直接在 Console 把問題解掉。問題是這種效率不會留下痕跡，下一個人遇到同樣狀況時得從零重來，而那個熟手變成了所有人的瓶頸——每個改動都要等他有空、每個決策都要問過他。組織越依賴他，他越難抽身去做別的事，這對個人跟組織都是負擔。

把知識搬出個人腦袋有兩條路徑，互補使用。一條是把運作邏輯寫進程式碼與流程：當環境的建立方式是一份 IaC、變更方式是一個 PR，知識就內建在可執行的物件裡，新人讀 code 跟 PR 歷史就能重建脈絡，這正是「模組七：infra 走 PR 流程」的核心價值之一。另一條是刻意的輪替與配對：讓不同人輪流負責 infra 的 review 與 apply，用實際操作累積分散的熟悉度。檢驗有沒有做到，問自己一句就夠：如果最懂 infra 的人下週離職，團隊還敢動 production 的網路設定嗎——答案是否定的，就代表知識過度集中，那個熟手仍然是繞不開的瓶頸。共享不必走到人人都是專家，只要關鍵操作有第二個人能接手、關鍵決策的脈絡留得下來，瓶頸就不再卡在單一個人身上。

把 infra 重要性翻成商業語言

infra 的重要性要翻譯成商業後果才能進入決策者的優先級，因為決策者用的是成本與風險的語言，不是技術術語的語言。「我們缺乏環境分離」對 PM 沒有重量，但「測試環境的一次誤操作可以直接打到正式資料庫、波及全部客戶」有重量，因為後者描述的是一個可以標價的損失。翻譯的本質是把抽象的技術缺口換算成一個具體的、會痛的場景。

最有說服力的素材是「環境爆炸時的代價」——把地基失效的那一刻會發生什麼攤開來算。沒有 state 版控時，一次併發修改可能讓整個環境的記錄錯亂，重建要幾天、期間服務不可用；沒有身分隔離時，一把外洩的長期憑證可以橫向存取所有資源；沒有環境分離時，一次本該打在 staging 的變更直接改了 production。這些場景的共同點是平時完全看不見、爆炸時一次性兌現巨大成本，這也正是「模組零：infra 是什麼」裡地基隱形、出事才現形的論證。把這條論證從技術語境搬到商業語境，就是這一章要做的翻譯。

可操作的做法是替每一項想推動的 infra 工作，準備一句「不做的話，最壞情況是什麼、影響多少客戶、要救多久」。這句話本身就是一道篩子：講不出對應商業後果的工作，可能真的優先級不高、可以排到後面；講得出而且後果嚴重的，這句話就是排程的籌碼。要小心的陷阱是把每件事都講成世界末日，幾次之後狼來了效應會讓所有警告失效——所以翻譯要誠實分級，把真正的地基跟可延後的優化分開。商業語言是用來爭取優先級、不是用來嚇人；爭取到之後，怎麼安全地做仍然回到前面八個模組的技術判準。把成本量化的延伸方法，可參考 /devops/08-cost-management/ 對基礎設施成本的拆解視角。

章節文章

跨分類引用

• → 模組零：infra 是什麼：地基隱形、爆炸時才現形的論證
• → 模組七：infra 走 PR 流程：用流程把 infra 知識從個人腦裡搬進 code
• → /devops/08-cost-management/：把 infra 缺口換算成可標價成本的拆解視角