衡量和监控 CI/CD 性能
持续改进是 DevOps 理念的一大基石。
它延伸至软件开发的各个方面，涵盖从您构建的产品或服务到组织的文化和流程。
持续改进需要收集和分析有关构建内容或工作方式的反馈，以了解哪些方面表现良好，哪些方面有待改进。 应用这些见解后即可收集进一步反馈，了解所做更改是否产生了积极影响，然后继续根据需要调整。
CI/CD 管道在实现软件的持续改进方面发挥着核心作用。 缩短从开发到部署的时间后，您可以更频繁地向用户发布更改，进而从生产使用中获得反馈，了解下一步的优先级。 同样，采用自动化测试各个阶段提供的快速反馈可以更轻松地解决错误并保证软件质量。
但持续改进并不止于此。 将相同的技术应用于 CI/CD 管道本身，您可以改进构建、测试和发布软件的过程，放大用于改进产品的反馈循环。
了解管道指标
俗话说，“没有测量就无法管理”。
指标是提高系统性能的重要工具，可以帮助您确定在哪些方面增加价值，并提供基准衡量改进的影响。
CI/CD 中的性能包括速度和质量。在快速部署更改和交付稳定可靠的产品之间不应有所取舍——高性能 CI/CD 管道将让您同时实现这两种性能。
通过测量和监控活动速度、软件质量以及自动化程度，您可以确定需要改进的领域，然后确认更改是否产生了积极影响。
顶级性能 DevOps 指标
以下四个指标已被 DevOps Research and Assessment (DORA) 确定为高级指标，可准确指示组织在软件开发环境中的表现。
You can learn more about the research that informed these choices in the book Accelerate.
交期
虽然交期（也称为交付前时间或上市前时间）可以指定为从首次提出功能到向用户发布的时间，但构思、用户研究和原型设计所涉及的时间往往很容易发生变化。
出于这个原因，DORA 采取的方法是测量从代码提交到部署的时间，这使您可以只关注 CI/CD 管道范围内的阶段。
较长的交期意味着您不会经常在用户面前更改代码，无法通过反馈完善您正在构建的内容。 这可能是由多个因素导致的。
涉及手动步骤（例如大量手动测试、风险评估或更改审查委员会）的发布管道可能会使流程增加数天或数周，从而削弱频繁发布的优势。
虽然投资自动化测试将解决前者，但后者需要与利益相关者接触以了解如何更有效地满足相关需求。 另外，如果自动化步骤缓慢或不可靠，则可以使用构建持续时间指标确定花费最多时间的阶段。
部署频率
部署频率记录了您使用 CI/CD 管道部署到生产的次数。 DORA 选择部署频率作为批量大小的代理，因为高部署频率意味着每次部署的更改较少。
频繁部署少量更改可降低发布的相关风险（因为可能组合成意外结果的变量更少），并更快提供反馈。
部署频率低可能意味着管道没有定期提交，可能是因为任务没有被分解，也可能是将更改批处理到更大发布的结果。
出于业务原因（例如，由于用户期望）需要批量处理更改时，测量部署到暂存站点的频率将允许您监控批量大小并评估您是否获得小增量作业的效益。
更改故障率
更改故障率是指部署到生产中导致故障的更改的比例，例如需要回滚或热修正的中断或错误。 该指标的优势在于将故障的部署置于更改量的背景中。
低更改故障率表明管道的早期阶段正在执行其工作并可在代码部署到生产之前捕获大多数缺陷，让您的管道更加可靠。
平均恢复时间
平均恢复或解决时间 (MTTR) 衡量的是解决生产故障所需的时间。 MTTR 认识到，在一个有许多变量的复杂系统中，生产中的故障是不可避免的。 与其追求完美（因此减慢发布速度并放弃频繁发布的优势），不如快速响应问题。
保持低 MTTR 既需要对生产中的系统进行主动监控以在问题出现时获得提醒，也需要有能力通过管道快速回滚更改或部署修正。
平均检测时间 (MTTD) 相关指标测量的是部署更改与监控系统检测到该更改引入的问题之间的时间。 通过比较 MTTD 和构建持续时间，您可以确定某一领域是否会从一些投资中受益以减少您的 MTTR。
CI 和运营指标
除了这些高级测量之外，您还可以使用一系列运营指标进一步了解管道的执行情况并确定可以改进流程的领域。
代码覆盖率
在 CI/CD 管道中，自动化测试应该提供大部分测试覆盖率，让 QA 工程师能够腾出时间专注于探索性测试和定义新的测试用例。 第一层自动化测试应该是单元测试，因为单元测试的运行速度最快并且提供最直接的反馈。
代码覆盖率是大多数 CI 服务器提供的指标，用于计算单元测试覆盖的代码比例。 监控此指标可以确保在编写更多代码时保持足够的测试覆盖率。 如果代码覆盖率随时间推移呈下降趋势，那就应该在此第一线反馈中多投入一些精力。
构建持续时间
构建持续时间或构建时间衡量的是完成自动化管道各个阶段所花费的时间。 观察流程中每个阶段所花费的时间，有助于找出可能会减慢获得测试反馈或部署到现场的总体时间的痛点或瓶颈。
测试通过率
测试通过率是指给定构建成功通过的测试用例的百分比。 只要您有合理水平的自动化测试，它就可以很好地表明每个构建的质量。 您可以使用此指标了解代码更改导致测试故障的频率。
虽然用自动化测试捕获故障优于手动测试或在生产中发现问题，但如果一组特定的自动化测试经常发生故障，则可能有必要研究这些故障的根本原因。
修正测试的时间
修正测试的时间是指从构建报告故障测试到相同测试在后续构建中通过的时间。 该指标可指示您对管道中所发现问题的响应速度。
低解决时间表明您正在使用管道达到最佳效果。在发现问题后立即处理，您可以更高效地工作（因为这些更改在您的脑海中仍然清晰），并避免在不稳定的代码之上构建更多功能。
失败部署
导致意外停机、需要回滚部署或需要紧急发布修正的失败部署。 失败部署计数用于计算更改故障率（如上所述）。
监测故障占总部署次数的比例有助于根据 SLA 衡量您的表现。
但是，请记住，零（或极少）部署故障的目标很可能并不现实，但会鼓励团队优先考虑确定性。 由于更改将被批量处理，这样做会导致更长的交期和更大的部署，从而实际上增加生产故障的可能性（因为有更多的变量），并使其更难修正（涉及更多更改）。
缺陷计数
与故障不同，缺陷计数是指积压工作中归类为错误的未解决故障单的数量。 它可以按照测试或暂存中发现的问题以及生产中发现的问题进一步细分。
与代码覆盖率一样，监控缺陷数量有助于提醒您表明错误正在失控的总体上升趋势。 但是请记住，将此指标作为目标可能会使您的团队更关注对故障单进行分类而不是修正故障单。
部署规模
作为部署频率的必然结果（见上文），以构建或发布中所含案例点数衡量的部署规模可用于监控特定团队内的批量规模。
保持小规模的部署表明团队正在频繁提交，并最大程度获得收益。 但是，由于案例估计在开发团队之间没有可比性，因此不应使用此指标衡量总体部署规模。
结论
监控这些指标可以让您更好地了解 CI/CD 管道的执行情况以及您处于上升趋势还是下降趋势。
您可以使用指标确定流程中值得进一步关注的领域。 做出更改后，还应继续监控相关指标，验证其是否达到预期效果。
然而，虽然指标可以提供实用的性能表现，但重要的是根据背景理解数字，并考虑关注特定指标可能会激励哪些行为。 记住，重点不是数字本身，而是保持您的管道快速可靠，以继续为用户提供价值。