DevOps 状态报告

DevOps 状态报告是一份年度报告，它使用对调查数据的统计分析来确定软件交付组织的有效实践。其主要作者是 Nicole Forsgren、Jez Humble 和 Gene Kim。

该报告基于对数万名专业软件开发人员的调查。调查包含旨在识别结构组件的问题——无法直接衡量的东西，例如组织文化。在本例中，结构代表软件交付组织的能力 [1]，例如实践（持续集成）和环境因素（团队文化）。对于每个结构，调查问题旨在间接识别它们，因此它们不会询问“您是否进行持续集成”（我们知道这会给出 非常不可靠的答案），而是询问 CI 的具体内容（例如“每个人每天都推送到共享主线吗？”）。然后，他们使用各种统计技术来测试这些问题是否实际上衡量了潜在的概念。进一步的分析可以测试关于这些结构如何相互关联的假设。

这项调查中最引人注目的结果之一是，团队如何聚集成四种软件交付性能标准（精英、高、中、低）。精英表现者每天部署多次，将开发人员完成的更改投入生产不到一个小时。相比之下，低效表现者需要几个月才能将更改部署到生产环境中。这种高吞吐量不会以系统稳定性为代价，因为精英团队的更改失败率低于 15%（而低效表现团队的更改失败率为 46-60%），并且可以在几分钟内从故障中恢复，而不是几周。

开始阅读更多相关内容的最佳位置是 2019 年 DevOps 状态报告，该报告可免费获得。为了更深入地了解结果和用于发现结果的技术，我 强烈推荐他们的书 加速。 [2]

2019 年报告中的四个关键指标

	精英	高	中	低
部署频率	按需（> 1/天）	1/小时到 1/天	1/周到 1/月	1-6 个月
交付周期	< 1 天	1 天到 1 周	1 周到 1 个月	1-6 个月
恢复时间	< 1 小时	< 1 天	< 1 天	1 周到 1 个月
更改失败率	0-15%	0-15%	0-15%	46-60%

该报告根据四个关键指标的相似性对受访组织进行了分类。

• 部署频率：团队将代码部署到生产环境的频率
• 交付周期：从代码提交到代码在生产环境中成功运行的时间
• 恢复时间：发生缺陷时恢复服务的所需时间
• 更改失败率：导致需要修复问题的更改所占的百分比