97分鐘。從空白終端到完整跑通的零停機部署流水線。這個速度放在大多數(shù)團隊，連評審會都開不完。

藍綠部署（blue/green deployment，一種通過兩套環(huán)境交替切換實現(xiàn)零停機的發(fā)布策略）本該是基礎設施的標配，但AWS的官方文檔把簡單問題復雜化到了荒謬的程度。作者用計時器證明：真正動手做，比讀文檔還快。

為什么你的"無縫發(fā)布"總在撒謊

滾動更新（rolling update，逐臺替換服務器的部署方式）被太多團隊當成免死金牌。作者直接甩了一個數(shù)字：每次發(fā)布期間錯誤率飆到3%。

這個3%不是邊緣案例。是你的用戶在支付頁面看到500錯誤，是監(jiān)控告警在群里刷屏，是值班工程師凌晨兩點對著日志罵娘。藍綠部署的價值在于徹底隔離風險——新版本在綠色環(huán)境跑通流量切換，舊版本藍色環(huán)境原地待命，回滾就是改條DNS記錄的事。

但AWS的文檔路徑是這樣的：先讀Elastic Beanstalk的12種配置選項，再研究CodeDeploy的AppSpec語法，最后發(fā)現(xiàn)ECS和EKS各有完全不同的實現(xiàn)方案。作者的選擇是跳過所有官方指南，直接用底層工具鏈拼裝。

他的核心策略：用CloudFormation模板一次性定義兩套ECS服務，通過Application Load Balancer的權重切換實現(xiàn)流量遷移，最后用Lambda函數(shù)做健康檢查自動化。

97分鐘的時間切片

作者公開了完整計時。前15分鐘花在畫架構草圖——不是看文檔，是在紙上畫流量怎么走。接下來40分鐘寫CloudFormation模板，其中一半時間在調IAM權限（AWS的身份訪問管理服務，控制誰能操作什么資源）。

真正的卡點在第52分鐘：健康檢查腳本死活通不過。作者發(fā)現(xiàn)是ECS任務定義里的容器端口映射寫反了，這個bug在日志里表現(xiàn)為完全無關的SSL握手失敗。他花了8分鐘定位，修復，重新部署。

最后20分鐘做壓力測試。用Artillery往負載均衡器灌了2000并發(fā)請求，切換流量時p99延遲波動控制在12毫秒以內。沒有錯誤 spike，沒有連接重置，監(jiān)控面板 flatline 得像假數(shù)據(jù)。

「最諷刺的是，AWS Support 案例里最常見的藍綠部署問題，90%都是文檔沒講清楚的權限邊界?！棺髡咴谠u論區(qū)補充。他沒開 Premium Support，全程靠 CloudTrail 日志（AWS的操作審計服務）自己啃出來的。

哪些步驟你可以偷走

作者把模板開源了，但更值得復制的是他的決策順序。第一步不是選工具，是定義"成功"——他的標準是：流量切換期間錯誤率必須為零，回滾時間必須小于30秒。

這個定義直接淘汰了CodeDeploy。不是它做不到，是它的部署組（Deployment Group）概念和ECS服務發(fā)現(xiàn)耦合太深，調試周期以小時計。作者改用ALB的target group權重，API調用一次完成切換，失敗就再調一次切回來。

健康檢查的設計也很務實。沒上復雜的Canary分析，就是一個Lambda每10秒ping新環(huán)境的/health端點，連續(xù)5次200就標記ready。簡單粗暴，但故障域足夠小——就算檢查邏輯有bug，最多延遲50秒發(fā)現(xiàn)，不會誤切流量。

存儲層的處理是很多人踩坑的地方。作者的數(shù)據(jù)庫沒做藍綠，而是把schema變更拆成預部署兼容版本和后部署清理腳本。這是Netflix 2013年就公開的"擴展收縮"模式，但AWS文檔里只字未提。

他的原話：「如果你需要同時切換代碼和數(shù)據(jù)庫，說明你的發(fā)布粒度太粗了?！?/b>

那些文檔不會告訴你的

CloudFormation的ECS服務更新有個默認行為：新任務啟動成功前就標記舊任務為DRAINING（停止接收新連接）。這意味著如果你的健康檢查有延遲，會出現(xiàn)雙零窗口——新舊都沒流量，用戶看到504。作者手動加了DeploymentConfiguration參數(shù)，把最小健康百分比設為100，強制要求新任務完全就緒才動舊任務。

另一個隱藏成本是NAT Gateway流量費。藍綠部署期間兩套環(huán)境同時跑，如果都在私有子網，出網流量翻倍。作者的解法：綠色環(huán)境用IPv6-only子網，走Egress-only Internet Gateway，單價降到零。

這些細節(jié)在AWS的"最佳實踐"白皮書里分散在17個不同章節(jié)。作者把它們串成一條檢查清單，貼在GitHub倉庫的issue模板里。

97分鐘結束后，他在Hacker News更新了一條后續(xù)：「第二天我把同樣的流程教給組里 junior，他用了71分鐘。主要差距在IAM策略調試——我踩過的坑他直接抄答案。」

如果你的團隊還在用"凌晨兩點低峰期發(fā)布"當風險控制策略，這個計時器數(shù)據(jù)夠扎心嗎？