谷歌发布：DevOps 投资回报白皮书

IT,价值驱动器和创新引擎

传统上，IT 一直被视为一个成本中心，因此，人们希望 IT 能预先证明其成本和投资回报率（ROI）是合理的。

其实，IT是一个价值驱动力和创新引擎。

那些未能充分利用 IT 的变革性及其创造价值能力的公司，很有可能会被利用者打乱。

然而，现在并没有一个能用于数据驱动的分析框架，用于预测 DevOps 转型的价值，并证明对其的投资是合理的。

这份白皮书有助于填补这一空白。虽然本方法并非详尽无遗，但它的确概述了其中所需要考虑的比较重要的因素。

使用 Accelerate:State of DevOps 报告中提到的关键指标，根据行业平均水平，本文将分别对四类 IT 组织（精英、高、中、低绩效者）实施 DevOps 实践所带来的价值进行预测。本文还将向你展示：

• 如何使用这些指标来计算您的生产力
• 通过提高你的能力和IT绩效，来估计你的转型计划的潜在投资回报率

本文所提供的信息特别适合技术领导者、高管和（或）财务伙伴，以帮助推动组织内的技术变革。

通过量化成本和可能的回报，使用你自身组织的数字和提供的行业基准，你应该能为投资 DevOps 进行技术改造来向上级领导提供强有力的商业投资分析。

本文还提供了在不断改进和进步的情况下，所能获得的可能收益。

如果你所在的组织是一个低、中或高绩效者，请注意精英绩效者所设定的基准，并意识到该行业每年都在改善。

如果不进步，就会落后。

如果你的组织属于精英绩效者，也可以看看如何与其他精英绩效者进行比较，并努力不断改进和提高标准。

请注意，本文中提到了中位基准，该行业每年都在不断改善，尤其是在精英绩效者中。

通过软件开发速度和稳定性来评估IT组织绩效。

• 精英绩效者：从卓越的软件交付中获得最大的好处，并以最高的水平交付软件。在所有团队中，他们每天经历的增值时间最多，花在非增值工作上的时间最少。

• 高绩效者：仍有改进空间，但在统计上优于中等绩效者。在吞吐量和稳定性的各个方面都非常出色，但必须在这些方面持续改进，才能从改进的 IT 绩效中获得最大的好处。通过减少技术债务来优化速度和价值，而不是降低成本。

• 中等绩效者：将获得最大收益。在稳定性方面表现良好，但在速度方面落后于高绩效者。

• 低IT绩效者：通过解决低挂果实和设定可衡量的目标，有最多的改进机会。

那些未能充分利用IT价值创造能力的公司，有可能被那些IT利用最大化者打乱阵脚。

IT 与组织绩效

由 DORA 合著的《DevOps状态报告》，根据对 DevOps 作用的重要程度，将对衡量软件开发和交付团队的方法分成两个维度，它们是：

• 开发敏捷性（或吞吐量）：通过衡量部署代码的频率和部署代码所需的时间来定义敏捷性
• 运维可靠性：通过衡量平均恢复服务时间（ MTTR ）和变更失败率（即代码或基础设施的更改需要回滚或热修复的频率）来获取稳定性。

选择这些度量项有几个关键原因。

1. 敏捷性度量能很好地体现开发人员的目标，并有助于强调快速向客户交付功能的重要性。
2. 可靠性度量能很好地体现IT运维人员的目标，有助于强调可靠代码的重要性，并需要一段时间的基础设施。

使用这两个维度做衡量的好处在于：它们彼此之间存在一定的张力，防止团队「玩弄」度量，并提供团队开发和交付软件总体能力的良好整体视图。

根据这些指标，IT组织被分为不同的组：精英、高、中、低绩效者。

（更详细的信息可以在 2019 年 DevOps State of DevOps 报告中找到，但基本信息在表1.a中概述）

精项绩效者在吞吐量和稳定性方面表现最好，在软件开发和交付方面都表现出卓越的性能，没有冲突，也无需权衡。也就是说，他们在工作中所应用的原则与实践，让他们能够同时提高吞吐量和稳定性。

关于IT绩效的一个重要注意事项是：同一个组织中的不同的团队，都有它自己的改进旅程。

所以，一个组织中的不同团队，可以并且的确会有不同的绩效表现。

通过确定自己团队的失败之处，你可以看到自己在不断改进的过程中，算做哪一类绩效者，并为未来设定目标。

在本文中所做的对 ROI 的计算过程中，需要一些数据。如果你所在团队或组织没有易拿得的相关数据，可以使用报告中提供的 IT 绩效者的数据，来获取行业基准中的数据点。例如，在报告的后面，我们在计算浪费时，会使用「不必要工作」的百分比。如果你自己没有现成的数据，就可以使用报告中提供的行业基准，并根据你自己团队当前技术绩效，选择最相近的行业基准。

当然，必须注意的是：这些数据有可能存在很大差异，团队可能与这些基准有很大差异。

因此，团队最好使用自身的数据。

根据调研报告所指出的，在统计学意义上，IT 精英绩效者在以下四项指标上都表现出色。

• 部署代码的频率最高
• 发布周期最快
• 在出现故障时，MTTR最短
• 在不到一小时的时间内，MTTR也最低。

高绩效者的表现比大多数组织好，他们正在进行快速部署代码，并快速修复错误，但是，必须持续改进，才能与精英同行的水平相匹配。

中绩效者所占比例最大，因为低绩效者在不断提高处已，而高绩效者正面临行业日益复杂的局面。中等绩效者在稳定性方面表现良好，但还需要在吞吐量方面持续提高。

在四项指标中，低绩效者在其中三项指标上表现较差。他们部署代码的频率最低，发布代码所需时间最长。他们的平均 MTTR 也最长。

所以，低绩效者能从 IT 改进中获得最多的经济收益。

投资回报率由哪些要素构成

