从发布台账算出平台指标

目标

从一张记录 28 天部署情况的台账中，亲自计算 DORA 四项指标、采用率和错误预算。练习从台账中提取数据，而不是凭目测填写数值。

为什么重要

围绕指标的争论大多不是始于定义，而是始于计算方法。取平均值还是中位数，分母用部署次数还是失败次数，如何统计活跃使用，这些选择会让同一份数据产生相差数倍的结果。平台团队引入指标时，第一件事应是把计算方法固化为代码，确保任何人运行都得到相同结果。本练习的评分器也按同样原理工作：它不会相信你填写的数字，而会从台账重新计算并进行核对。

步骤

将部署台账抄写到 /root/cnpa-metrics/deploys.csv。表头为 service,day,lead_min,result,restore_min，数据共 15 行。内容必须与格式示例完全一致。result 为 success 或 failed，成功部署的 restore_min 为 0。
在 /root/cnpa-metrics/freq.json 中写入部署频率。键为 window_days（28）、weeks（4）、per_week；per_week 中写入各服务每周部署次数，保留两位小数。只包含台账中的三个服务。
在 /root/cnpa-metrics/lead.json 中写入交付周期中位数。键为 median_min（各服务的中位数）和 overall_median_min（全部 15 次部署的中位数）。
在 /root/cnpa-metrics/cfr.json 中写入变更失败率。键为 total、failed、cfr_pct（保留一位小数）。
在 /root/cnpa-metrics/mttr.json 中写入恢复时间。键为 failed、mean_restore_min（失败部署的平均恢复时间，保留一位小数）、max_restore_min。
在 /root/cnpa-metrics/dora.json 中写入四项指标的等级。键为 deploy_frequency、lead_time、change_failure_rate、mttr，值为 Elite、High、Medium、Low 之一。阈值如下：部署频率（全部部署次数除以 4 周所得的每周次数）大于等于 7 为 Elite，大于等于 1 为 High，大于等于 0.25 为 Medium，低于该值为 Low。交付周期（总体中位数，分钟）低于 60 为 Elite，低于 1440 为 High，低于 10080 为 Medium，否则为 Low。变更失败率不高于 5% 为 Elite，不高于 10% 为 High，不高于 15% 为 Medium，高于该值为 Low。恢复时间（平均值，分钟）使用与交付周期相同的阈值。
将服务名册抄写到 /root/cnpa-metrics/services.csv。表头为 service,onboarded_day,golden_path,last_deploy_day，数据共 6 行。然后在 /root/cnpa-metrics/platform-adoption.json 中写入采用情况。键为 total_services（名册中的服务数）、onboarded（golden_path 为 yes 的数量）、active（golden_path 为 yes 且 last_deploy_day 大于等于 15 的数量）、active_rate_pct（活跃数除以服务总数的百分比，保留一位小数）。
在 /root/cnpa-metrics/budget.json 中写入错误预算。平台 SLO 为 99.5%，窗口为 28 天。键为 slo_pct（99.5）、window_days（28）、budget_min（整个窗口分钟数的 0.5%）、burned_min（台账中恢复时间之和）、burn_pct（消耗率，保留一位小数）、remaining_min（剩余预算）。

参考

中位数可用 sort -n 排序后选取中间值。数量为奇数时取正中间一个。
使用 awk 'BEGIN { printf "%.1f", ... }' 调整小数位数。
使用 jq -n --argjson 创建 JSON，可避免数字变成字符串。
评分器会将你的 JSON 与台账核对。若试图修改台账来配合数字，第 1 步的评分会先失败。

抄写部署台账

将部署台账抄写到 /root/cnpa-metrics/deploys.csv。表头为 service,day,lead_min,result,restore_min，数据共 15 行。内容必须与格式示例完全一致。result 为 success 或 failed，成功部署的 restore_min 为 0。

这是所有计算的起点。即使只错一个字符，后续步骤的值也会全部改变，因此抄写后请用合计进行确认。

部署频率

在 /root/cnpa-metrics/freq.json 中写入部署频率。键为 window_days（28）、weeks（4）、per_week；per_week 中写入各服务每周部署次数，保留两位小数。只包含台账中的三个服务。

分别统计每个服务。28 天等于 4 周，数值保留两位小数。

交付周期中位数

在 /root/cnpa-metrics/lead.json 中写入交付周期中位数。键为 median_min（各服务的中位数）和 overall_median_min（全部 15 次部署的中位数）。

排序后取中间值。总体中位数应排列全部 15 次部署后计算，而不是对各服务中位数求平均。

变更失败率

在 /root/cnpa-metrics/cfr.json 中写入变更失败率。键为 total、failed、cfr_pct（保留一位小数）。

分母是部署次数，不是服务数，也不是事故数。百分比保留一位小数。

恢复时间

在 /root/cnpa-metrics/mttr.json 中写入恢复时间。键为 failed、mean_restore_min（失败部署的平均恢复时间，保留一位小数）、max_restore_min。

计算平均值时，除数是失败部署的数量。若除以全部部署次数，结果会小数倍。

判定等级

在 /root/cnpa-metrics/dora.json 中写入四项指标的等级。键为 deploy_frequency、lead_time、change_failure_rate、mttr，值为 Elite、High、Medium、Low 之一。阈值如下：部署频率（全部部署次数除以 4 周所得的每周次数）大于等于 7 为 Elite，大于等于 1 为 High，大于等于 0.25 为 Medium，低于该值为 Low。交付周期（总体中位数，分钟）低于 60 为 Elite，低于 1440 为 High，低于 10080 为 Medium，否则为 Low。变更失败率不高于 5% 为 Elite，不高于 10% 为 High，不高于 15% 为 Medium，高于该值为 Low。恢复时间（平均值，分钟）使用与交付周期相同的阈值。

严格使用说明中给出的阈值。部署频率按整个组织的 15 次部署除以 4 周所得的值判定。

采用率

将服务名册抄写到 /root/cnpa-metrics/services.csv。表头为 service,onboarded_day,golden_path,last_deploy_day，数据共 6 行。然后在 /root/cnpa-metrics/platform-adoption.json 中写入采用情况。键为 total_services（名册中的服务数）、onboarded（golden_path 为 yes 的数量）、active（golden_path 为 yes 且 last_deploy_day 大于等于 15 的数量）、active_rate_pct（活跃数除以服务总数的百分比，保留一位小数）。

入驻与活跃使用并不相同。活跃服务是已通过黄金路径入驻，并在最近 14 天内部署过的服务。活跃率的分母是全部服务。

错误预算

在 /root/cnpa-metrics/budget.json 中写入错误预算。平台 SLO 为 99.5%，窗口为 28 天。键为 slo_pct（99.5）、window_days（28）、budget_min（整个窗口分钟数的 0.5%）、burned_min（台账中恢复时间之和）、burn_pct（消耗率，保留一位小数）、remaining_min（剩余预算）。

28 天等于 40320 分钟。SLO 为 99.5%，因此其中的 0.5% 是该窗口的预算；消耗量为台账中恢复时间之和。