使用 DevOps 指标衡量 CI/CD 性能

刚开始构建 CI/CD 管道时，从编写自动化测试到使预生产环境自动刷新，有很多事情要做。 如果您想了解如何在此阶段改进流程，请查看我们的 CI/CD 最佳做法指南。

搭建好自动化管道后，就该探索如何使其更有效地工作了。 在 CI/CD 管道指标的帮助下，持续改进的循环就从这一阶段开始。

彼得·德鲁克曾经说过：“你无法管理你无法衡量的东西。” 指标对于持续改进至关重要。 数据有助于确定您可以在哪些方面增加价值，并提供基线来衡量您所做更改的影响。

通过监测重要的 DevOps 指标，您可以确定扩展自动化测试覆盖、改进吞吐量或分解开发任务是否会对 CI/CD 管道的性能产生最大影响。

每次优化 CI/CD 管道的某个阶段时，您都会放大该反馈循环的效果。 这种改进将提高您在保持质量和降低缺陷率的同时更频繁地发布更改的能力。

更频繁地发布意味着您可以持续改进关键功能，运行实验来验证假设，并及时解决任何问题。 随着市场的发展和功能需求的变化，您可以快速做出反应，赶上甚至领先竞争对手。

此外，监测 CI/CD 指标是向更广泛的业务（包括利益相关方和其他开发团队）展示管道价值的绝佳方式。

部署频率记录了您使用 CI/CD 管道部署到生产的次数。 DORA 选择部署频率作为批量大小的代理，因为高部署频率意味着每次部署的更改较少。

部署更少数量的更改可以降低发布相关风险，因为可能产生意外结果的变量更少。 更频繁地部署还可以为您的成果提供更及时的反馈。

低部署频率可能意味着管道不会获得定期提交，这可能是因为您没有将任务分解得足够细。 营造 DevOps 文化，让所有团队成员都了解 CI/CD 的好处，这可以帮助团队适应以较小的增量开展工作。

有时，作为持续交付策略的一部分，将更改批量处理到更大的版本中会导致部署频率较低。 如果您由于业务原因（例如用户期望）需要批量处理更改，可以考虑衡量部署到暂存站点的频率。

交期（也称为交付前时间或上市前时间）是从开始开发一项功能到将其发布给用户的时间。 不过，构思、用户研究和原型设计所涉及的时间可能差别很大。

为此，DORA 衡量的是从最后一次代码提交到部署的时间。 这个时间框架可让您专注于 CI/CD 管道范围内的各个阶段。

较长的交期意味着您不会经常在用户面前更改代码。 因此，您无法利用使用情况统计数据和其他反馈来完善您正在构建的内容。

在包含多个手动步骤的管道中，更长的交期较为常见。 这些阶段可能包括大量手动测试或需要手动刷新环境的部署流程。

投资自动化测试和 CI 服务器来协调构建、测试和部署任务将缩短交付软件所需的时间。 同时，您可以使用 CI 服务器来收集显示投资回报的指标。

假设您已经开始自动执行您的持续集成和部署流程，但步骤缓慢或不可靠。 在这种情况下，您可以使用构建持续时间指标来查明瓶颈。

如果您的组织要求在每次发布之前进行风险评估或由更改审查委员会批准，那么每次部署都会增加几天或几周的时间。 使用指标来证明流程的可靠性有助于建立利益相关方的信心，并消除对这些手动审批步骤的需求。

更改故障率是指部署到生产中导致中断或 bug 的更改（需要回滚或热修复）的比例。 它不包括在将代码更改部署到生产之前发现的问题。

此指标的优势在于将故障部署置于更改量的背景中。 低更改故障率表明早期阶段正在执行其工作并且可以在代码发布之前捕获大多数缺陷，让您的管道更加可靠。

如果您的更改故障率很高，就该检查您的自动化测试覆盖率了。 您的测试是否涵盖了最常见的用例？ 您的测试可靠吗？ 您能否通过自动化性能或安全测试来增强测试机制？

