Repo Intelligence
一个不指出原因的指标只是装饰。每一个数字都应附带支撑它的 PR、任务或文件。
DORA 四项关键指标
指标 | 从仓库数据计算
部署频率 | 发布次数，或合并到仓库实际部署所用分支的次数
变更前置时间 | 按 PR 计算，从分支上的首次提交到合并
变更失败率 | 合并后在失败窗口内被 revert、hotfix 分支或引用该合并的 incident 标签 issue 所跟随的合并比例
恢复时间 | 从 incident issue 打开到关闭它的 PR 被合并
报告 p50 与 p90，绝不用平均值。平均前置时间会被少数搁置一个月的 PR 主导，并掩盖其他所有人的体验。p90 才是团队实际感受到的。
拆解前置时间
“前置时间上升了”不可行动。把它拆开，让回归有明确指向：
首次提交 → 打开 PR 打开 PR → 首次评审 ← 通常是回归所在 首次评审 → 批准 批准 → 合并
然后归因到发生变化的那一阶段。首次评审时间的回归几乎总是以下之一：评审人未分配、某位评审人不在时仍持有队列、PR 变大，或团队边界变化。命名原因前先逐一检查。
变更失败归因
仅有比率不可用。列出失败变更及其共同点：
变更失败率：14%（51 个中的 7 个） 7 个中有 5 个触及 src/billing/** ← 集中 7 个中有 6 个仅带一个批准即合并 7 个中有 4 个超过 800 行
集中的失败是可修复的问题。分散的失败是流程问题。要说明你面对的是哪一种。
热点
risk = normalized_churn × normalized_defect_density × complexity_factor
仅 churn 不是风险——配置文件频繁变更却不会破坏任何东西。排除生成文件、lockfile 和 vendored 路径，否则它们会淹没信号。
诊断机制，而不仅是排名：god file · central registry · missing abstraction · implicit coupling · under-tested · ownership drift。
归属
漂移——CODEOWNERS 点名一个人，近期提交却来自别人。这会预示评审缓慢。
巴士因子——持有某模块近期提交 ≥ 20% 的作者。
最重要的组合：一个文件既是热点又是 bus-factor-1。只有一个人能理解的脆弱代码是仓库中风险最高的对象。始终显式指出这一组合。
CODEOWNERS 是最后匹配优先——与 .gitignore 相反。一个宽泛的 * 放在具体规则之后会静默覆盖它。在断定某路径已被覆盖前先检查顺序。
Flake 成本
用浪费的 CI 分钟数报告 flake 成本，而不只是百分比。分钟数会让 flake 被修复；百分比会让它们被容忍。
对数据质量保持诚实
明确说明局限。没有发布标签 → 部署频率只是代理指标。没有标签的 incident → 恢复时间不可测量；应如实说明，而不是从糟糕的代理指标计算。在一个窗口内提交少于约 50 次时，热点排名是噪声——应扩大窗口，而不是报告一个自信的顺序。
一个自信但错误的指标比缺失的指标更糟，因为有人会据此做计划。
另见
../commands/insights.md · ../commands/ownership.md