当组织和技术领导者评估是否以持续改进为重点，实施技术改造计划时，他们通常会询问投资回报率。

本文所用的计算方式需要有两个维度的数字序列：

• 投资，即：将投入多少资金和资源（转换成美元金额）用于技术、流程、培训和文化改进

• 回报，即：投资能带回来多少资金和资源

虽然本文侧重于计算投资回报率，但请记住，在投资计算中还要包括技术收购以外的成本。重要的考虑因素包括因培训、学习和集成新技术或工作方式而导致的生产力损失、长期维护成本，以及重新设计和更换现有系统所花费的时间损失。在这些投资中，实际上包括哪些成本，则取决于团队和组织，以及他们在整个过程中所处的阶段。

在计算收益时，组织有两类成本和资源，他们应该总是要考虑的。第一是价值驱动方式；第二是成本驱动方式。

价值驱动方式

精英组织已经证明，应该优先考虑「价值驱动」的方法（或至少与成本降低工作同等重要），高度重视市场压力，并有能力快速可靠地应对这些压力，如客户需求、新技术的可用性和竞争对手的压力，而且不需要他们的技术团队表现出英雄主义。

有远见的技术领导者一定明白这一点，并正在显著优化速度而非成本，这是思维方式的重大转变（ DevOps 领导者 Courtney Kissler 引用了这一策略）。

价值损失可能包括机会成本，或您当前在非增值工作（如不必要的返工和手动测试）上花费的资源，但您可能在增值工作（如新功能或额外的自动测试）上花费的资源。

推迟新产品或功能带来的价值损失也是一个关键问题。但是，由于它难以估计，因此通常会被忽略。例如，组织因此而没有获得的收入和客户.但j ,如果该组织能更快地发布软件，它将获得这些收入和客户。这可以被认为是一种机会成本，或延迟成本：不及时发布特性所产生的成本。

能够更快地发现并向客户提供价值，这是精益 / 敏捷模式的一个关键优势，也是真正的竞争优势，每年和每个季度都保持着相关性。

此外，仅仅因为某件事很难估计，并不意味着它不应该做。计算投资回报率不需要很高的精度，稍后我们将展示如何计算这个数字的有用值。

2008年，美国在线（ AOL ）的生产时间越来越长，无法投入生产环境使用。

吉恩·金与埃里克·帕斯莫尔合作，他当时是美国在线全球工程高级副总裁。Gene 在谈到该项目时说，“ ops 团队花了几个月的时间才将 Linux 内核从 2.4 更新到 2.6 ，因为开发团队需要 2.6 内核提供的多线程支持。对于该公司来说，缺少多线程支持就像“代码冻结”一样让该公司疲惫不堪。”

换句话说，开发团队已经完成了新的软件功能，但在运维团队完成内核升级之前，客户无法使用它，或从中获得价值。Gene 和 Eric 意识到这不仅仅是一个开发或运营问题—，真正的问题是延迟向客户提供软件功能，这是个商业问题，它转化成了企业的实际损失。

通过改进软件开发和交付流程，Eric 和他的团队能够将部署时间从 6 小时缩短到 45 分钟，消除了流程中的瓶颈，使 AOL 能够更快地向客户交付功能和价值。

成本驱动方式

在成本驱动方式中，重点是通过实施 DevOps 实现成本节约和效率提升，例如，通过实施 DevOps 技术而节省出时间，通过自动化手动流程节省的时间和成本等。

成本节约（例如基于时间和效率的节约）很容易识别，并且通常是证明应该向 IT 投资 时所能用的唯一方式。

这些成本包括停机成本以及手动与自动化工作的成本。这些节约可以通过采用精益实践和持续改进工作，以实现效率提升来实现，例如，消除浪费和不必要的返工。精益思想是改进经济学和 ROI 论证的有力基础。

然而，仅考虑这些成本是不够的，这种方式很少计算系统性的长期收益。随着组织调整到新的成本和绩效基准，第一年实现的效率在第二年之后就“不再被计算”了。

更糟糕的是，只关注成本节约，会向技术人员发出了这样一个信号：他们可能会失去工作，而不是从繁重的工作中解放出来，以更好地推动业务增长，这对士气和生产力产生了额外的负面影响。

使用价值和成本计算回报

让我们看看 ROI 计算是如何在价值和节约方面分解的，记住企业避免的所有成本都被视为对企业的回报。我们在这些计算中使用了保守估计。根据你的具体情况，你的数字可能会更高或更低。我们提供了完整的计算方法，因此您可以使用自己的数字计算回报。我们还提供行业基准和评估，以帮助您填写手头可能没有的任何数字。

关键思想：企业避免的成本被视为回报，因为成本和收入的任何变化都会与作为基线的起始预算进行比较

作为比较。

例如，如果基线预算占当年IT支出的1亿美元，但通过技术改进计划，支出减少到8000万美元，那么现在有一个“额外”2000万美元可用，这是以前没有计划的。因此，这额外的2000万美元是对该业务的回报。

价值计算

最优秀、最具创新精神的公司在进行技术改造时，除了能够实现成本节约和效率外，还考虑到他们能够为客户和业务带来的价值。然而，许多公司只关注成本节约，因为这个概念通常被很好地理解，并且通常被用来证明技术投资的合理性。

虽然关注成本节约是一个良好的第一步，但仅仅关注成本节约本身是不够的。成本节约可以在早期产生良好的影响，但在未来几年会带来递减的回报。

此外，将成本节约本身视为有价值的做法是短视的。利用技术赢得市场的先锋公司注重价值：他们将从这些节省中获得的回报再投资，以发现新客户，并增加向现有客户提供的价值。通过利用卓越的软件开发和交付能力，他们能够不断交付有价值的新产品和功能，让客户、者和投资者感到高兴。