平均恢复或解决时间 (MTTR) 衡量的是解决生产故障所需的时间。 MTTR 认识到，在一个有许多变量的复杂系统中，生产中的故障不可避免。 重点不是追求完美（并放弃频繁发布的优势），而是您能否快速响应问题。

保持低 MTTR 既需要主动生产监测以在问题出现时获得提醒，也需要有能力通过管道快速回滚更改或部署热修复。

平均检测时间 (MTTD) 相关指标衡量的是部署更改与监测系统检测到该更改引入的问题之间的时间。 通过比较 MTTD 和构建持续时间，您可以确定某一领域是否会从一些投资中受益以缩短 MTTR。

CI/CD 管道中的自动化测试应该提供大部分测试覆盖率。 第一层自动化测试应该是单元测试，这项测试的运行速度最快并且提供最直接的反馈。

代码覆盖率是大多数 CI 服务器提供的指标，用于计算单元测试覆盖的代码比例。 监测此指标可以确保在编写更多代码时保持足够的测试覆盖率。 如果代码覆盖率开始呈下降趋势，那就应该在此第一线反馈中多投入一些精力。

构建持续时间或构建时间衡量的是完成自动化管道各个阶段所花费的时间。 分析流程每个阶段所花费的时间，有助于发现可能增加获取测试结果或部署到生产所需时间的痛点或瓶颈。

测试通过率是指给定构建成功通过的用例的百分比。 只要您有合理水平的自动化测试，指标就可以表明每个构建的质量。 您可以使用这些数据了解代码更改引入新 bug 的频率。

虽然用自动化测试捕获故障优于手动测试或在生产中发现问题，但如果一组特定的自动化测试经常发生故障，则可能有必要研究这些故障的根本原因。

修正测试的时间是指从构建报告故障测试到相同测试在后续构建中通过的时间。 此指标可以指示您对管道中所发现问题的响应速度。

低解决时间表明您正在有效使用管道。 发现问题时立即修正会更高效，因为您还记得这些更改。 通过快速修正问题，您还可以保证您和团队成员不会在不稳定的代码上构建更多功能。

故障部署会导致意外停机、需要回滚部署或需要紧急修正。 故障部署计数用于计算更改故障率。

监测故障占总部署次数的比例有助于根据 SLA 衡量您的表现。

但是，请记住，零（或极少）故障部署的目标可能并不现实，并且会让团队优先考虑确定性，而不是稳定交付优质产品。 由于更改是分批进行的，这种思维方式可能会导致更长的交期和更大规模的部署。 由于更大的部署包含更多变量，生产中出现故障的可能性更高，而且更难修正（因为需要处理更多更改）。

与故障部署指标不同，缺陷计数是指积压工作中归类为 bug 的未解决故障单的数量。 此 CI 指标可进一步分为测试、暂存和生产中发现的问题。

监测缺陷数量有助于及时获得提醒，如果缺陷数量呈总体上升趋势，表明 bug 可能已经失控。 但是请记住，将此指标作为目标可能会使您的团队更关注对故障单进行分类而不是修正故障单。

作为部署频率的结果，以构建或发布中所含故事点数衡量的部署规模可用于监测特定团队内的批量规模。

保持小规模的部署表明团队正在频繁提交更改，并最大程度获得收益。 但是，由于案例估计在开发团队之间没有可比性，因此不应使用此指标衡量总体部署规模。

这些 DevOps 指标可以让您更好地了解 CI/CD 管道在部署速度和软件质量方面的表现。

通过跟踪这些指标，您可以确定流程中最需要关注的领域。 做出更改后，还应持续监控相关指标，验证其是否达到预期效果。

不过，虽然指标可以作为实用的性能指标，但重要的是根据背景理解数字，并考虑特定指标可能激励哪些行为。

记住，重点不是数字本身，而是保持您的管道快速可靠，以继续为用户提供价值，进而支持您的组织的目标。