客户是一家物流服务商，每天处理数万笔订单，晚间和促销期间会出现流量高峰，并对合作零售商承诺严格的 SLA。基础设施在缺乏规划的情况下不断扩张：分散的 VPS、留在「服务器上」的配置，以及按照 wiki 说明手动部署。每次发布都要夜间上线并造成停机；每次高峰都伴随着订单丢失的风险。一次新年前促销事故中，平台停摆四小时，服务商不得不赔偿合作方，这促使他们向我们求助。
在不停止业务的情况下迁移到可管理的基础设施：
基础设施即代码、自动化交付、容器化与编排、可观测性，以及可预测的故障恢复。创始人这样定义成功：「在工作时间部署、不停机，也不需要有人通过 SSH 登录操作」。
我们按照经过验证的顺序推进：先使用容器并建立可复现的环境，再自动化交付，最后才引入带自动扩缩容的编排。
- 审计基础设施：绘制服务与依赖关系图，测量高峰负载曲线，并登记最常导致事故的手工操作。
- 将服务容器化：统一构建方式，将配置从代码移至环境变量，并建立相同的 dev/stage/prod 环境。
- 使用 Terraform 将基础设施写成代码：从仓库部署环境，禁止在云服务商控制台中手动修改。
- 搭建 GitLab CI 流水线：自动运行测试和构建镜像；stage 立即部署，prod 经审核后按按钮部署；一次操作即可回滚。
- 迁移到支持自动扩缩容的 Kubernetes：晚间和促销高峰由平台自动增加实例，不再依赖人工紧急处理。
- 部署监控和告警，以延迟、错误、流量和资源饱和度等黄金信号指标为核心，并设置值班及升级流程。
- 配置备份与灾难恢复：制定恢复流程，并在 stage 上演练故障、测量实际 MTTR。
项目最有价值的不是技术本身，而是责任方式的改变：基础设施不再依赖「持有 SSH 权限的人」。每次部署都可复现，每个环境都能从代码恢复，任何故障都会在第一位客户发消息之前显示在仪表盘上。这样，停机不再是灾难，而是按清晰手册处理、恢复时间可测量的日常事故。
项目的经济效益由三部分组成：借助自动扩缩容并取消持续预热的「峰值」容量，基础设施成本直接下降 32%；团队节省了过去用于夜间发布的工时；最重要的是，高峰期现在无事故，收入得以保留。一家大型零售连锁客户正是在新基础设施上的首次促销后续签了合同。
| 指标 | 结果 |
|---|---|
| 版本部署 | 人工 3–4 小时 → 自动化 15 分钟 |
| 发布频率 | 每月 2–3 次 → 几乎每天 |
| 平台可用性 | 97,8% → 99,95% |
| 高峰负载 | 停机风险 → 无需人工干预的自动扩缩容 |
指标取自案例原始材料。仅在来源明确记录时注明统计周期。
- 版本部署（此前人工需 3–4 小时）
- 15分钟
- 平台可用性（此前为 97.8%）
- 99.95%
- 故障后的恢复时间（此前为 2–4 小时）
- 20–30分钟
- 基础设施成本
- −32%
版本部署时间，分钟
数值越低越好恢复时间（MTTR），分钟
数值越低越好平台停机时间
数值越低越好图表显示区间上限（4 小时、30 分钟）。停机率 = 100% − 可用性。
- 01提交代码
- 02测试
- 03镜像构建
- 04预发布环境立即
- 05生产环境审核后按按钮部署
下一阶段基础设施的发展方向：
- FinOps 实践：为成本异常设置告警，并按团队透明展示费用。
- GitOps 方法：将 prod 状态描述在仓库中，所有更改仅通过 pull request 进行。
- 多区域部署：复制关键服务，以提高应对云服务商故障的韧性。
以前发布意味着通宵、咖啡和祈祷。现在只要按一下按钮，等十五分钟。第一次在新基础设施上平安度过促销，全公司一起庆祝。
— 物流服务技术总监