5人团队时管用的部署流程，到15人时就会崩溃
每个工程团队都会经历手动部署的阶段，而且一开始还挺好用。一两个人知道操作步骤，检查清单存在 Notion 文档里，谁有空闲的下午就发布一次。可一旦团队规模超过15人，发布频率从每周一次变成每天一次，同样这套流程就开始制造事故。
我们反复见到这种模式：一个安全发布了两年的团队，突然某个月状况频出。不是因为谁的工作能力变差了，而是因为这套流程从一开始就没打算支撑更大的团队规模。手动部署本质上是一个单点故障系统，只是披着"我们一直都是这么做的"这层外衣。
客户问我们的从来不是"要不要自动化"——这一 点大家早就有共识。真正的问题是应该先自动化什么，因为想在一个冲刺周期里把所有问题都解决掉的团队，通常最后什么都没做成。以下是我们在成长期团队中反复验证过、真正管用的顺序。
先修好部署路径，再碰基础设施
当系统感觉摇摇欲坠时，本能反应是先上基础设施即代码——把所有东西都用 Terraform 管起来，把服务器彻底掌控住。这其实是错误的第一步。如果你的部署流程还停留在"SSH 登录服务器跑一个脚本"，那给运行脚本的那台机器套上 Terraform，并不能解决真正的故障根源：一个人在时间压力下手动执行一个本该可重复的任务，而且没有回滚方案。
第一笔自动化投入应该花在 CI/CD 上：一条每次推送都会运行的流水线，每次都跑相同的测试，每次都以相同的方式部署。具体来说：
- 每次合并到 main 分支都会触发构建和测试套件——没有例外，也没有"就这一次"的手动推送。
- 部署环节是流水线中的一项任务，而不是某个人的终端窗口。GitHub Actions、GitLab CI 或 CircleCI 都能胜任；工具本身是次要的，关键在于每次都严格遵守这套流程的纪律性。
- 回滚是一个按钮，而不是靠某人在晚上11点凭记忆找出上一个已知可用的提交哈希。
先做这一步的团队，通常在第一个月内就能看到部署相关事故明显减少，而且还没碰过一个 Terraform 文件。原因在于：这个阶段大多数所谓的"基础设施"事故，根本不是基础设施问题。它们是披着基础设施外衣的流程问题——一个只存在于某个工程师脑子里的配置值、一个被忘记执行的迁移步骤、一次和另一次部署顺序搞反的发布。
接下来，让环境可复现
部署自动化之后，下一个故障模式就会浮出 水面："在预发布环境（staging）能跑通，生产环境却不行"，更糟的是"我们已经想不起来 staging 环境当初是怎么搭起来的"。这正是基础设施即代码真正该出场的地方——不是第一步要修的东西，而是第二步。
用 Terraform 或 OpenTofu 模块把你的 AWS、GCP 或 Azure 环境描述成受版本控制的代码，解决的是一个具体问题：环境漂移。没有 IaC 的话，每个环境都会不断积累细小、未被记录的差异——这里手动调大了一次实例规格，那里在处理事故时加了一条安全组规则——直到 staging 环境不再能可靠地预测生产环境的行为。
一开始就追求"100%自动化基础设施"并不现实。真正务实的目标是：你能否在一小时内仅凭代码销毁并重建 staging 环境，完全不依赖任何只存在于个别人脑子里的经验？如果答案是不能，那就是接下来该修的问题——排在 Kubernetes、多区域部署，以及任何更宏大的目标之前。
预览环境，补上 CI/CD 留下的缺口
在部署已经自动化、基础设施可复现之后，下一个杠杆点是给每个 pull request 配一个用完即弃的独立环境。这一步经常被团队跳过，因为它感觉像是奢侈品，但它往往是继前两步之后杠杆效应最大的一项自动化投入。
没有预览环境时，"这个改动到底能不能跑通"这个问题只能在共享的 staging 环境里验证，这意味着每个工程师的改动都会和其他人的互相冲突。QA 变成了排队等待的队列。等到发现 bug 时，往往已经有好几处改动叠加在一起，排查成本也随之升高。预览环境——按每个 PR 单独启动、合并后自动销毁——把这条排队的队列重新变回并行、互不干扰的测试。在修好部署流水线之后再加上这一步的团队，通常会发现从评审到合并的时间有所缩短，因为评审者 可以直接点开一个链接看到改动真实运行的样子，而不必只靠读 diff 来凭空信任它。
什么该放到最后自动化，而不是最先
渐进式发布——金丝雀发布、功能开关（feature flags）、错误率飙升时的自动回滚——确实真实有效，但这是一项更后期才该做的投入。它解决的问题是"如何安全地向生产流量发布"，而这个问题只有在向生产环境发布本身已经足够可靠、足够无聊之后才真正重要。在还没有可用的 CI/CD 之前就先搭建金丝雀发布基础设施的团队，其实是在为错误的风险做自动化；如果底层部署仍然依赖某人按正确顺序敲对命令，那再精巧的流量调度逻辑也无济于事。
对大多数成长中的团队来说，Kubernetes 也属于同一类"后期再说"的选项。它确实解决了真实的问题——自动扩缩容、资源隔离、服务自愈——但同时也带来了实实在在的运维复杂度：manifest 文件、Helm chart、集群升级、RBAC 权限。团队规模在20人左右以下、只维护少数几个服务的情况下，通常用一个更简单的平台（比如 ECS、Cloud Run，或某个托管 PaaS）配上扎实的 CI/CD，效果会更好。只有当你的服务数量多到编排问题真实存在时，才该转向 Kubernetes，而不是因为"下一步理应如此"。
一个现实可行的顺序，以及它的成本
对于刚从手动或半手动部署走出来、规模在15到25名工程师之间的团队，这样的顺序通常管用：第一步是带自动化测试和一键回滚的 CI/CD 流水线（通常需要2–4周）；第二步是核心环境的基础设施即代码（再需要3–5周，具体取决于已经积累了多少环境漂移）；然后再在此基础上叠加预览环境和监控告警。单独搭建一套 CI/CD 通常从 $8,000 起；完整的顺序——CI/CD 加基础设施即代码再加预览环境——通常从 $25,000+ 起，具体取决于涉及的服务和环境数量。这是一个分阶段推进的过程，我们的云与 DevOps团队会按阶段逐一评估范围，而不是当作一个没有边界的整体平台重建来做。
要避免的错误是把这一切当成一个有单一上线日期的大型基础设施项目来做。每个阶段都应该独立交付、立刻开始产生回报——一条能正常运作的 CI/CD 流水线本身就有价值，哪怕背后还没有 Terraform 撑腰。
结论
当手动部署开始出问题时，解法不是"再买一些 DevOps 工具"。真正的关键是顺序：先流水线，再可复现的基础设施，然后是预览环境，只有等这些基本功已经变得"无聊"之后，才轮到渐进式发布和编排系统。按这个顺序自动化的团队，往往在第一个月就能解决掉最严重的那批事故。而那些一上来就选用清单里最复杂工具的团队，通常会花上整整一个季度去搭建基础设施，结果部署流程骨子里依然是手动的。