通过建立一种猖獗的创新文化，我们在税收旺季的三个月里进行了165次实验。我们的生意结果如何？[在我们的客户获取渠道中]转化率上升了50%。者结果如何？每个人都喜欢它，因为他们的新想法可以推向市场

-- Scott Cook, Founder Intuit6

我们在计算回报时包括两种类型的价值。首先是从降低工作效率中获得的价值。这来自持续改进计划，团队可以减少浪费并提高效率。许多组织将这类改进工作归类为成本节约，但我们认为这是一种价值计算。我们计算回报时包含的第二类价值是从新开发工作中获得的价值，这有助于增加收入。下面将详细讨论这些问题。

每年避免不必要的返工所获得的价值

每年在不必要的返工上花费和损失的时间和金钱对生产率和技术经济都是一个重大打击。然而，许多组织忽视了这一成本。所有避免的成本都代表着企业的回报，可以产生巨大的价值。因为不必要的返工意味着可以通过改进流程来避免的工作，所以一些组织仅将效率的提高计算为成本节约。然而，我们指出，这些成本节约只有在完全避免成本的情况下才能实现；也就是说，劳动力的减少相当于累计节省的时间。然而，我们强烈建议组织不要采用这种策略，因为它会对士气和组织文化产生负面影响，会降低效率，甚至会激励者不改进工作流程。由于技术部门的招聘和保留目前是一个严重的挑战，公司可以取而代之的是收回这一时间，并将其重新投资于业务，基本上获得「免费」者的数量。保留和培训现有人才更具成本效益，保留了组织知识，并通过拥有一支参与并持续学习的强大技术者队伍，为组织带来优势。通过留住者并利用通过降低效率而恢复的时间，组织可以通过额外的人力工时获得价值。因此，我们将其归类为从避免的不必要返工中获得的价值，并每年累积。虽然每个组织甚至每个团队为改进流程和提高效率而采取的具体步骤各不相同，但使用精益思想和持续改进可以使团队减少浪费并实现效率。

“[一开始]，我们降低了价格，降低了价格，所以它们现在基本上是商品。[现在…]为了在业务上取得成功，我们必须朝着为我们与客户的关系增加其他价值的方向前进。

---Charles Schwab

关键思想：认识到通过降低效率而恢复的劳动时间的价值。

企业本质上是在不需要招聘和雇佣的情况下获得额外的能力——只需改进流程。我们的研究还表明，改进DevOps实践可以提高者满意度，高绩效团队中的者推荐他们的组织为理想工作场所的可能性高出2.2倍。这是一个巨大的胜利，当前对技术人才的竞争非常激烈，离职成本远远超过留住人才的成本。

Retaining existing talent
留住现有人才更具成本效益，保留了组织知识，并通过拥有一支强大的技术者队伍并不断学习，为组织带来优势。

美国进步中心（Center for American Progress）的一项研究发现，者离职的典型成本是者年薪的21%。

https://www.americanprogress.org/wp-content/uploads/2012/11/CostofTurnover.pdf

计算每年避免的不必要返工所获得的价值，我们使用以下等式：

Technical Staff Size

组织应该包括他们拥有的技术者总数，因为不必要的返工会影响价值链上的每个人，从开发、QA和测试，一直到运营。为了便于说明，我们将以下小组用于不同规模的组织：

• 对于主要业务依赖内部软件（如金融服务）的大型组织，我们估计有8500名技术者。
• 对于中大型技术组织，我们估计有2000名技术者。
• 对于中小型企业和非技术企业，我们估计有250名技术者。

当然，在计算贵公司不必要的返工成本时，您应该使用贵公司参与软件开发和交付的技术人员数量。

Average Salary

根据 Glassdoor 公司 2019 年的一份报告，DevOps 专业人士的总体工资中值为 143000 美元。对于较大的团队，这个数字会增加，并根据地理位置和生活成本而变化，但我们在计算中使用这个数字。为自己的目的进行计算时，请使用适合组织中技术人员的典型薪资。

福利系数

保险、假期和退休等者福利费用超出了基本工资。虽然我们看到福利乘数在工资成本的30%到 110% 之间（导致福利系数为 1.3 到 2.1 ），但我们使用保守的 1.5 倍系数进行计算。

Percentage of Time Spent on Unnecessary Rework

出于我们的目的，我们参考了2018年DevOps州调查受访者报告的平均花费在不必要返工上的时间百分比。这个数字代表了花费在非增值工作上的时间量——实际上是由于效率低下而浪费的劳动时间。当然，并非所有不必要的返工都可以消除，但团队应该设定目标，不断改进不必要的返工。基于两个来源，我们建议目标为18%。首先，研究报告称，19%到40%的代码在最终版本10之前进行了返工。其次，我们自己在2018年《加速：DevOps州报告》中的研究发现，优秀者报告了19%的不必要返工。因此，18%不必要的返工似乎是一个目标，符合所研究的最佳性能。

• 对于 IT 精英，报告的不必要返工量为19%。虽然精英绩效者展示了行业的黄金标准，但总有改进的空间。因此，我们使用1%作为他们计划外工作的目标；报告的返工量与18%返工目标之间的差异。他们在每一个指标上都表现最好，但由于代码中的中断、错误和对错误的反应，他们仍然有反应性的计划外工作。然而，在所有团队中，精英绩效者从他们的工作中获得最多的增值时间，而花在非增值工作上的时间最少。

• 对于高 IT 绩效者，报告的不必要返工量为 19.5 % 。因为我们相信，高绩效者在工作中仍有改进的余地，并且应该继续争取精英地位，所以我们在计算中使用了报告的返工和目标之间的1.5%差异。然而，从事更静态项目（如成熟项目维护）的团队可能会为不必要的返工设定更积极的目标。虽然总会有一些计划外的工作要做，但及早发现错误并建立快速反馈循环有助于将高绩效者的这一点降至最低。这里有什么好消息？通过及早发现错误，这一群体在新工作上花费的时间也比中、低绩效者多10%，他们在新工作上花费的时间约为50%。

