持续部署（CD）原理与实践归纳总结
持续部署，说白了就是让每一行通过自动化测试的代码，都能自动跑到生产环境上。你可能觉得这有点激进，但我在多个项目中实践下来，只要配套的监控和回滚机制到位，它反而比手动部署更稳。
持续部署 vs 持续交付：就差一个“手动门”
很多人把这两个混为一谈。我刚开始也迷糊过。持续交付是“随时可部署”，但需要人工点一下按钮。持续部署则是“全自动”，连那个按钮都省了。你想想看，其实差的就是风险偏好。
- 持续交付：代码经过 CI 和验收测试后，生成可部署的产物，但手动触发生产部署。
- 持续部署：所有通过测试的分支变更，自动推送到生产环境，无人干预。
我的建议：如果团队刚开始推行，先从持续交付做起，等监控和回滚能力成熟了再切到全自动。我在一家金融客户那里吃过亏——当时监控还没覆盖全链路就上了自动部署，结果一个配置错误影响了十分钟用户体验，虽然很快回滚了，但业务方还是骂了好久。
部署策略选型：没有银弹，只有适配
自动部署不代表“一把梭”。不同业务场景要选不同策略。我总结了一个常用对比表：
| 策略 | 风险 | 速度 | 成本 | 适用场景 |
|---|---|---|---|---|
| 蓝绿部署 | 低（全量切换） | 快 | 高（需双倍资源） | 关键业务，允许短时资源浪费 |
| 金丝雀部署 | 极低（小流量试探） | 慢（需逐步放量） | 中（部分额外资源） | 高流量、高要求稳定性 |
| 滚动部署 | 中（逐台替换） | 适中 | 低（利用现有资源） | 微服务、无状态应用 |
举个例子，我在一个电商大促前部署推荐服务，用的是金丝雀——先放 1% 流量，观察五分钟错误率和响应时间，没问题再逐步扩大到 100%。那次正好发现新版本有内存泄漏，金丝雀阶段就暴露了，避免了全站崩溃。
CD 流水线中的关键环节
一个可靠的 CD 流水线，远不止“跑个脚本把包传上去”。我习惯把它拆成以下步骤：
- 构建与制品管理：生成不可变的 Docker 镜像或压缩包，并推送到制品仓库（比如 Harbor、Nexus）。
- 自动部署审批（可选）：对于生产环境，即使全自动，也可以设置“破窗门禁”——例如异常检测模型打分低于阈值则暂停。
- 基础设施即代码：用 Terraform、Ansible 或 Kubernetes YAML 定义部署目标。我曾在项目中遇到手动修改服务器配置导致部署失败的坑——后来全部改成 IaC，再没出过类似问题。
- 优雅启停：确保新进程启动后，旧进程持续服务直到新进程通过健康检查。Kubernetes 的 readiness probe 就是个好例子。
举个例子，一个典型的 Kubernetes 部署配置：
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
spec:
containers:
- name: myapp
image: registry.example.com/myapp:v1.2.3
livenessProbe:
httpGet: /healthz
initialDelaySeconds: 5
readinessProbe:
httpGet: /ready
initialDelaySeconds: 3
关键点：readinessProbe 是区分“活着”和“就绪”的关键。我曾经因为只配了 livenessProbe，导致新 Pod 还没完全加载就接入流量，直接 502 报错。
监控在 CD 中的“刹车”作用
没有监控的自动部署就像开车不踩刹车。尤其在金丝雀和滚动策略中，监控指标是决定继续放量还是回滚的唯一依据。我常用的监控指标包括：
- 错误率：HTTP 5xx 比例，超过基线 +1% 就触发回滚。
- 响应时间 P99：如果新版本比旧版本慢 20% 以上，自动停止。
- 资源使用率：CPU、内存、磁盘 I/O 异常飙升。
- 业务指标：比如订单转化率、支付成功率——这些最接近用户体验。
我曾经踩过的坑：只监控了基础设施指标，忽略了业务指标。那次部署后服务器一切正常，但下单接口因为缓存失效导致大量超时——直到运营反馈才发现。从那以后，我坚持在 CD 流程中加入至少一个业务级监控门禁。
最后聊一句：CD 的成熟度不是一蹴而就的。我通常建议团队从流水线可视化开始，把每个环节的耗时、失败率、部署频率都画出来——这就是后面章节要讲的瀑布图监控的基础。先有数据，再优化。