DevOps的基本知识介绍

此刻，您可能已经充分地接纳DevOps了，但您的同事可能还没有。也许以下这些内容会对您有帮助：

根据Google DORA（ DevOps、Research与Assessment）团队最新的《DevOps现状》报告，在DevOps方面成效不佳的团队很少能够在6个月内将软件投入生产运营。即便他们做到了，也会有16%-30%的失败率，而且他们很可能需要长达六个月的前导时间来让代码投入生产运营。就算变更不那么频繁，但某些事情发生变更带来的风险相对较高，而下一次更新可能又需要6个月的时间。

与此相比，精英团队的部署频率要高出973倍（基本上可以每天都可以根据需要进行多次更新），从提交到部署的交付周期要快6570倍，从故障中恢复的时间更快，其变更失败的可能性要低30%。

虽然上面的数据令人印象深刻，但可能仍然让您感觉有点抽象。当您把失败与美元价值关联起来，那将会是什么感觉？

根据IT软件质量联盟（CISQ，Consortium for IT Software Quality ）2018年发布的报告，美国劣质软件的总成本为2.84万亿美元。平均而言，每个失败项目的成本大约是5000万美元。即使是打折为十分之一，想想您是否真的能承受那么多钱的损失。

为什么推出高质量的软件如此困难？人们普遍认为，是因为企业很难及时获得并响应客户的意见。敏捷开发流程和其它现代化开发方法旨在降低风险，但您企业的其他成员如何才能步调一致并以最快的速度交付价值呢？

答案就是——采用DevOps非常有益，而且应用越好收益越多！

您需要做什么？具体应该怎么做？

如果您具备DevOps的基本知识，您的团队就有可能变得更加敏捷，更加协调一致。他们就能够比以前更快地将更高质量的代码推向生产第一线。这太好了！尤其是如果您在其中扮演了重要角色那就更值得庆贺！

但也有时候，这些改善带来的实际收益不够显著，也有可能就是您的管理层需要调整期望值。这时候您就需要认真考虑下一步如何行动。

问题的关键在于您需要ROI方面的真凭实据。您可能会担心，您的下一个步骤可能不会像在早期阶段看到的那样效果显著。也就是说，您如何证明继续改变可以加快DevOps的有效性呢？您可能会遇到以下一种或两种情况：

需要克服惯性：这就是我所说的问题——“我们不就是按部就班做的吗？”您对您的团队说您想引入新的DevOps实践，但他们已经根据当前的实践设计了工作流程。改变常常很难，尤其是当人们刚刚适应上次的改变之后。

管理层期望过高：谁没有经历过这种情况呢？通常，高管层的期望都很高，有时他们似乎没有真正意识到这项工作到底有多么复杂。创新的压力接踵而至，而且一波比一波更紧迫。您能跟上节奏吗？

解决上述这两个问题——阻力和压力——可以通过这种方式完成：确定“关注点”，同时找出您希望改变的一组指标。没有人会说：“改变流程把软件做得更糟糕些。”但简单地说“让它运行的更好、更快”并没什么意义！

当考虑如何确定ROI的时候，或者为DevOps的投资寻找理由时，需要首先搞清楚哪些指标可以衡量，哪些指标不可以衡量。

大多数企业都可以确定解决客户报告的一个缺陷需要多少钱。随着自动化测试的增加，可以更快地发现缺陷，并以更低的成本修复缺陷。如果您可以将缺陷的数量减少5%-10%，这就是一个可衡量的价值。请注意，您的团队中仍有人需要完成修复缺陷的工作，因此我们不会重复计算节省的费用。

有些好处却很难衡量，但可能会随着时间的推移而改变，值得追踪。企业商誉就是一个很好的例子。衡量企业商誉有不同的方法。在风河公司，我们使用净推荐评分（Net Promoter Score），也就是客户向他人推荐我们的可能性有多大。您的企业可能会使用不同的测量指标。关键是，您可以使用这个指标跟踪您在市场上的商誉。因果关系很难确定——您的商誉是否因为质量提高或其他市场因素而提高？但如果您追踪指标的变化，就可以分辨出正面或负面的趋势。

商誉对销售有影响，如果您可以获得这些数据，它就可以让趋势显现出来。大多数销售或营销团队都可以追踪到续约率与客户满意度、现有客户渗透、甚至是媒体正面报道都是正相关的指标。再次强调，因果关系很难确定，但值得追踪。

因此，改善底线成本节约就成为一种明显的结论。另外有些指标不易测量但的确能给企业增加利润。

审核编辑：彭静