落地DevOps的路线图
这是devops系列的第二篇文章。
上篇文章发布后，有同学私信问我，企业如何落地devops？
老实说，这是一个很大的命题，而且也并没有标准答案。一个软件工程实践理念能否在企业内落地并达到一定效果，取决于很多因素。
比如是否有上层领导支持，是否有足够的资源投入，是否采取了正确且适合自己的方法，团队是否认可这项实践带来的价值等很多因素。
在聊企业如何落地devops之前，我想结合最近学习的devops相关知识，以我的理解，聊聊落地devops的路线图（指引人正确达成目标的路径）。
落地DevOps的源动力
我在上篇文章聊过软件工程中关于开发模型的演变。
最开始，瀑布模型过程中研发、测试、运维三种角色的工作是上一环节完成后，才能流转到下一阶段。
敏捷研发阶段，提倡是把大的目标拆解为小目标，小步快跑，快速迭代快速验证，测试左移的概念也是如此。
而devops的理念和实践，就是打破技术人员之间协作的那堵墙，通过高效的协作沟通，使软件交付形成自动化交付流水线，更快的响应和支撑业务需求，从而创造更大的业务价值。
以上这些都是在打破技术团队内部的协作隔阂，但在实际工作中，业务团队和技术团队之间的理解和沟通障碍更加严重。
如果业务需求方不能认同devops的实践理念，双方对于快速交付对业务价值的提升没有统一的认知，那devops的落地之能是镜中花水中月。
devops的目标是通过构建自动化交付流水线来提升交付能力，交付能力的提升可以帮助业务更快的小成本试错。
同时，用户和市场的情况如果能够快速地反馈给业务方，也可以帮助业务快速调整。
要达到这些，需要业务敏捷起来，对需求的设计和把控灵活调整，做有价值的事情，否则会拖累交付能力，整体效率也会下降。
因此在实际的devops落地实践中，业务敏捷，做有价值的事才是落地devops的源动力。
技术团队除了按照业务需求快速交付功能，还应该更快的为业务提供客观有效的数据反馈，辅助业务决策。
同时，交付能力的提升也进一步降低了业务的试错成本，而业务的敏捷性也决定了研发交付的需求价值和交付节奏。
这其实就是BizDevOps的理念，也是devops发展的一种潮流。BizDevOps意为：Business + Dev + Ops。
BizDevOps的核心理念如下：
- 对齐业务和技术团队的目标及评估指标；
- 在安全合规的基础上开展协作，落地devops；
- 及时对齐需求，抹平信息差，减少无用开发，避免返工；
- 让技术团队主动接触业务，调动积极性，体现devops的价值；
落地DevOps的切入点
devops的目标是通过构建自动化交付流水线来提升交付能力，这种持续交付能力是devops的核心能力之一。
但持续交付只是手段，而不是目的。目的是通过devops的持续交付能力来为团队为企业带来业务价值的提升。
Jenkins 的主要维护者 CloudBees 公司推出的 DevOptics 产品就主打 VSM 功能，而持续交付产品 GoCD 的 VSM 视图也一直为人所称道，他们的核心都不是持续交付产品，而是VSM。
VSM（Value Stream Mapping） 就是我们常说的价值流图。它起源于传统制造业的精益思想，用于分析和管理一个产品交付给用户所经历的业务流、信息流，以及各个阶段的移交过程。
从软件工程的角度来理解就是从需求到研发到测试再到上线交付给用户使用的过程。通过观察流程中各个环节的交付效率和交付质量，识别低效环节并进行优化，从而实现整体效率的提升。
VSM的几个关键要素和核心思想如下：
- 前置时间：即Lead Time。它指的是一个需求从提出到最终上线交付的时间周期，这部分时间体现了研发团队的交付速率，可用来计算交付吞吐量。DevOps 的核心使命之一就是优化这段时长。
- 增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time，简称 VAT/NVAT）。在软件研发交付过程中，不增值活动很多，比如无意义的会议、频繁的需求变更、不断reopen的bug等。VSM中很重要的一点就是消除浪费，降低不增值的活动。
- 完成度和准确度（% Complete/Accurate，简称 %C/A）。这个指标用来表明工作质量，即有多少工作因为质量不符合要求而被打回。这里面蕴含了大量的沟通和返工成本，从精益视角来看，也是一种浪费。
ps：此图来源于网络，侵删。
VSM是devops在企业内落地的切入点，它最重要的价值体现在如下几个方面：
- 全局视角：单点突破很容易陷入局部优化的陷进，devops追求的是通过持续交付推动流动，使价值最大化。而要构建企业级的devops持续交付流水线，需要全局视角。
- 识别问题：从VSM的几个关键指标来看，都是客观可量化改进的指标。从全局视角识别出低效和不增值的活动，可以更好的针对问题进行改进。
- 促进协作：识别出问题后，需要主动沟通才能保证信息的一致。而梳理VSM的过程，就是让参与其中的人员从全局视角理解devops的最佳机会。只有在梳理过程中，团队才能真正了解整个流程的上下游，通过沟通来促进协作。
- 驱动度量：不能被度量的工作都无法证明其价值，构建企业级的devops持续交付流水线需要对整个过程进行明确客观的度量，才能识别其中的低效和不增值环节，度量也可以帮助我们判断改进措施是否有效。度量数据的采集，需要各个团队和平台间打通，做到数据共享，这也是devops落地需要解决的一大难题。
- 体现价值：要落地devops，需要企业高层的认可甚至大力推动。而梳理VSM价值流的梳理过程，本身就可以让高层理解持续交付效率的提升对企业带来的价值。这其实也是devops证明自身价值的一个过程。
落地DevOps的路径和挑战
在《DevOps实践指南》这本书中提出了“DevOps 三步工作法”，概括了 DevOps 的通用实施路径。
第一步-流动：通过工作可视化，限制在制品数量，并注入一系列的工程实践，加速从开发到运营的流动过程，实现低风险的发布；
第二步-反馈：建立快速反馈能力，使问题第一时间暴露，用户和运营数据第一时间展示，从而提升组织的响应能力；
第三步-持续学习和试验：通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步。
具体来说，在devops落地实践过程中，可以将其拆分为以下4个步骤：
- 寻找合适的试点项目：和混沌工程中所提倡的最小爆炸半径概念很类似。即在最开始实施时，选择合适的对象进行快速落地验证，很类似我们做技术调研对比汇报时的demo。合适的试点项目应满足如下几个特征：
- 贴近核心业务（重视程度高，资源投入足够）；
- 业务相对敏捷（业务不敏捷会拖累交付能力）；
- 项目对应团队有改进意愿（毕竟强扭的瓜不甜）；
- 寻找团队痛点：有工作经验的同学应该都明白的一点，就是谁最痛谁才关心怎么解决问题。识别出项目所在团队当前最影响交付效率的点，这样更容易开展工作，也更方便看到投入产生的效益。
- 快速拿到结果：即采用mvp方案，快速的解决最痛的也是最容易看到收益的难点，用数据证明工程实践改进是切实有效的。
- 持续改进汇报：拿到好结果要快速让领导层知道当前的进度和结果，这样才能在后续的持续改进过程中获取更多的支持和资源倾斜。多沟通常汇报，永远是职场生存的不二法门。
当然，devops落地过程中会遇到各种问题，最典型的问题就是 J型曲线，来源于2018年devops状态报告，见下图：
面对这些问题，常见的解决思路有：
- 通过团队内部复盘总结，识别问题，快速改进；
- 引入一些外部优秀实践和工具，快速提升团队能力；
- 成立专门的devops落地团队，由各团队和领域的资深成员参与，负责落地计划制定、目标和风险识别、技术方案设计以及在关键节点推动项目的进度。
当然，最重要的，一定要争取到管理层的认同和支持。devops是对软件工程和研发交付流程的改革，改革势必会动到既得利益者的蛋糕，有了高层支持，才可以自上而下的推动。
借助大势的同时，快速的自下而上的改进，多沟通常汇报，才能让devops更好的落地。
