Middleware：以 DORA 指标衡量工程效能的轻量级平台

工程效能度量一直是个难题：代码行数容易误导，交付时间难以追踪，团队反馈又偏主观。Middleware 想用 DORA 指标把这件事变得可操作。它是一套开源平台，基于 Docker、Python、Node.js 构建，许可证为 Apache-2.0，部署在自己的基础设施上，数据不出内网。

DORA 指标落地：从四件事开始度量

Middleware 的核心是围绕 DORA 指标设计：部署频率、变更前置时间、变更失败率、恢复服务时间。它不直接给你一个笼统的“生产力分数”，而是把软件交付拆成这几个可量化的环节。安装后，它会自动对接代码仓库和 CI/CD 工具，追踪每次提交到部署的耗时、部署的频次、失败回滚的比例。

这些指标对工程负责人意味着什么？部署频率低，可能说明发布流程卡顿；变更前置时间长，或许在提示代码评审或测试环节积压；变更失败率高，则指向质量门禁不够。Middleware 把原始数据变成图表和趋势线，让团队看到改进的方向，而不是凭感觉开会。

从顶层到底层：强调可采纳性的设计

Middleware 的宣传语里有一句很关键：平台“从组织顶层到底层都易于采纳”。这反映在设计上：仪表盘不仅给管理者看，也给一线工程师看。工程师能看到自己的变更何时进入生产、有没有引发故障，而管理者看到的是团队整体节奏。这种自上而下的透明度，减少了度量工具常见的抵触感。

它提供的是开箱即用的体验，不用从零构建数据管道。官方描述提到“开箱即用”地衡量生产力、追踪关键指标、简化交付流程。这意味着部署 Middleware 后，它会自动采集数据，而不是要求团队先手动埋点或定义一堆自定义事件。

真实场景：三个典型用法

场景一：新晋工程经理想摸清团队节奏。他部署 Middleware，连接 GitHub 和 Jenkins，两周后就能看到部署频率的基线。如果发现每周只发一次版，他可以和团队讨论是否拆分发布批次，然后观察指标是否改善。

场景二：团队想验证“重构是否真的提高了交付速度”。重构前，变更前置时间中位数是 3 天；重构后，Middleware 显示中位数降到 1.5 天。这个数据可以作为复盘时的客观依据，而不是“感觉变快了”。

场景三：跨多个服务的大型项目，想识别哪个服务拖累整体交付。Middleware 可以按服务或团队拆分 DORA 指标，找到变更失败率最高的那个服务，优先投入技术改进。

开源与自托管的边界

Middleware 的开源属性（Apache-2.0）让它可以完全自托管，这对数据敏感的企业很有吸引力。工程数据——代码提交时间、部署记录、失败日志——属于高度敏感信息，放在第三方 SaaS 上可能不合规。自托管意味着数据留在自己的 VPC 里，访问控制也由自己的团队管理。

不过，自托管也需要投入运维资源。Middleware 基于 Docker，部署不算复杂，但更新、备份、扩容仍需有人负责。如果团队没有 DevOps 人力，这可能是一个负担。另外，DORA 指标只是起点，Middleware 并不包含类似“代码质量评分”或“开发者体验调查”的功能，它聚焦在交付流程本身。

Middleware 适合那些已经认同 DORA 理念、想要一个可定制的度量平台的团队。如果你只需要高层看板，可能用现成的 SaaS 工具更省事；但如果你希望数据完全可控，并且愿意投入少量运维，Middleware 是一个务实的选择。

FAQ：常见问题

Middleware 是免费的吗？

Middleware 采用 Apache-2.0 开源许可证，这意味着你可以免费使用、修改和分发它，前提是保留版权声明。它没有“免费版”或“专业版”的区分，因为整个平台都是开源的。不过，自托管需要自己承担服务器和运维成本。

Middleware 适合什么样的团队？

它适合那些希望用 DORA 指标改进交付流程、但不想把工程数据交给第三方 SaaS 的团队。尤其是已经有成熟 DevOps 实践、能承担自托管运维的工程组织。对于刚起步的小团队，可能更简单的工具就够用。