虚拟化，容器化，云计算，自动化为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 不同职能、不同产品之间分享开发和运维过程中的想法，知识，问题，以及失败经验，共同提升能力。
Q&A
Q：基于Jenkins的CI/CD不同用户是怎么管理的 ？权限怎么控制的？
A：在DevOps实施里面提倡充分授权团队，所以在基础设施自服务的基础上让团队有自己独占的Jenkins Master能够有效的减少权限控制此类问题，同时可以避免不同团队之间构建任务的相互影响；如果是共用JenkinsMaster，Jenkins有权限控制的插件可以控制用户的权限。
Q：刚才你介绍的CI整个交付流程，每个细节都需要花大量的时间和精力去开发和实施，如果公司团队很多，如果分配自己团队的时间，时间少了自然达不到效果。
A：在实施DevOps转型过程里面，可以先尝试试点团队，通过试点团队去完成DevOps工具链相关的技术选型，在工具链成熟的情况下向其它团队推广。
Q ：请问你们有DevOps的自动化运维平台吗？可能是一个Web页面，把DevOps相关的流程和工具集成在上面，方便管理的同时也方便运维开发一体化操作。这个平台可能还包括全链路检测系统？
A：目前我们公司做的基于容器持续交付平台主要就是解决此类问题，通过流水线来组织工具链，同时对相关的环节进行度量，为避免广告嫌疑就不便多说。
Q： 你们在这个过程中怎么做沟通管理，以防止因为这造成的对需求理解的偏差等问题？
A：这块更多是团队的组织结构的问题，有兴趣可以尝试通过看板方法，团队的各个角色都会基于看板完成迭代的开发，通过看板可以帮助团队成员之间的沟通和需求确认。
Q：因为很简单，持续集成持续交付，快速迭代，小步快跑，稳扎稳打，这些都有所有的理论最后都回归到代码，所有的变更都回归到本源代码的变更，如何保障所有的变更无遗漏，如何保证每一次任务都在正确的代码基准线上进行，如何出了问题快速反馈到研发第一线，及时终止问题的蔓延？
A：这块其实主要的方式就是基于持续部署流水线的方式，上面分享的时候有提到。通过将流水线通过自动化流水线的方式进行控制，在任何阶段出现问题都应该让流水线失败（门禁），另外出问题不怕，快速解决问题是关键，对于流水线最好可以设置Webhook实时触发，可以确保当问题出现后，问题代码的域可以关联到最近的一次提交。
Q：请问你们容器发布是如何自动区分开发、测试、正式等不同环境的，是否需要人工介入修改应用访问关系和启动环境变量？
A：目前我们自己持续交付平台对接不同的容器运行环境（目前主要是Rancher），团队会对环境进行分类管理，流水线中进行容器部署的时候选择相应的环境即可；另外由于主要是基于容器在做，所以也对容器镜像的不同状态也进行了划分，并且在多个Registry实例之间进行了流转，物理隔离了开发，测试以及发布状态的容器镜像。人工介入的部分主要是控制镜像状态的变化这块。
Q：Jenkins的Pipeline和普通的Project都可以支持流水线 ，2者有区别吗？
A：主要解决的问题就是当构建出问题的时候如何快速定位问题，假如在流水线线中涉及8个阶段，如果只是在一个Project中实现，需要开发者花很多时间定位；如果是Build Pipeline的话，则可以很直观的知道问题是发生在什么阶段。
