有哪些方法可以评估DevOps的ROI？

DevOps很复杂，涉及文化和流程等许多不确定性方面。
有哪些方法可以衡量DevOps成功的举措？
您如何向企业证明他们所做的投资正在回报（或节省）真实美元？

好问题！我们大多数人都知道，出于各种原因，对DevOps实践进行投资是非常值得的。不过，我们通常不会仅靠对底线的影响来证明DevOps的合理性。

注意：这是一个自以为是的问题，我的回答也是自以为是的。

Tensibai明智地建议我们找到正确的指标，他以上市时间为例。这是一个很棒的全局方法。

作为一种替代方法，我在bean计数器上的经验是，他们不需要-或不一定要了解全局，他们只需要财政责任的证据即可。他们希望看到正确方向的趋势。

这只是一些财政上的胜利：

• 计算通过利用云中的自动扩展功能节省的服务器成本
• 对于产生收入的站点，推断每分钟的停机时间成本，然后显示MTTI和MTTR有所改善
• 再次，对于产生收入的站点，根据过去的事件，通过利用高度可用的架构来估算每分钟节省的成本
• 如果您在构建和部署管道方面有所改进，请表明您已减少了由于已跟踪的故障而导致的回归和生产错误
• 如果您已经改进了开发人员测试环境，甚至改进了开发人员笔记本电脑上的工具和配置，请查看提交历史记录，以查看新工程师是否在加入后尽快做出了自己的第一贡献。
• 像Gitlab最近所做的那样，在云和本地之间进行全面的成本比较，以证明您的基础架构支出合理（又称节省！）。

证明自己有金钱意识，并且赢得了一些明显的胜利通常就足够了。我当然错过了一些明显的例子。随时在下面添加评论。

DevOps管道的关键指标是周期时间（也称为提前期）。这是进行更改（或更改请求，一直跟踪到构想开始）所花费的时间。我知道的这个概念的最好例证是《目标》一书，该书在制造业中谈到了这一目标。

部署频率也很有用。我们希望在DevOps管道中进行频繁部署。没有神奇的“ 1天好，2天坏”的度量；这需要项目的历史背景才能有意义。

部署规模：根据您的开发人员的工作规模来衡量-用户故事，故事点，四合院等。同样，您希望查看一段时间内的趋势，而不是绝对值。

在频率和大小之间有一个故事可以讲。我们的发行版本变得越来越少并且越来越大吗？为什么？他们变得越来越小，越来越频繁吗？同样，为什么呢？

要说明频率/大小趋势是否良好，我们还需要失败部署的百分比。了解这三个指标中的“原因”将告诉您有关项目运行状况的很多信息。

我个人最喜欢的是虚空部署，尽管它是虚荣的指标。如果您发现最小的事情值得重新部署整个站点（也许是CEO的名字打错了），您从紧急电话转到已部署站点的速度有多快？我之所以说“虚荣”，是因为它确实没有上述其他指标所讨论的那样具有预测性，但是当我喜欢这种价值时，会让我感觉很好。

如果我们要进行监视，那么我们可以跟踪很多不同的事情...从无所不包的事情（例如“ 正常运行时间 ”），到非常低级的事情，例如在请求-响应周期上重新生成自定义HTML所花费的时间 ...但是这些并不是建立DevOps文化所特有的。

这些并不直接与美元挂钩……这样做将需要比我在这样的论坛中提供的有关组织的更多知识；但是它们是开始回答该问题的关键。一旦知道您能够定期将工作作为非事件发布到生产中，就可以开始查看您之前浪费了多少精力。正如《目标》一书中所讲的（关于制造管道-这是相关的），本地优化看起来像是在省钱，但最终，它只会创造与库存相关的价值（未部署的功能）。

除此建议外，您还应该查看过去几年的《 DevOps状态报告》。这充满了关于您可以模拟的现实世界项目的度量。

明显的上尉：通过减少产品上市时间和发行缺陷。

要扩大这一范围，通常的陷阱是没有任何参考的组织变更。

参与文化或组织变革意味着在培训和向人们介绍这种新方法时会花费一些钱，这在培训上有成本，但也意味着生产力的损失，因为参加培训的人们不会产生任何东西。这是文化变革的投资部分。

要衡量投资回报率，您必须首先找到一些需要改进的相关指标（了解成本高昂，昂贵或利润损失的原因）。这样可以缩短上市时间，减少每次发行后的补丁，从而提高产品中的客户参与度。相关指标将高度依赖您的产品。

衡量ROI（您支付培训费用的速度）意味着您实际上可以提出这些指标的变化，因此在进行任何更改之前，您必须定义这些指标并以客观的方式对其进行衡量。
一旦有了一个真正的发展过程，您就可以判断您是否确实以某种方式改善了某些东西，从而可以覆盖培训费用并比以前获得更多的利润。

通常的陷阱是在定义任何指标之前进行更改，从而根据感觉而不是事实数据评估ROI。

生产率可以是一个度量标准，但通常很难以客观的方式对其进行度量，并且不应该将其作为此类研究的一流度量标准。

在这里比赛晚了，但以为我会报仇。

您无法管理无法衡量的内容，因此对于初学者而言，以下是devop团队应跟踪事件响应的关键指标：

• 正常运行时间百分比：总可用时间百分比 = [总时间-停机时间] / [总时间]
• MTTR：解决问题的平均时间= [停机时间] / [事件次数]
• MTTA：平均确认时间= [总确认时间] / [事件数量]
• MTBF：平均无故障时间= [总时间-停机时间] / [事件数量]

这些指标为您提供了运行状况的高级运行状况检查，并帮助您确定需要进一步挖掘的地方。

在此处查看白板动画，以更深入地了解该主题。

了解指标后，您就可以将它们与停机成本进行对比。您可以从那里开始建立团队的ROI，并设置一些定量指标以进行持续改进。