4. 部署频率指标：度量单位、收益与风险

部署频率（Deployment Frequency, DF）是衡量服务交付节奏的核心指标，也是 DORA 四关键指标之一。它直接反映团队将代码变更推送到生产环境的速度，是平台工程和 SRE 团队评估交付管道健康度的首要观测点。

4.1 部署频率的度量单位

部署频率的度量单位根据服务类型、业务场景和团队成熟度有所不同。常见的度量单位包括：

4.2 高频部署的收益

提升部署频率（从周级向天级甚至小时级演进）能够带来可量化的工程收益：

• 缩短变更前置时间：从代码提交到生产部署的时间窗口从数天压缩到数小时，减少上下文切换成本。
• 降低单次变更风险：每次部署包含的变更量变小，问题定位范围从数十个 commit 缩小到 1-3 个 commit。
• 加速故障恢复：高频部署意味着回滚和热修复的路径同样高频，MTTR 显著下降。
• 提升团队交付信心：高频、小批量的部署模式让团队对生产变更脱敏，减少“发布恐惧症”。
• 增强业务响应能力：市场需求的变更可以在数小时内转化为生产功能，而非等待数周。

4.3 高频部署的风险与代价

盲目追求高频部署而不配套相应的工程能力，会引入新的风险：

4.4 部署频率与变更失败率的平衡关系

部署频率和变更失败率之间存在非线性关系。下图展示了在不同工程成熟度下，两者的典型分布区间：

4.5 服务目录中的部署频率建模

在服务目录中，部署频率不应仅作为一个静态数值记录，而应建立包含以下维度的模型：

1. 目标频率（Target DF）：由 SLO 定义的服务期望部署节奏，通常与服务的变更风险等级挂钩。
2. 实际频率（Actual DF）：通过 CI/CD 管道事件自动采集的最近 N 天（如 30 天）平均部署次数。
3. 频率偏差（DF Drift）：实际频率与目标频率的比值，用于触发告警或容量规划。
4. 部署窗口（Deployment Window）：允许部署的时间段，用于合规性校验。
5. 变更失败关联：每次部署后 1 小时内是否触发 P1/P2 告警，用于计算变更失败率。

{
  "service": "payment-gateway",
  "deployment_frequency": {
    "target": "2次/天",
    "actual_30d": "1.8次/天",
    "unit": "次/天",
    "window": "09:00-18:00 UTC+8",
    "drift_percent": -10
  },
  "change_failure_rate": {
    "target": "<5%",
    "actual_30d": "3.2%"
  }
}

4.6 调优策略：从当前频率向目标频率演进

根据服务目录中记录的当前部署频率与目标频率的差距，可以采取以下调优路径：