我的读者们，新年快乐，希望新的一年里大家继续支持，我会为大家奉上更多更好的文章与视频。
关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。
在我们结束 2022 年之际，我们在 DevOps.com 想要重点介绍当年最受欢迎的文章。以下是我们 2022 年最佳系列中的最新一期。
一家技术公司最有价值的资产是其人员和数据，尤其是有关组织本身的数据。通过了解随着时间的推移要跟踪哪些数据，工程领导者可以衡量他们的 DevOps 团队的运作效率，并使他们能够最大化他们的价值流，以向最终用户提供尽可能好的产品。
经过多年研究，Google 的 DevOps 研究与评估 (DORA) 团队确定了四个用于评估团队绩效的关键指标：
- 更改的准备时间
- 部署频率
- 平均恢复时间
- 更改失败率
DORA 指标现已成为衡量软件开发团队效率的标准，并且可以提供对增长领域的重要见解。这些指标对于希望实现现代化的组织和希望获得竞争优势的组织来说至关重要。下面，我们将深入研究每个指标并讨论它们可以揭示有关开发团队的哪些信息。
更改的准备时间
变更前置时间 (LTC) 是指提交和生产之间的时间。LTC 表示团队的敏捷程度——它不仅告诉您实施变更需要多长时间，还告诉您团队对不断变化的需求和用户需求的响应程度。DORA 团队在他们的 DevOps 2021 加速状态报告中确定了这些性能基准：
精英表演者：不到一 小时
高绩效者：一天到一周
中等表现者：一个月到六个月
低绩效者：超过 六个月
LTC 可以揭示不良 DevOps 实践的症状：如果团队需要数周或数月才能将代码发布到生产环境中，那么他们的流程效率低下。可以通过持续集成和持续交付 (CI/CD) 最大限度地减少 LTC。鼓励测试人员和开发人员紧密合作，让每个人都对软件有全面的了解。考虑构建自动化测试以节省更多时间并改进 CI/CD 管道。
因为在变更的启动和部署之间有多个阶段，所以定义流程的每个步骤并跟踪每个步骤花费的时间是明智的。检查周期时间以全面了解团队的运作方式，并进一步了解他们可以在哪些方面节省时间。
人们应该小心，不要为了追求更快的变化而让软件交付的质量受到影响。虽然较低的 LTC 可能表明一个团队是高效的，但如果他们不能支持他们正在实施的更改或者他们以不可持续的速度前进，他们就有可能牺牲用户体验。与其将团队的变更提前期与其他团队或组织的 LTC 进行比较，不如随着时间的推移评估这一指标，并将其视为增长（或停滞）的迹象。
部署频率
部署频率 (DF) 是您发布更改的频率；您的软件交付的一致性如何。在确定团队是否达到持续交付目标时，此指标很有用。根据 DORA 团队的说法，这些是部署频率的基准：
精英表演者：一天多次
高绩效者：每周一次到每月一次
中等绩效者：每月一次至每六个月一次
低绩效者：不到每六个月一次
增强 DF 的最佳方法是发布一堆小的更改，这有一些好处。如果部署频率很高，则可能会揭示开发过程中的瓶颈或表明项目过于复杂。交付通常意味着团队不断完善他们的服务，如果代码有问题，更容易找到并解决问题。
如果团队很大，这可能不是一个可行的选择。相反，可以考虑定期构建发布火车和运输。这种方法将允许团队更频繁地部署，而不会压倒您的团队成员。
平均恢复时间
平均恢复时间 (MTTR) 是您的团队在发生中断等中断时恢复服务所需的平均时间。该指标可以让您了解软件的稳定性，以及您的团队在面对挑战时的敏捷性。这些是 DevOps 状态报告中确定的基准：
精英表演者：不到一小时
高绩效者：不到一天
中等执行者：一天到一周
低绩效者：超过六个月
为了最大限度地减少服务质量下降对您的价值流的影响，应该尽可能减少停机时间。如果您的团队需要超过一天的时间来恢复服务，您应该考虑使用功能标志，以便您可以快速禁用更改而不会造成太多中断。如果是小批量发货，应该也更容易发现和解决问题。
尽管平均发现时间 (MTTD) 不同于平均恢复时间，但您的团队检测问题所花费的时间会影响您的 MTTR——您的团队发现问题的速度越快，服务恢复的速度就越快。
与更改的准备时间一样，您不希望以牺牲解决方案质量为代价实施突然的更改。与其部署快速修复程序，不如确保您交付的更改是持久且全面的。您应该随着时间的推移跟踪 MTTR，以了解您的团队是如何改进的，并以稳定、稳定的增长为目标。
更改失败率
变更失败率 (CFR) 是导致停机、服务降级或回滚的发布百分比，它可以告诉您团队实施变更的效率如何。如您所见，CFR 的性能基准之间没有太大区别：
精英表演者：0-15%
高、中、低绩效者：16-30%
变更失败率是一个特别有价值的指标，因为它可以防止团队被他们遇到的失败总数误导。没有实施很多变更的团队会遇到更少的失败，但这并不一定意味着他们部署的变更会更成功。那些遵循 CI/CD 实践的人可能会看到更多的失败，但如果 CFR 很低，这些团队将因其部署速度和总体成功率而具有优势。
该比率也可能对价值流产生重大影响：它可以表明有多少时间用于解决问题而不是开发新项目。因为高、中、低绩效者都在同一范围内，所以最好根据团队和特定业务设定目标，而不是与其他组织进行比较。
将它们与 DORA 指标放在一起
与任何数据一样，DORA 指标需要上下文，并且应该考虑所有这四个指标共同讲述的故事。更改的提前期和部署频率可以让您深入了解团队的速度以及他们对用户不断变化的需求做出响应的速度。另一方面，平均恢复时间和更改失败率表明服务的稳定性以及团队对服务中断或故障的响应程度。
通过比较所有四个关键指标，可以评估他们的组织在速度和稳定性之间取得平衡的程度。如果 LTC 在一周内进行每周部署，但变更失败率很高，那么团队可能会在准备好之前匆忙推出变更，或者他们可能无法支持他们正在部署的变更。另一方面，如果他们每月部署一次，并且他们的 MTTR 和 CFR 很高，那么团队可能花在纠正代码上的时间多于改进产品的时间。
由于 DORA 指标提供了团队绩效的高级视图，因此它们对于试图实现现代化的组织可能是有益的——DORA 指标可以帮助确定改进的地方和方式。随着时间的推移，团队可以衡量他们在哪里成长以及哪些领域停滞不前。
那些属于精英类别的人可以利用 DORA 指标来继续改进服务并获得超越竞争对手的优势。正如 DevOps 状况报告所揭示的那样，精英执行者群体正在迅速增长（从 2018 年的 7% 增加到 2021 年的 26%），因此 DORA 指标可以为这个群体提供有价值的见解。
但请记住，数据只会让你走到这一步。为了充分利用 DORA 指标，工程主管必须了解他们的组织和团队，并利用这些知识来指导他们的目标并确定如何有效地投资他们的资源。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。