每一個踩過「staging 連到 prod 資料庫」的工程師，都會對環境隔離產生宗教般的虔誠。
先講結論
環境隔離只有一個目的：降低風險。不是讓你多開幾台機器，是讓你在搞砸的時候只炸到測試環境而不是正式客戶。Dev、staging、prod 三層是最低標準，金鑰分離、資料隔離、部署權限控管缺一不可。
那些年我們闖過的禍
不隔離會出什麼事？我列幾個真實場景你感受一下：
- 測試環境的 cron job 誤用正式 DB，把客戶資料覆蓋掉
- QA 測寄信功能，信寄到了真實客戶的信箱
- 工程師在 staging debug，不小心打了 prod 的 API endpoint
- 新功能的 migration 直接跑在 prod，鎖表三分鐘
每一件都是「我以為我連的是測試環境」。人會犯錯，系統設計要讓犯錯的代價盡可能小。
三層環境怎麼切
最少三層，多了看團隊規模：
dev —— 開發者自由發揮，壞了自己修。可以頻繁部署，資料可以隨便造。
staging —— 模擬正式環境，配置盡量跟 prod 一致。這裡是上線前的最後一道關卡。如果你的 staging 是一台 t2.micro 跑所有東西，那壓力測試的結果等於零。
prod —— 正式服務。部署需要 approval，存取需要稽核，金鑰獨立管理。
# 同一份程式碼，不同的環境變數
APP_ENV=staging
DB_URL=postgres://stg-db.internal:5432/app
REDIS_URL=redis://stg-redis.internal:6379重點是：程式碼相同，設定不同。不要在 code 裡寫 if (env === 'prod') 來分岔大量邏輯，那是災難的起點。
金鑰分離：共享密碼就是共享風險
你知道最常見的安全事故是什麼嗎？Dev 跟 prod 共用同一組 API key。
工程師在 dev 測試的時候，用的是 prod 的第三方付款金鑰。然後測試資料就變成了真實扣款。
規矩很簡單：
- 每個環境獨立的 Secrets
- 每個環境獨立的 access key
- 最小權限——dev 的 key 不能碰 prod 的資源
任何共享的金鑰都是一顆定時炸彈。
資料隔離：測試帳號不該出現在 prod
每個環境要有自己的 DB。Staging 需要真實資料來測試？用匿名化的副本，不要直連 prod。
如果真的需要用 prod 資料來 debug：
- Read-only 存取
- 限制時間窗口
- 全程記錄誰看了什麼
Prod 裡面如果出現 test@example.com 這種帳號，那就是你的隔離機制有洞。
部署治理：誰能 deploy 到哪裡
我見過最可怕的情況是：任何工程師都可以 SSH 到 prod 然後手動部署。
合理的分層是：
- dev：工程師自由部署
- staging：需要 PR 通過 CI
- prod：需要 review + approval，只有 CI/CD 機器人能做
用 CI/CD pipeline 管理部署，不要讓人類直接碰 prod。人類會手抖，機器不會。好吧機器有時候也會，但至少有 log。
Infra Drift：環境飄移
隔離做好之後，最容易出問題的是 drift——staging 跟 prod 的設定慢慢飄開。
通常是因為有人「為了趕時間」直接在 prod console 改了設定，沒有回寫到 IaC。結果 staging 測了半天，上 prod 才發現行為不一樣。
唯一的對策：所有變更都走 IaC，禁止手動改 prod。 沒有例外。
延伸閱讀
環境隔離最大的敵人不是技術限制，是「為了方便」。每一次的便宜行事，都是在往正式環境的定時炸彈上多加一顆螺絲。