97分钟。从空白终端到完整跑通的零停机部署流水线。这个速度放在大多数团队，连评审会都开不完。
蓝绿部署（blue/green deployment，一种通过两套环境交替切换实现零停机的发布策略）本该是基础设施的标配，但AWS的官方文档把简单问题复杂化到了荒谬的程度。作者用计时器证明：真正动手做，比读文档还快。
为什么你的"无缝发布"总在撒谎
滚动更新（rolling update，逐台替换服务器的部署方式）被太多团队当成免死金牌。作者直接甩了一个数字：每次发布期间错误率飙到3%。
这个3%不是边缘案例。是你的用户在支付页面看到500错误，是监控告警在群里刷屏，是值班工程师凌晨两点对着日志骂娘。蓝绿部署的价值在于彻底隔离风险——新版本在绿色环境跑通流量切换，旧版本蓝色环境原地待命，回滚就是改条DNS记录的事。
但AWS的文档路径是这样的：先读Elastic Beanstalk的12种配置选项，再研究CodeDeploy的AppSpec语法，最后发现ECS和EKS各有完全不同的实现方案。作者的选择是跳过所有官方指南，直接用底层工具链拼装。
他的核心策略：用CloudFormation模板一次性定义两套ECS服务，通过Application Load Balancer的权重切换实现流量迁移，最后用Lambda函数做健康检查自动化。
97分钟的时间切片
作者公开了完整计时。前15分钟花在画架构草图——不是看文档，是在纸上画流量怎么走。接下来40分钟写CloudFormation模板，其中一半时间在调IAM权限（AWS的身份访问管理服务，控制谁能操作什么资源）。
真正的卡点在第52分钟：健康检查脚本死活通不过。作者发现是ECS任务定义里的容器端口映射写反了，这个bug在日志里表现为完全无关的SSL握手失败。他花了8分钟定位，修复，重新部署。
最后20分钟做压力测试。用Artillery往负载均衡器灌了2000并发请求，切换流量时p99延迟波动控制在12毫秒以内。没有错误 spike，没有连接重置，监控面板 flatline 得像假数据。
「最讽刺的是，AWS Support 案例里最常见的蓝绿部署问题，90%都是文档没讲清楚的权限边界。」作者在原帖评论区补充。他没开 Premium Support，全程靠 CloudTrail 日志（AWS的操作审计服务）自己啃出来的。
哪些步骤你可以偷走
作者把模板开源了，但更值得复制的是他的决策顺序。第一步不是选工具，是定义"成功"——他的标准是：流量切换期间错误率必须为零，回滚时间必须小于30秒。
这个定义直接淘汰了CodeDeploy。不是它做不到，是它的部署组（Deployment Group）概念和ECS服务发现耦合太深，调试周期以小时计。作者改用ALB的target group权重，API调用一次完成切换，失败就再调一次切回来。
健康检查的设计也很务实。没上复杂的Canary分析，就是一个Lambda每10秒ping新环境的/health端点，连续5次200就标记ready。简单粗暴，但故障域足够小——就算检查逻辑有bug，最多延迟50秒发现，不会误切流量。
存储层的处理是很多人踩坑的地方。作者的数据库没做蓝绿，而是把schema变更拆成预部署兼容版本和后部署清理脚本。这是Netflix 2013年就公开的"扩展收缩"模式，但AWS文档里只字未提。
他的原话：「如果你需要同时切换代码和数据库，说明你的发布粒度太粗了。」
那些文档不会告诉你的
CloudFormation的ECS服务更新有个默认行为：新任务启动成功前就标记旧任务为DRAINING（停止接收新连接）。这意味着如果你的健康检查有延迟，会出现双零窗口——新旧都没流量，用户看到504。作者手动加了DeploymentConfiguration参数，把最小健康百分比设为100，强制要求新任务完全就绪才动旧任务。
另一个隐藏成本是NAT Gateway流量费。蓝绿部署期间两套环境同时跑，如果都在私有子网，出网流量翻倍。作者的解法：绿色环境用IPv6-only子网，走Egress-only Internet Gateway，单价降到零。
这些细节在AWS的"最佳实践"白皮书里分散在17个不同章节。作者把它们串成一条检查清单，贴在GitHub仓库的issue模板里。
97分钟结束后，他在Hacker News更新了一条后续：「第二天我把同样的流程教给组里 junior，他用了71分钟。主要差距在IAM策略调试——我踩过的坑他直接抄答案。」
如果你的团队还在用"凌晨两点低峰期发布"当风险控制策略，这个计时器数据够扎心吗？
热门跟贴