• 对于中等 IT 绩效者，行业报告的计划外返工量为 20% 。减去18%的目标，我们的计算得到2%。中等水平的绩效者可能不像精英或高水平的绩效者那样拥有自动测试和其他机制，以便尽早发现许多缺陷，因此他们会在不必要的返工上花费更多时间。这可能会影响到中间绩效者为清理技术债务而必须执行的耗时工作。请注意，中等性能的用户仍在更频繁地部署代码，并快速地将代码推送到管道中，而且比低性能的用户更可靠。

• 对于低 IT 绩效者，行业报告的不必要返工量为 20% 。减去18%的目标，我们可以在计算中使用2%。在所有这些对不必要返工的估计中，表现不佳的人最有可能有不成熟和不可靠的测量实践，因此他们不太清楚自己在不必要返工上花费了多少时间。因此，我们认为这一估计可能很低，因为低绩效者根本不知道他们在浪费多少时间。根据报告的数字，低绩效者将大部分时间花在不必要和计划外的工作上，只有约30%的时间花在新工作上。在所有其他群体中最低。低绩效者被手头的工作量压得喘不过气来，他们可能不想跟上计划外的、反动的工作——他们会无视这些工作，不惜一切代价发布新代码。当企业为了在市场中获得战略地位而优先考虑新特性和功能时，通常会出现这种情况，但这种战略是不可持续的。虽然做新工作和提供新功能是好事，但从长远来看，忽视缺陷和不必要的返工是一种失败的策略——技术债务累积起来，增加了维护现有系统的成本，降低了新功能的交付速度。从低水平到精英水平的过程需要努力工作，以弥补过去积累的技术债务，并达到一个你能够尽早且经常发现缺陷的程度。

2019年加速-DevOps告发现：IT精英几乎翻了三倍，从7%增长到20%，表明卓越是可能的——它只需要执行。与精英同行类似的高IT绩效者每年都在增长，并报告了优异的可用性，这与软件交付性能显著相关。中等IT人才在稳定方面做得不错，与高绩效者相当，但在递送速度方面落后。在统计显著性水平上，低IT绩效者在所有四项指标中都处于劣势。他们部署代码的频率最低，发布代码的时间最长。平均而言，他们报告的MTTR最长，但报告的变更失败率低于中等绩效者。

使用上面的公式和输入值，可以对每年不必要的返工成本进行以下估算：

While the Low Performers see lower yearly costs of unnecessary rework

虽然表现不佳的者每年不必要的返工成本较低，但这很可能是以让技术债务累积为代价的。如果真是这样，这种策略将在未来产生问题。此外，与高绩效者和精英绩效者相比，中低绩效者在其软件开发和交付环境中具有更大的不可预测性，这造成了不确定性。管理这种不确定性会带来他们无法预见的更大的开销和不必要的下游返工。进行技术改造，着眼于不断提高产品质量，从而减少不必要的返工及其相关成本。这是一个减少浪费的战略，也是持续交付技术实践的一个关键目标。请注意，这些成本如果得以避免，将为企业带来可观的回报。在我们的计算中，这些成本的降低将被归类为回报，如表2所示。组织可以选择通过裁员来实现这些成本，但是采用这种策略会对士气产生负面影响，并且收益不能用于创造价值；事实上，对你的产品和技术环境做出贡献和创新的最佳人选往往是那些已经是it专家的人。

通过在多个计划（如测试、基础设施、工作流和法规遵从性）中使用通过自动化工作恢复的时间百分比，可以对其他改进计划（如自动化）进行类似的业务价值计算。在我们的分析中，我们不包括这些计算，因为还没有通过自动化改进措施获得的储蓄和价值的良好估计，但是你应该考虑在你自己的计算中包括这些。

新功能再投资的潜在附加值

Potential Value Added from Reinvestment in New Features

虽然更难预测，但在计算技术投资的储蓄和效率回报时，损失的收入也同样重要。这些失去的机会成本，如果避免，有可能继续增加价值，你的产品和你的投资组合逐年，弹射你超过你的竞争对手。最好的组织理解这一点，并将技术改造的价值纳入其ROI计算中。然而，由于这个概念很难估计和传达，我们提供了一个框架来帮助您量化它。我们将通过向客户提供功能实现的持续价值作为我们的代理。通过提供客户价值，我们希望创造条件来产生收入或创造我们想要的商业价值。虽然向客户提供新功能会带来收入，但并非所有功能都是赢家：在成熟产品中，只有约三分之一的精心设计、精心研究的功能为企业带来了顶级价值。新产品和商业模式的统计数据要差得多11。因此，我们看到亚马逊等高绩效公司利用其频繁部署的能力在生产中运行实验。他们这样做是为了避免构建和维护没有价值的功能。在我们的计算中，我们将新功能的收入潜力建立在当前业务收入的基础上。这一收入潜力代表了企业从技术转型中获得的潜在回报。

关键理念：利用从降低效率中恢复的时间，通过为客户提供新功能来创造收入，从而将其转化为价值。

我们使用以下等式计算再投资的潜在附加值：

恢复时间并重新投资于新功能

Time Recovered and Reinvested in New Features

这是从减少不必要的返工和重新投资于新功能中恢复的时间百分比。i实验频率（见下文）假设团队的所有时间都花在开发和交付新功能上。虽然这对于一个新的专门团队来说是可能的，但该分析将侧重于通过技术改造计划可能获得的收益，因此只有通过改进恢复的部分时间。这是一个估计，每个团队的结果可能因其组织和技术成熟度而异。我们使用与上述相同的方法来估计通过提高效率可以恢复的时间量，并使用我们规定的18%返工的目标。只有当通过减少不必要的返工而实现的效率被重新投资到业务中时，这些特定的价值收益才可能实现。也就是说，允许您的技术专业人员利用他们新发现的空闲时间，并将其用于致力于有可能为业务创造收入的功能的工作。例如，如果恢复的时间花在记录流程或自动化测试等工作上，组织仍然可以从恢复的额外工时中获益（如上所述），但它没有实现收入的潜力。

