度量驱动的DevOps转型

虚拟化，容器化，云计算，自动化为DevOps运动提供了底层技术支持，新的工具链和技术栈的采用进一步降低了DevOps的技术门槛，越来越多的企业纷纷开始自己的DevOps转型之路，然而……

本次分享我们将会讨论到：

• DevOps以及企业DevOps转型的现状

• 为什么我们需要在DevOps转型中强调度量

• 如何实现度量驱动的DevOps转型

• DevOps转型中的其它实践

Wiki上讲：DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例 （这个是目标）透过自动化“软件交付”和“架构变更”的流程（这个是方法）来使得构建、测试、发布软件能够更加地快捷、频繁和可靠（这是结果）。

所以对于企业来说的真正价值则在于通过团队间协作关系的改善， 整个组织效率的提升的同时，可以有效降低伴随频繁变化而带来的生产环境风险，从而提升企业应对市场变化响应力。

根据2016 DevOps调查报告显示。成功实施DevOps组织可以更快的去适应整个市场环境的变化，同时能够更快的做出调整。

拥有相比竞争对手拥有更加高的部署频率，更快的故障恢复时间，更低的变更失败率以及以及更短的需求交付周期。

然后当企业大量的采纳并使用这些新的工具链之后，我们并没有看到我们所交付的软件真的如同DevOps的目标一样，能够真正的实现软件快捷，频繁并且可靠的交付。

DevOps不是盲目的使用新的工具链和技术栈，通过自动化部署流水线的方式，将低质量的代码频繁的部署到运行环境。

目前实施DevOps转型的传统企业，通过引入自动化确实能提升在软件交付的某些环节中的效率，但是却很难去提升软件的交付质量，依然引入独立的测试部门进行大量的系统测试来确保软件的质量，同时企业也很难度量持续交付和DevOps实施的效果。

所以目前大部分企业基本上是把自动化当做DevOps在做，把自动化部署当做持续交付在做，而很少去考虑软件交付流程的整体性优化。

自动化是实施DevOps的先决条件但是并不能真正的帮助企业跨越DevOps转型的鸿沟的银弹。

而对于DevOps的成功转型而言，我们需要做的是持续的对我们的软件交付过程进行优化，发现软件交付过程各个环节中存在的瓶颈并持续改进。

You Can’t Fixed What You Can’t.

而数据和度量则是帮助企业去发现DevOps转型过程中的瓶颈并且做出改进的关键基础。

在开始时我们说从Wiki上看，DevOps会主要设计到3个部分：目标，方法和结果。

所以从度量的交付上看我们需要从两个方面去度量我们的DevOps转型。哪些度量指标是能够支撑企业判定DevOps转型结果。而哪些是能够去评判软件的交付过程，并且用于发现交付瓶颈的。

根据2016DevOps报告显示，目前度量企业DevOps转型是否成功的最终结果性关键指标包括：

吞吐量指标：部署频率，变更交付周期。

稳定性指标：变更失败率，问题平均恢复时长（mean time to recover）。

吞吐量即敏捷性，确保企业能够适应市场的变化，并且快速做出反馈。稳定性，即高质量。

相比于传统的IT服务流程绩效指标ITIL而言，DevOps更加关注结果性指标， 即客户价值。

就好比我们做软件交付和外卖小哥其实很像，可以评价一个产品是否优秀更多的是看交付效率如何，质量如何，并且是不是能够满足我的预期的？

这两种截然不同的度量方式本质就是OKR和KPI的区别：

OKR基于目标和关键成果，促使我们思考，沟通，每个人都知道什么是最重要的；并且能让团队所有人共同的为某件事而努力。

所以对于基于OKR驱动的DevOps可以确保参与软件交付过程中的所以角色围绕具有通过的目标，并且为了这些共同目标去尝试新的技术和方法。

而KPI理论则避免按照SMART标准制订，有些事情值得去做，但在做出来一部分之前无法测量因此无法制订目标。KPI 还有一个更严重的问题，那就是为了完成可测量的目标，有可能实际执行手段与该目标要达到的愿景正好相反。

KPI使得团队使劲往前走，而OKR则确保团队能够往正确的方向走。而在软件交付过程中，开发，测试，运维都有着不同的考核标准。所以KPI能够团队各个成员使劲的按照各自的目标走，而OKR则确保团队能够一起往正确的方向走。

DevOps需要的是整体性的优化，当你选择自己企业内部的度量标准时，请问自己两个问题：

为什么需要度量这个指标？从这个指标中我们能学到什么？

根据DevOps 2016报告高效的IT组织与中等和低效的IT组织之间在DevOps最终结果性关键指标存在则显著的差异。

DevOps的最终结果性指标能够帮助企业去衡量和评判DevOps转型的结果。

当然除了结果性的指标去验证DevOps转型所起到的作用以外，我们还需要持续的度量其他的数据去帮助我们发现在软件交付各个阶段的问题。

包括从需求管理，源码管理，构建过程，测试过程，部署过程，发布，配置管理，监控等各个方面，这里我们列举了在各个过程当中可能需要的一些度量数据。

其中比较典型的包括通过对需求管理进行度量，我们可以知道从需求到需求部署上线的变更交付时间。

在CI过程中我们持续的去获取相关的过程数据，如构建次数，构建频率，构建时长，成功率，平均恢复时间等可以帮助团队去判定研发团队是否能够做到小步提交，频繁提交，并且当发现问题之后能够快速的恢复。

除此之外，低质量的，高复杂度的代码也会使得软件交付效率无法得到有效提升，所以我们需要持续的获取代码质量相关的数据，持续改进代码质量等等。