目录
当你的团队需要通过持续集成和持续交付(CI/CD)流水线将代码部署到生产环境时，衡量这些应用程序交付的速度和稳定性对于确保软件的高质量具有至关重要的意义。
Nicole Forsgren博士的《Accelerate》一书中介绍了四个软件交付性能指标，来衡量和可视化我们应用程序交付的速度和稳定性。eBay公司据此做出了尝试。
软件交付性能指标
以下是四个软件交付性能指标：
- 部署频率–你的组织多久一次将代码部署到生产环境？
- 变更准备时间–从提交代码，到在生产环境中成功运行要花多长时间？
- 变更失败率–部署中有多少次回滚，修补等？
- 平均恢复时间–出现问题时，需要多长时间恢复正常？
eBay公司据此，构建了一个可以实时跟踪和可视化所有这些指标的系统，并能够深查看该组织内所有团队的这些指标的信息。
此外，该系统还允许访问历史趋势，以识别每个级别上四个指标的改进或降低。团队还可以使用过滤器来查看特定时间段内的指标。
部署频率
为了跟踪该指标，我们从构建和部署系统中查找部署事件。在新版本的应用程序被部署到生产环境后，部署计数器会递增。这包括好和坏的应用程序版本。
变更准备时间
准备时间，指的是从变更创建时间到部署第一个服务实例过程中耗费的时间。
部署到生产环境中的单个功能修改，可能有多个提交，从而导致要计算多个交付周期。为了计算单个变更准备时间的总体指标，我们将这些准备时间的中值用作该部署的“变更准备时间”。
该组织，团队或应用程序的所有部署的“变更准备时间”的平均值，就是我们想要的“变更准备时间”。
变更失败率
应用程序在部署生产环境后，由于某些原因影响用户使用，我们需要修正（例如修补程序，回滚，正向修复或修补程序等），这些系统修补次数在所有部署中所占的百分比，就是变更失败率。
当前，我们将变更失败率衡量为给定时间段内所有部署中的回滚百分比。如果实例正在为流量提供服务，即使来自单个实例的回滚也算作失败。
平均恢复时间（MTTR）
平均恢复时间（MTTR）表示系统发生故障时，恢复正常所需的时间。
例如，如果将构建N（不良构建）部署到生产中，然后团队发现了一个问题，要求他们通过部署N-1（最新已知的良好构建）来回滚N，直到将N-1部署到生产环境为止的时间花费就是恢复时间（TTR）。所有TTR的平均值为MTTR。
总结
作为eBay内“ Velocity Initiative ”的一部分，eBay的各种平台和产品团队正在共同努力以实现一个共同目标：提高所有团队更快地交付高质量软件的能力。
同时，测量和可视化这些指标，有助于团队了解交付速度和稳定性方面的优势，还有助于确定整个团队在软件交付过程中需要改进的地方。
译文链接：https://thenewstack.io/4-ways-to-measure-your-software-delivery-performance/