对于这个数字，我们还参考了2018年加速：DevOps行业基准数据。

精英绩效者能够将他们的努力重新导向增值工作1%。（该组报告称，他们19%的时间花在了不必要的返工上；目标是18%，差异是技术人员1%的时间将花在增值工作上。）

高绩效者能够减少不必要的返工，从而将他们的工作转向增值工作，减少1.5%。（最初报告为19.5%，该群体可以通过将技术人员的工作转向增值工作，实现18%的时间用于不必要的返工的建议目标，从而使增值工作增加1.5%。）

中等水平的者能够将他们的工作转向增值2%。（该组报告称，他们20%的时间花在了不必要的返工上；目标是18%，差异是技术人员现在可以花在增值工作上的时间的2%。）

低绩效者能够将他们的努力转向增值工作2%。（这组人报告说，他们20%的时间花在了不必要的返工上；通过将不必要的返工减少到18%，他们将2%的时间用于增值活动。）

Frequency of Experiments

组织能够通过A/B测试或其他类型的用户研究（定量和定性）在客户身上测试功能，这对寻求客观测试的组织来说是一个巨大的好处。然而，如果团队不能定期部署代码，那么来自客户的反馈对于软件产品来说就困难得多。也就是说，部署频率限制了他们与客户一起试验和测试功能的能力。保守地说，我们建议每个业务线每周进行一次实验，因为这是该计算的组织中的实验轨迹。我们参考DevOps行业基准数据的状态，以验证每个组是否可行：

精英绩效者能够按需部署代码，每天多次部署。因此，每天两次（或每年730次）的实验频率是可以实现的。我们将使用这个数字进行计算。

高性能人员能够在每天和每周之间部署一次代码。对于这一组，我们使用这些持续时间的上限，或每周一次，用于计算。

中等绩效者每周部署一次，每月部署一次。对于这一组，我们使用这两个持续时间的高端进行实验，或者每个月一次，用于我们的计算。

低绩效者每月部署一次，每六个月部署一次。对于这一组，我们使用这两个持续时间的高端进行实验，或者每六个月进行一次计算。

Lines of Business in the Organization

组织在战略业务部门或业务线中创建和部署软件。每一条业务线都有一个核心软件产品或服务，可以为客户提供服务。这个核心软件产品或服务是组织中实验的中心。

大型技术组织拥有更多的产品（支持业务线），因此可以进行更多的实验。根据行业和公司结构，每个组织拥有多少业务线存在很大的差异。虽然您应该插入自己的数字，但出于说明目的，我们对不同规模的组织使用以下数字：

对于主要业务依赖于主要由内部创建的软件（如金融服务）的大型组织，估计有8500名技术者，我们假设有20个业务线。

对于估计有2000名技术者的中大型技术组织，我们假设有8条业务线。

对于中小型企业和非技术企业，估计有250名技术者，我们假设有一条业务线。

Idea Success Rate

虽然花在创新和增值工作上的时间对组织来说通常是一种胜利，而且肯定比不必要的返工花费的时间更好，但并不是每件工作都能产生收入。大量实验表明，精心设计的功能中只有三分之一能够改善关键指标，因此我们在计算中使用了这一点。请注意，这一指标适用于拥有强大的现有新产品用户群的产品，构建能够为业务带来价值的产品的可能性可能要低得多。因为这个估计对你的环境可能是乐观的，所以使用准确代表你的环境的比率。

Product Portfolio Business Size

对于许多组织来说，新功能的收入潜力取决于当前产品或业务的当前收入。我们对收入为1亿美元的产品组合进行这些计算。

Idea Impact

每个想法或特征都有可能为我们的底线做出贡献。在我们的计算中，我们假设每一个成功的想法或功能对收入的贡献平均为1%，这是基于与从事已建立的web软件属性的行业专家的对话，这些软件属性正在经历增量功能改进，而不是重大变化。你会希望你的想法转化率建立在你自己的产品上。

基于上述公式和输入，我们通过恢复不必要的返工损失的时间并将其重新投资于增值活动，总结了业务的潜在增值（见表3）。这也可以被认为是由于没有改进工作而失去了价值

Cost Savings Calculations

节约计算从节省时间和精力开始。从业务的角度来看，任何计划的成本或随后避免的日常开支都代表着对组织的回报。也就是说，尽管这不是新的资金进入该业务，但它属于此类。我们将在整个报告中强调这一点。

Any costs that are planned or expenses that are then avoided represent
returns to an organization.

计划的任何成本或随后避免的费用都代表着对组织的回报。

Cost of Downtime Per Year

应用程序和基础设施宕机带来了巨大的成本，史蒂文·埃利奥特（Steven Elliot）和IDC团队最近的一份报告显示，对于财富1000强的公司来说，每小时的宕机成本可能在12.5亿美元到25亿美元之间。停机成本因业务性质的不同而变化很大，高交易量的金融交易业务的停机成本要比简单地维护网络状态以通知客户其运营时间的小型实体业务的停机成本高得多。此外，从中断中恢复的能力取决于体系结构。虽然我们以这些计算为例，但我们强烈建议您在计算这些成本时考虑自己的综合成本和IT架构。停机时间数字突显了团队快速恢复服务并（尽可能）通过设计弹性系统从一开始就避免故障的能力的重要性。停机成本的消除或减少代表着业务的回报。本节确定了精英、高、中、低IT绩效者每年可以避免的停机时间。

关键思想：找到一种估算停机成本的方法，因为当这些成本得以避免时，它们可以为企业节省成本。

