落地DevOps的路线图

最开始，瀑布模型过程中研发、测试、运维三种角色的工作是上一环节完成后，才能流转到下一阶段。

敏捷研发阶段，提倡是把大的目标拆解为小目标，小步快跑，快速迭代快速验证，测试左移的概念也是如此。

而devops的理念和实践，就是打破技术人员之间协作的那堵墙，通过高效的协作沟通，使软件交付形成自动化交付流水线，更快的响应和支撑业务需求，从而创造更大的业务价值。

• 对齐业务和技术团队的目标及评估指标；
• 在安全合规的基础上开展协作，落地devops；
• 及时对齐需求，抹平信息差，减少无用开发，避免返工；
• 让技术团队主动接触业务，调动积极性，体现devops的价值；

1. 前置时间：即Lead Time。它指的是一个需求从提出到最终上线交付的时间周期，这部分时间体现了研发团队的交付速率，可用来计算交付吞吐量。DevOps 的核心使命之一就是优化这段时长。
2. 增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time，简称 VAT/NVAT）。在软件研发交付过程中，不增值活动很多，比如无意义的会议、频繁的需求变更、不断reopen的bug等。VSM中很重要的一点就是消除浪费，降低不增值的活动。

3. 完成度和准确度（% Complete/Accurate，简称 %C/A）。这个指标用来表明工作质量，即有多少工作因为质量不符合要求而被打回。这里面蕴含了大量的沟通和返工成本，从精益视角来看，也是一种浪费。

1. 全局视角：单点突破很容易陷入局部优化的陷阱，devops追求的是通过持续交付推动流动，使价值最大化。而要构建企业级的devops持续交付流水线，需要全局视角。
2. 识别问题：从VSM的几个关键指标来看，都是客观可量化改进的指标。从全局视角识别出低效和不增值的活动，可以更好的针对问题进行改进。
3. 促进协作：识别出问题后，需要主动沟通才能保证信息的一致。而梳理VSM的过程，就是让参与其中的人员从全局视角理解devops的最佳机会。只有在梳理过程中，团队才能真正了解整个流程的上下游，通过沟通来促进协作。
4. 驱动度量：不能被度量的工作都无法证明其价值，构建企业级的devops持续交付流水线需要对整个过程进行明确客观的度量，才能识别其中的低效和不增值环节，度量也可以帮助我们判断改进措施是否有效。度量数据的采集，需要各个团队和平台间打通，做到数据共享，这也是devops落地需要解决的一大难题。
5. 体现价值：要落地devops，需要企业高层的认可甚至大力推动。而梳理VSM价值流的梳理过程，本身就可以让高层理解持续交付效率的提升对企业带来的价值。这其实也是devops证明自身价值的一个过程。

第一步-流动：通过工作可视化，限制在制品数量，并注入一系列的工程实践，加速从开发到运营的流动过程，实现低风险的发布；

第二步-反馈：建立快速反馈能力，使问题第一时间暴露，用户和运营数据第一时间展示，从而提升组织的响应能力；

第三步-持续学习和试验：通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步。

1. 寻找合适的试点项目：和混沌工程中所提倡的最小爆炸半径概念很类似。即在最开始实施时，选择合适的对象进行快速落地验证，很类似我们做技术调研对比汇报时的demo。合适的试点项目应满足如下几个特征：

1. 1. 贴近核心业务（重视程度高，资源投入足够）；
   2. 业务相对敏捷（业务不敏捷会拖累交付能力）；
   3. 项目对应团队有改进意愿（毕竟强扭的瓜不甜）；

2. 寻找团队痛点：有工作经验的同学应该都明白的一点，就是谁最痛谁才关心怎么解决问题。识别出项目所在团队当前最影响交付效率的点，这样更容易开展工作，也更方便看到投入产生的效益。
3. 快速拿到结果：即采用mvp方案，快速的解决最痛的也是最容易看到收益的难点，用数据证明工程实践改进是切实有效的。
4. 持续改进汇报：拿到好结果要快速让领导层知道当前的进度和结果，这样才能在后续的持续改进过程中获取更多的支持和资源倾斜。多沟通常汇报，永远是职场生存的不二法门。

1. 通过团队内部复盘总结，识别问题，快速改进；
2. 引入一些外部优秀实践和工具，快速提升团队能力；
3. 成立专门的devops落地团队，由各团队和领域的资深成员参与，负责落地计划制定、目标和风险识别、技术方案设计以及在关键节点推动项目的进度。