度量体系设计：从DORA到平台工程度量金字塔
DORA 指标为软件交付效能提供了行业基准，但直接将其套用在平台工程场景中会出现“度量断层”——平台团队不直接部署应用，如何衡量其价值？本章引入平台工程度量金字塔，将 DORA 指标逐层映射到平台服务目录，构建从基础设施到业务价值的完整度量链路。
1. 度量断层：为什么 DORA 不能直接用于平台工程？
DORA 的四个核心指标（部署频率、变更前置时间、变更失败率、故障恢复时间）面向应用交付团队。平台工程团队提供的是内部开发平台（IDP），其产出是服务目录中的各类能力（计算、存储、CI/CD、可观测性等）。直接套用会导致：
- 指标错配：平台不部署业务代码，无法计算“部署频率”。
- 责任模糊：变更失败率可能由平台变更或应用变更共同导致，难以归因。
- 价值脱节：平台团队优化了基础设施交付速度，但业务团队感受不到。
核心观点：平台工程的度量需要“翻译层”——将 DORA 的交付效能指标，映射为平台能力的采用率、交付速度、稳定性和开发者体验指标。
2. 平台工程度量金字塔：四层结构
我们设计了一个四层度量金字塔，从底层基础设施到顶层业务价值，逐层映射 DORA 指标：
设计原则：每一层都回答一个关键问题——底层回答“平台跑得稳吗？”，顶层回答“平台让业务更快了吗？”
| 层级 | 名称 | 核心问题 | 对应 DORA 指标 |
|---|---|---|---|
| L4 | 业务价值层 | 平台是否加速了业务交付？ | 部署频率、前置时间（间接） |
| L3 | 开发者体验层 | 开发者使用平台是否顺畅？ | 变更前置时间（感知） |
| L2 | 平台效能层 | 平台自身的交付和变更是否高效？ | 部署频率、变更失败率 |
| L1 | 基础设施层 | 底层资源是否稳定、可用？ | 故障恢复时间（MTTR） |
3. 映射方法：将 DORA 指标翻译为平台服务目录指标
平台工程服务目录中的每一项服务（如“Kubernetes 集群服务”、“CI/CD 流水线服务”、“日志收集服务”）都需要一套对应的度量指标。映射的核心逻辑是：将 DORA 的“交付”概念替换为“能力交付”。
3.1 部署频率 → 服务目录采用率与交付频率
- DORA 原意：应用代码部署到生产环境的频率。
- 平台映射：平台服务被开发者采用的频率，以及平台自身发布新版本的频率。
- 示例指标：服务目录中“CI/CD 模板”的月采用增长率、平台 API 的周版本发布次数。
3.2 变更前置时间 → 能力就绪时间
- DORA 原意：从代码提交到生产部署的时间。
- 平台映射：从开发者请求平台能力到能力可用的时间。
- 示例指标：从提交“创建 PostgreSQL 实例”工单到实例就绪的时长（P50/P95）。
3.3 变更失败率 → 平台变更事故率
- DORA 原意：部署导致生产故障的比例。
- 平台映射：平台组件变更（升级、配置修改）导致服务降级或中断的比例。
- 示例指标：平台版本升级导致的“服务目录不可用”事件数 / 总变更次数。
3.4 故障恢复时间 → 平台自愈时间
- DORA 原意：从故障告警到服务恢复的时间。
- 平台映射：平台基础设施或服务目录中的某个能力从故障到自动/手动恢复的时间。
- 示例指标：Kubernetes 集群节点故障到 Pod 重新调度的 MTTR。
常见误区：不要试图让平台团队背“应用部署频率”的指标。平台团队的职责是缩短“能力就绪时间”，而不是直接控制业务应用的部署行为。度量错配会导致平台团队优化错误的方向。
4. 服务目录中的度量锚点：每个服务都需要一个“度量卡片”
在平台工程服务目录中，每个服务条目都应附带一个度量卡片，明确该服务在金字塔各层的指标。以下是一个示例：
| 服务名称 | 层级 | 度量指标 | 目标值 |
|---|---|---|---|
| Kubernetes 集群服务 | L1 基础设施 | 集群 API Server 可用性 | 99.95% |
| L2 平台效能 | 集群版本升级失败率 | < 5% | |
| L3 开发者体验 | 命名空间创建到就绪时间（P95） | < 30 秒 | |
| CI/CD 流水线服务 | L2 平台效能 | 流水线模板发布频率 | 每周 ≥ 2 次 |
| L3 开发者体验 | 流水线执行成功率 | ≥ 95% | |
| L4 业务价值 | 使用平台流水线的应用部署频率 | 每日 ≥ 1 次（由应用团队达成） |
5. 落地步骤：从金字塔到仪表盘
- 盘点服务目录：列出平台提供的所有服务能力（至少 10-20 项）。
- 分配金字塔层级：为每项服务确定其所属的度量层级（L1-L4）。
- 映射 DORA 指标：按照上述映射逻辑，为每项服务定义 2-3 个核心指标。
- 设定基线：收集过去 1-3 个月的数据，确定当前基线值。
- 构建仪表盘：将度量卡片汇总到统一仪表盘，按金字塔层级分层展示。
- 持续校准：每季度回顾指标是否仍然有效，根据平台演进调整映射关系。
快速启动建议：不必一开始就覆盖所有服务。选择 3 个最核心的平台服务（如计算、CI/CD、可观测性），先完成它们的度量卡片设计和数据采集，验证映射逻辑后再推广到整个服务目录。
6. 小结：度量金字塔的价值
平台工程度量金字塔解决了 DORA 指标在平台场景中的“水土不服”问题。通过将 DORA 的四个核心指标逐层映射到服务目录的度量卡片，平台团队可以：
- 对齐业务价值：L4 指标直接关联业务交付速度，让平台投入可量化。
- 明确改进方向：L2 和 L3 指标暴露平台自身的瓶颈（如能力就绪时间过长）。
- 建立共同语言：平台团队和应用团队使用同一套度量框架沟通，减少认知偏差。