为了计算每年的停机成本，我们使用以下等式：

Deployment Frequency

团队部署的频率将影响其有机会引入可能导致事故的变更的频率。但是，请记住，不频繁的部署会导致将更大、更复杂的代码包发布到生产环境中，这使得集成和支持新代码变得更具挑战性，并且识别任何故障变得越来越困难。我们参考我们的2019 Accelerate:State of DevOps行业基准来了解这些统计数据：

• 精英绩效者能够按需部署或每天多次部署。对于此计算，我们将其编码为每天部署2次，或每年部署730次。虽然每天部署两次似乎很高，但Etsy报告每天部署80多次，Netflix和Amazon每天部署数千次，这使得我们的估计相当保守。

• 高绩效者可以每天部署一次，每周部署一次。在这个计算中，我们使用这两次部署的平均值，即每年209次部署。

• 中等绩效者每周部署一次，每月部署一次。在此计算中，我们使用这两次部署的平均值，即每年部署32次。

• 低绩效者每月部署一次，每六个月部署一次。在这个计算中，我们再次使用了每年两次或7次部署的平均值。

把你的代码库和基础设施想象成一座Jenga塔。频繁的发布就像在塔上添加一个Jenga部件。它易于支持，并且很容易识别是哪一个添加导致了停机（如果有）。我们还可以继续加强和支持基础设施，看看小规模的扩建会对塔楼产生怎样的影响。不经常发布的版本就像在Jenga tower的顶部添加一个由数百个Jenga部件组成的巨大球体，粘在一起。这座塔很可能会因为一个大的增加而倒塌，现在你必须弄清楚是哪一块或哪几块Jenga增加物导致了停电。

Change Fail Rate

引入生产的每一项变更都有可能导致故障、事故或服务降级。这些服务中断必须由团队解决，并有可能导致更大的停机。对于这些统计数据，我们参考了「2019 年 DevOps 加速报告」的行业基准状态，但如果它们可用，建议您使用自己的基准：

• 精英绩效者报告 0% 到 15% 的变化会导致服务降级或需要补救。在我们的计算中，我们将使用这两个数字的平均值：7.5 %。
• 高绩效者报告0%到15%的更改会导致服务降级或需要补救。在我们的计算中，我们将使用这两个数字的平均值：7.5 %。
• 中等绩效者报告0%到15%的更改会导致服务降级或需要补救。在我们的计算中，我们将使用这两个数字的平均值：7.5 %。
• 低绩效者报告 46 % 到 60 % 的更改会导致服务降级或需要补救。在我们的计算中，我们将使用这两个数字的平均值：53 %。

平均恢复时间 Mean Time to Restore (MTTR)

我们处理复杂的系统，一些故障和停机是不可避免的。关键是快速恢复系统的能力。我们再次参考「2019 年 DevOps 加速报告」： DevOps 行业基准状态以获取这些统计数据：精英绩效者报告，当发生停机时，他们能够在不到一小时内恢复服务。

• 由于精英绩效者对停机非常敏感，并优先考虑系统正常运行时间，我们将使用此范围的中位数进行计算：0.5 小时。
• 高绩效者报告能够在不到一天的时间内恢复服务。在计算中，我们将使用该范围的中位数：4 小时。
• 中等水平的绩效者报告说，当发生停机时，他们能够在不到一天的时间内恢复服务。在我们的计算中，我们将使用这个范围的上限：8 小时。
• 低绩效者报告说，在发生停机时，他们能够在一周到一个月之间恢复服务。在我们的计算中，我们将使用一个月或15天（相当于 120 小时）的中位数.

停机成本

停机对组织来说代价高昂。然而，停机的成本是高度可变的，尤其取决于停机的“爆炸半径”（它是占用了整个基础设施还是只占用了一个非关键任务应用程序？）以及服务降级的程度（整个系统是否不可用，或者我们是否看到特定类型请求的响应时间出现长尾？）。您需要收集自己的数据，以完善这些计算。斯蒂芬·埃利奥特（Stephen Elliot）和IDC团队最近的一份报告将基础设施故障的平均每小时成本定为10万美元，关键应用程序故障的平均每小时成本定为 50 万美元至 1.14 万美元，但精确度较低。由于 DevOps 参与开发和交付核心应用程序功能，我们将使用为关键应用程序故障提供的数字。我们也将保持保守，在估算中使用 50 万美元。然而，应注意的是，一些企业，如零售商和金融机构，报告的停机成本为每分钟数百万美元，因此这些成本不应被忽视。我们建议您使用自己的平均每小时停机成本（如果有）。

使用上述公式和数字，我们计算出每年的停机成本为：

根据我们的模型，很明显，低绩效者每年和每次部署的停机成本最高。与中绩效者相比，高绩效者每年的停机成本更高，这可能是因为高绩效者部署的停机时间几乎是中绩效者的六倍，以及他们为修复这些更改而产生的后续成本。尽管如此，该模型显示，高绩效者的每次部署支出低于中等绩效者。事实上，这些数字应该更低，因为精英和高绩效人员通常会构建系统，从而使停机本地化，而不是系统化，并将导致服务降级，而不是完全关闭系统。这些重要的体系结构特征大大减少了业务影响和停机成本。降低停机成本的解决方案不是降低部署频率，而是降低更改故障率、降低MTTR、在系统中建立恢复能力，并控制故障，以便系统正常降级，而不是导致级联的全局停机。不频繁部署的隐性成本包括缺乏客户反馈，这是一个让最好的公司在试验、调整和继续赢得市场的过程中获得优势的因素。请注意，所有节省下来的停机时间成本代表着业务的回报；在未来的计算中，我们将它们归类为此类。

Adding it All Together

既然我们已经确定了技术改造和改进工作的主要成本和价值组成部分，我们将把它们结合起来，以发现DevOps等技术改造的潜在回报。记住，所有节省下来的成本都代表着企业的回报。

