3、部署频率SLI口径（初级）：基于环境维度的口径（生产环境 vs 非生产环境），如何定义一次“部署”
在DORA度量体系中，部署频率（Deployment Frequency, DF）是最核心的四个指标之一。对于初学者而言，最容易混淆的问题就是：“到底什么算一次部署？” 本章从环境维度出发，明确区分生产环境与非生产环境的部署定义，帮助团队建立统一、可复用的SLI口径。
3.1 为什么需要区分环境维度？
不同环境的部署目的、风险等级、触发方式差异巨大。如果不加区分地混用口径，会导致以下问题：
- 口径膨胀：将CI/CD流水线中的每一次构建推送都计为“部署”，导致DF数值虚高，失去业务参考价值。
- 口径收缩：只统计生产环境的正式发布，忽略非生产环境的验证性部署，无法反映团队的交付节奏。
- 跨团队不可比：A团队将“合并到主分支”视为部署，B团队将“上线到生产集群”视为部署，两个DF无法横向对比。
核心原则：部署频率SLI的口径必须与环境维度绑定。生产环境与非生产环境应分别定义、分别统计，最终在仪表盘中以“分层视图”呈现。
3.2 生产环境部署的定义
生产环境部署是指将软件变更正式交付给最终用户使用的行为。这是DORA度量中最受关注的部署类型，直接反映团队向客户交付价值的速度。
| 判定维度 | 生产环境部署定义 | 典型反例（不应计为部署） |
|---|---|---|
| 变更生效 | 代码/配置变更已到达生产环境，并对真实用户流量产生影响 | 仅合并PR、仅通过CI构建、仅推送镜像到仓库 |
| 流量接入 | 变更后的服务实例已接入生产流量（如负载均衡器、网关路由已切换） | 灰度发布中仅部署到金丝雀节点但未放量 |
| 可观测性 | 部署完成后，监控/告警系统已开始采集新版本的业务指标 | 仅完成数据库迁移脚本执行，未启动应用 |
| 回滚能力 | 该部署具备明确的回滚机制（蓝绿、金丝雀、滚动回退） | 手动替换二进制文件且无版本记录 |
实战建议：对于生产环境，推荐使用“部署完成事件”作为计数锚点。例如：Kubernetes Deployment 的
AvailableReplicas == Replicas 且持续 30 秒无回滚触发，计为一次生产部署。
3.3 非生产环境部署的定义
非生产环境（开发、测试、预发布、Staging等）的部署定义相对宽松，但同样需要明确边界，避免“每次代码提交都算一次部署”的过度统计。
| 环境类型 | 部署定义 | 计数条件 |
|---|---|---|
| 开发环境 | 代码变更通过CI流水线自动部署到开发沙箱，供开发者自测 | 每次CI流水线执行到“部署”阶段并成功完成 |
| 测试环境 | QA团队触发的自动化部署，用于执行集成测试或端到端测试 | 测试环境部署任务完成，且测试脚本开始执行 |
| 预发布环境 | 模拟生产环境的全量部署，用于验收和性能验证 | 部署完成后，预发布环境健康检查通过 |
避坑提示：不要将“构建（Build）”与“部署（Deploy）”混为一谈。构建是将源代码编译为制品（如Docker镜像、JAR包），部署是将制品运行到目标环境。只有制品在目标环境中启动并对外提供服务，才应计为一次部署。
3.4 部署定义的核心判定模型
为了帮助团队快速判断“一次部署是否成立”，我们设计了一个三层判定模型。该模型适用于生产环境和非生产环境，仅判定阈值不同。
3.5 部署频率SLI的计数规则
基于上述定义，我们给出具体的计数规则。团队应按照环境维度分别统计，并在仪表盘中展示分层数据。
计数公式：
生产环境部署频率 = 统计周期内满足“三层判定模型”的部署次数 / 统计周期天数
非生产环境部署频率 = 统计周期内满足“前两层判定模型”的部署次数 / 统计周期天数
生产环境部署频率 = 统计周期内满足“三层判定模型”的部署次数 / 统计周期天数
非生产环境部署频率 = 统计周期内满足“前两层判定模型”的部署次数 / 统计周期天数
| 场景 | 是否计为部署 | 说明 |
|---|---|---|
| Git push 触发CI构建 | ❌ 不计 | 仅完成构建，未部署到任何环境 |
| CI流水线将制品部署到开发环境 | ✅ 计为非生产部署 | 满足前两层判定模型 |
| QA手动触发测试环境部署 | ✅ 计为非生产部署 | 满足前两层判定模型 |
| 蓝绿发布：新版本部署到Standby集群 | ❌ 暂不计 | 未接入流量，需等待流量切换完成 |
| 蓝绿发布：流量切换到新版本集群 | ✅ 计为生产部署 | 满足三层判定模型 |
| 金丝雀发布：1%流量进入新版本 | ✅ 计为生产部署 | 已接入生产流量，即使比例很小 |
| 配置变更通过Feature Flag动态生效 | ⚠️ 视情况 | 若Flag切换伴随部署动作则计，纯配置热加载不计 |
3.6 实战案例：统一口径落地
某互联网团队在推行DORA度量初期，发现部署频率数据波动极大。经排查，问题出在口径不统一：
- 后端团队：将每次Kubernetes Deployment的滚动更新都计为一次部署，包括镜像Tag不变仅重启Pod的情况。
- 前端团队：将每次CDN缓存刷新都计为一次部署，包括仅修改文案的静态资源推送。
- 数据团队：将每次Airflow DAG的调度执行都计为一次部署，包括无代码变更的定时重跑。
经过本章口径对齐后，团队达成以下共识：
- 统一判定模型：所有团队使用三层判定模型，生产环境必须满足“变更提交→环境交付→流量生效”。
- 环境标签化：在CI/CD流水线中为每个部署事件打上环境标签（production/staging/test/dev），确保数据可分层。
- 排除非部署事件：Pod重启、配置热加载、静态资源CDN推送（无应用代码变更）等行为，统一从部署频率中排除。
- 建立口径文档：将定义、判定模型、计数规则写入团队Wiki，作为SRE和DevOps的基线标准。
落地检查清单：
✅ 是否已区分生产环境与非生产环境的部署定义？
✅ 是否已排除“构建”和“重启”等非部署事件？
✅ 是否已在CI/CD流水线中为部署事件添加环境标签？
✅ 是否已建立口径文档并完成团队对齐？
✅ 是否已区分生产环境与非生产环境的部署定义？
✅ 是否已排除“构建”和“重启”等非部署事件？
✅ 是否已在CI/CD流水线中为部署事件添加环境标签？
✅ 是否已建立口径文档并完成团队对齐？
3.7 本章小结
部署频率SLI的口径定义是DORA度量的基石。基于环境维度的口径设计，要求团队：
- 生产环境：严格使用三层判定模型，以“流量生效”为最终确认条件。
- 非生产环境：使用前两层判定模型，以“环境交付完成”为计数条件。
- 统一排除：构建、重启、配置热加载等行为不计入部署频率。
- 分层统计：生产环境与非生产环境分别统计，避免口径混用导致数据失真。