| 编辑推荐: |
| 本文来自于微信号devopshub,文中说到了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过程中我们持续的去获取相关的过程数据，如构建次数，构建频率，构建时长，成功率，平均恢复时间等可以帮助团队去判定研发团队是否能够做到小步提交，频繁提交，并且当发现问题之后能够快速的恢复。
除此之外，低质量的，高复杂度的代码也会使得软件交付效率无法得到有效提升，所以我们需要持续的获取代码质量相关的数据，持续改进代码质量等等。
所以对于度量驱动的DevOps转型而言，我们需要持续的去获取在软件交付各个阶段所产生的数据，以及软件部署上线之后的监控数据，用户行为数据等，并且形成对团队所有人可见的DevOps可视化看板。
而产品/需求管理人员，则可以根据DevOps结果性数据去评价在过去一段时间内DevOps实施所产生的效果，从过程性数据中去发现交付过程中的瓶颈，根据用数据以及线上监控数据去评价软件产品是否如预期的一样产生相应的价值，如果没有，是否应该做出及时的调整。
除了通过自动化的方式去构建软件交付的端到端流程提升软件交付，并且持续的获取软件交付的各个阶段所产生的数据以外。
我们还应该在软件交付流程中去设置相应的门禁机制，去让不满足质量要求的构建快速失败。
在实践当中，根据软件产品的体量的不同完整运行端到端自动化的过程可能会非常长。
所以对于研发团队而言，持续部署流程所产生的反馈周期过长，不利于研发团队快速发现和解决问题。
基本CI流水线频繁执行，由代码提交触发，包含构建，单元测试，集成测试，代码静态扫描，部分自动化验收测试等（端到端运行周期短）。
FOR TEAM：全量流水线每日定时多次触发，包含构建，单元测试，集成测试，代码扫描，全量的自动化验收测试，部署，部署冒烟测试等等（端到端运行周期长）。
FOR QA：手动指定版本部署，手动触发。
通过分层流水线，在满足快速反馈的原则的同时，又能持续的对软件进行集成和测试。
同时在流水线当中通过引入质量门去控制代码质量，避免技术债务的积累。
当然对于历史遗留系统而言，通常会存在大量的历史债务，这时候我们可以将当前系统的代码质量作为基线标准，同时针对新增代码设置质量门控制，包括新增代码的代码风格，复杂度，测试覆盖率等。
通过可视化流水线将将持续部署流水线的构建过程向整个团队进行展示，让所有人都知道当前的项目构建状态以及进度，如果又构建失败了，成员之间也可以相互提醒尽快修复流水线的失败。
持续的获取过程有效性数据和质量有效性数据为团队提供可视化看板。
除了门禁机制以外，质量内建也是团队成功实施DevOps的关键因素，通过在软件交付的各个阶段建立自动化的保障体系可以使团队能够尽早的发现和解决发现的缺陷。
对于度量驱动的DevOps转型，通过自动化部署流水线有效提高软件交付的效率，通过质量内建确保软件交付的质量，通过对过程性数据的持续收集和分析发现交付过程中存在的瓶颈，通过对软件产品和用户的线上数据获取反馈并且及时作出调整，通过结果性数据去评价团队的成效。
最后对于企业DevOps转型而言：
Automation 自动化是实施DevOps转型的先决条件，自动化一切可以自动化的，降低部署和发布的难度。
Measure 通过建立有效的监控与度量手段来获得反馈，推动产品和团队的持续改进，支持业务决策。
Lean 协作文化，自动化，和有效的反馈，这些实施是个长期的过程，需要以精益的方式小步快跑，对过程与技术进行持续改善。
Culture OKR目标和关键成果驱动 建立具有跨职能协作文化和共同目标的一体化团队；这是DevOps运动的根本！
Sharing 不同职能、不同产品之间分享开发和运维过程中的想法，知识，问题，以及失败经验，共同提升能力。 |