每年的回报比大多数人估计的要大得多，这说明，如果在进行技术投资时考虑到真正的变革和持续改进，可以带来有价值的结果。

现在考虑额外的增益，我们还没有包括在上面的计算中。一个例子是，组织可以通过将资源再投资于其他地方来实现价值：例如，通过减少不必要的返工来节省时间，并将这些时间再投资于新项目，为公司创造价值。在这个例子中，计算可以被想象为一项直接投资，几乎就像“免费工作”或额外的者数量。或者，可以将其作为资本投资进行分析，在传统的再投资计算中使用多余的资源作为输入，通过门槛率和内部收益率进行评估。在我们与前瞻性思维公司的讨论中，他们例行地进行这个练习，计划利用它们，而我们不在这些练习中包含这些计算，我们鼓励你们在自己的思维中考虑它们。最后，不应忽视对者和组织文化的好处。考虑团队的士气提高，减少返工时间和更多的增值时间。研究表明，敬业、快乐的者对IT和组织绩效有贡献，并与公司发展相关。此外，它有助于团队吸引和留住更多优秀人才，创造良性循环。

敬业、快乐的者为IT和组织绩效做出贡献，并与公司增长相关。

Engaged, happy employees contribute to IT and organizational performance and correlates to company growth.

Demonstrating Return on Investment

有了技术改造回报的货币表示，您几乎可以证明您的投资回报了。你还需要计算这一转型的投资成本。虽然本白皮书不会详细介绍这些成本，但请记住包括以下成本：

• 技术，包括收购、许可证等。
• 培训，包括技术人员在培训期间损失的生产力成本（包括效益乘数）。
• 学习新技术和流程时的停机时间（包括工资和福利成本）
• 咨询服务
• 其他相关费用，如重构或重新架构

Sample Calculation

我们将利用680万美元（包括所有收购、培训和人员成本）的投资价值，对一家大型技术组织的技术改造，以及价值1亿美元的产品线，演示两种方法：投资回收期和投资回报。

举例来说，680万美元的投资细分如下：

这个计算使用的薪资数字比之前使用的要高，因为招聘和保留对组织来说是一个挑战，找到高级SRE和DevOps工程师可能需要支付额外费用。

这个数字似乎过高，但实际上可能还要高得多；技术变革严重依赖劳动力。21世纪初的研究表明，劳动力成本是技术成本的2倍。在最近的一个例子中，Forrester的云应用迁移成本模型还发现劳动力成本远远超过服务和基础设施成本。


Patterson: Patterson, D. (2002, Nov 3-8, 2002).
《一种估算停机成本的简单方法》。在宾夕法尼亚州费城举行的大型系统管理员会议（LISA'02）上发表的论文。
Forrester:

 https://www.forrester.com/report/Brief+The+Cost+Of+Migrating+An+Enterprise+Application+To+A+Public+Cloud+Platform/-/E-RES132801

Payback Period

谈论投资回报的一个最简单的方法是投资回收期。简单地说，这个方法是问一项投资需要多长时间才能从利润或储蓄中收回。

根据我们的计算，我们的投资需要多长时间来支付回报。方程式的输出以年为单位。利用精英类大型产品业务的潜在回报，我们正在考虑投资680万美元，每年将产生8060万美元的回报。如果我们假设每年的现金流相等，我们通过将投资除以收益来计算投资回收期：

投资回收期为0.085年，即约31天，这意味着这项投资将很快“自我回报”。在这个计算中，越快越好。从风险分析的角度来看，投资回收期被认为是有用的，因为它揭示了投资对公司构成风险的时间。它在科技等行业尤其重要，因为这些行业的投资可能很快就会过时。这种分析的好处是易于理解和沟通。读者应该注意，这种计算回收期的方法假设现金流相等；如果它们加速或不均匀，你的计算应该考虑到这一点。

回收期忽略了资金和再投资的时间价值，通常是“在餐巾纸的背面”完成的它通常是通过基于现金的计算完成的，但也可以用于所有投资和回报的估算，正如我们在这里展示的那样。

Return on Investment

投资回报率计算项目的盈利能力，并以投资的百分比报告回报。方程的输出是一个比率。这个比率对投资者和将其与其他投资进行比较的商界人士来说是有意义的。鉴于上述例子，我们正在考虑投资680万美元，每年将产生8060万美元的回报（四舍五入）。为了计算投资回报，我们从回报中减去投资，然后从投资中除以这个数字：

该投资的投资回报率为10.832。你可能会问：这是一个好的投资回报率吗？这取决于一个组织认为“好”是什么，以及它将其与什么进行比较。然而，我们可以说，该组织在其技术改造计划中投入的每一美元都能赚到约10.83美元。你还可以考虑与其他投资资产相比的投资回报率：公司以外的投资，如股票和债券，可以获得什么样的回报？虽然投资多元化的股票组合风险较小，但投资于投资回报率较高的公司是增加回报机会的好方法。也就是说，如果你可以通过投资自己的技术改造获得类似的回报（或者甚至更好的回报，这可能在上面的例子中），而这些内部投资也将帮助你赢得市场，你为什么不选择这种策略呢？

结论

技术改造是有回报的

正如我们所展示的，实施技术改造计划可以为任何组织带来可观的回报。当然，在进行任何成本估算时，都存在成本可能被高估或低估的风险，以及可能无法在预期时间内实现回报或市场条件可能发生变化的风险，从而导致客户偏好或利率的变化。尽管如此，成本和价值评估仍然是值得的，为团队成员和领导层提供了决策依据。对于每种类型的IT绩效者，都有值得学习的经验。

数据表明，通过持续减少技术债务，优化速度和价值而非成本，中等绩效者将获得最大收益。我们敦促中等业绩者继续开展这项工作，不要让他们在努力工作一段时间后，认为自己没有取得进展，转而回到过去的方式，满足于短期的改进，并再次积累技术债务。中等水平的绩效者必须继续在运营效率方面取得进展，实施持续交付的智能技术实践，如持续集成、自动化测试和版本控制，以实现吞吐量和稳定性方面的持续高性能。

低绩效者面临一个悖论。一方面，由于复杂的遗留系统和保守的文化，它们远远落后于竞争对手。然而，在这些组织中，只要存在抓住果实的政治意愿，通常会有大量低效的果实。与所有计划一样，为你的计划设定可衡量的业务目标，并与整个组织的利益相关者合作，尝试大胆的想法以实现结果，这一点至关重要。从那些有能力、渴望变革并在高层领导层得到支持的团队开始，寻找快速的胜利，即使影响有限，也能在几周而不是几个月内产生可衡量的结果。对于任何开始技术改造的团队来说，请记住，许多改进计划都遵循“J曲线”，所以要为早期的失望做好准备。J曲线是当一名新成员加入团队或新流程到位时，团队通常会经历的绩效冲击，并且在情况好转之前对绩效产生最初的负面影响。正如朱莉娅·韦斯特所指出的，变化的大小往往会影响负面影响的深度19。技术改造计划是一个巨大的变化，所以如果（现实地说，当）性能或生产力受到初步影响时，不要放弃。在我们的数据中可以看到这种模式，随着团队解决技术债务，从低绩效到精英绩效的路径会随着不必要返工率的提高而下降。当团队坚持它时，他们会得到卓越的软件开发和交付能力，以及最不必要的返工率，与其他研究报告的一致。

转型的 J-型曲线

For more information on what steps you can take and what technical practices you should implement to truly improve your IT and organizational performance, visit our website at https://cloud.google.com/devops.

References

1. Kim, G. (n.d.) The Amazing DevOps Transformation of The HP LaserJet Firmware Team (Gary Gruver). Retrieved from https://itrevolution.com/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/

2. DevOps Research and Assessment & Google Cloud. (n.d.).2019 Accelerate: State of DevOps Report (Rep.)

3. DevOps Research and Assessment & Google Cloud. (n.d.).2019 Accelerate: State of DevOps Report (Rep.)

4. DevOps Enterprise Summit 2014. (2014, October 29). DOES14 – Courtney Kissler – Nordstrom – Transforming to a Culture of Continuous Improvement Retrieved from https://www.youtube.com/watch?v=0ZAcsrZBSlo

5. Earnshaw, A. (2013, July 18). DevOps Solves Business Problems: Gene Kim’s Top Aha Moments. Retrieved from https://puppet.com/blog/devops-solves-business-problems-gene-kim%E2%80%99s-top-aha-moments

6. Divine, C. (2011, April 20). Leadership in an Agile Age: An Interview With Scott Cook. Retrieved from https://web.archive.org/web/20160205050418/ http://network.intuit.com/2011/04/20/leadership-in-the-agile-age/

7. Ippolito, B., & Murman, E. (2001, December). Improving the Software Upgrade Value Stream. In 43rd AIAA Aerospace Sciences Meeting and Exhibit (p. 1252).

8. Chron 200 / Interview with CEO of the Year Charles Schwab. (2007, April 9). Retrieved from http://www.sfgate.com/business/article/Chron-200-Interview-with-CEO-of-the-Year-2603664.phphttp://dspace.mit.edu/bitstream/handle/1721.1/83541/REP_0101_Ippo.pdf?sequence=1

9. Hainzinger, Brittany. “DevOps Salary Report for 2019 Is Here.” App Developer Magazine, 22 Jan. 2019, appdevelopermagazine.com devops-salary-report-for-2019-is-here/.

10. Morozoff, E. (2009, September 4). Using a Line of Code Metric to Understand Software Rework. Retrieved from http://ieeexplore.ieee.org/document/5232799/

11. Kohavi, R., Crook, T., Longbotham, R., Frasca, B., Henne, R., Ferres, J., Melamed, T. (2009). Online Experimentation at Microsoft. Retrieved from http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf

12. Kohavi, R., Crook, T., Longbotham, R., Frasca, B., Henne, R., Ferres, J., Melamed, T. (2009). Online Experimentation at Microsoft. Retrieved from http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf

13. Elliot, S. (2014). DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified. Retrieved from http://info.appdynamics.com/DC-Report-DevOps-and-the-Cost-of-Downtime.html

14. Shimel, A. (2015, February 11). The real cost of downtime. Retrieved from http://devops.com/2015/02/11/real-costdowntime/.

15. DevOps Research and Assessment, LLC. (n.d.). 2019 Accelerate: State of DevOps Report (Rep.)

16. Reichheld, F. F. (2003, December). The One Number You Need to Grow. Retrieved from https://hbr.org/2003/12/the-onenumber-you-need-to-grow

17. Patterson, D. (2002, Nov 3-8, 2002). A Simple Way to Estimate the Cost of Downtime. Paper presented at the Large Installation System Administrator’s Conference (LISA ‘02), Philadelphia, PA

18. Rymer, J. R., Bartoletti, D, Martorelli, B, Mines, C, Tajima, C. (2016, March 9). Brief: The Cost Of Migrating An Enterprise Application To A Public Cloud Platform. Retrieved from https://www.forrester.com/report/Brief The Cost Of Migrating An Enterprise Application To A Public Cloud Platform/-/E-RES132801

19. Wester, J. (2016, February 6). Why improvement initiatives fail. Retrieved from http://www.everydaykanban.com/2013/02/26/why-improvement-initiatives-fail/

原文作者： Nicole Forsgren, Jez Humble, Gene Kim, Brenna Washington, Nikhil Kaul, Dustin Smith

原文链接：ROI of DevOps Transformation: How to quantify the impact of your modernization initiatives

发表时间： February 07, 2022