| 编辑推荐: |
| 本文来自微信号MyDevOps,本文先介绍第一步建立从左到右的流，即流动原则，并且将此书第二部分中关于DevOps项目实施套路（方案）的内容也在此简单描述一下。 |
|
流动原则的目标是建立平滑的价值流
流动原则的目标是创建必要的技术实践和架构，从而能使工作从开发到运维的的方向稳定快速地流动，与此同时还能保证不会对生产环境造成混乱，不会使客户服务中断。这就意味着需要降低在生产环境中部署和发布变更的风险。可以通过*持续交付*的技术实践来实现这个目标。
注：上图在很多DevOps分享中也被解读为系统性思考，其实这幅图要表达的意思是建立价值流，和实践流动原则。当然系统性思考是价值流的设计，在过程中解决约束点的必要思考方法。
建立基于稳定的自动化部署流水线的持续交付，团队能够使用自动化测试持续验证代码，确保代码始终处于可部署的状态，开发人员要保证每天都向主干提交代码，以及构建有利于实施低风险发布的环境和软件架构。重点的内容如下：
* 为部署流水线奠定基础
* 实现快速、可靠的自动化测试
* 实现并实践持续集成和持续测试
* 通过自动化、架构解耦等方式实现低风险发布
这些实践能有效缩短创建类生产环境的前置时间。同时，持续测试可以为所有团队成员提供快速的反馈，使小型团队能够安全、独立地开发、测试和向生产环境部署代码，从而将生产环境的部署和发布作为日常工作的一部分。
此外，通过将QA人员和运维人员的任务集成到DevOps实施团队的日常工作中，能够减少救火、困境以及繁琐的重复劳动的发生，使团队成员的工作高效且充满乐趣。这不仅能提升团队的工作质量，还能提高组织的竞争力。
这一部分的详细技术实践请参考《DevOps实践指南》一书的第三部分，这部分包含第10章到第13章，一共描述了5个技术实践。
Stop starting. Start finishing. - David J. Anderson.
在这个步骤里我们强调的而是全局的目标而不是局部的目标，局部的目标如下：
* 特性开发完成率
* 测试发现/修复缺陷的比例
* 运维的可用性指标
要减少价值流中的交接次数，当交接次数多到一定程度时，所有人都会彻底的迷失，无法回答工作的上下文联系和我们要解决的是什么文件或者组织的全局目标是什么？
可视化价值流，持续优化价值流
如果DevOps转型的项目是棕地项目，要对工作的价值流进行细致的研讨和分析，画出当前的状态。如下图的示例所示（注：这是一个示例，你的棕地项目分析完之后并非如此）。
注：欲查看以上图片的高清大图，请点击页尾的原文链接。
要分析出当前价值流的核心定量指标：
1. 总计前置时间 = 求和价值流中每个工作步骤里的LT
2. 总计增值时间 = 求和值流中每个工作步骤里的VA
3. 完成且精确百分比 = 连乘值流中每个工作步骤的%C/A
如果是绿地项目，第一周的价值流图是没有这些数值的，在每天的CI/CD流水线工具中采集，在每个人的日常工作中关注和记录相关数据，做每周多次的度量时间分析，最好用仪表板展示工具，将它显示到项目组成员可以轻松看到的位置。
对价值流进行持续的优化，是它更高效的工作起来，并不断的进化。如果是棕地项目，那么在分析完以上的机制流之后，可以定制新的进化版的价值流图，并按照这个版本开始执行项目。如下图的示例所示（注：这是一个示例，你的棕地项目改进优化完之后并非如此）。
在实践运用流动原则的相关技术实践实施以上价值流的过程中，可以使用Goldratt博士给出的方法，随时识别并解决价值流中的约束点，这个五步法如下：
* 识别系统的约束点。
* 决定如何利用这个系统约束点。
* 基于上述决定，考虑全局工作。
* 改善系统的约束点。
* 如果约束点已经突破了，请回到第一步，但要杜绝惯性导致的系统约束。
以上五步法是DevOps实施项目组日常工作的必备流程优化工具。
传统企业或者团队里最容易发生的约束点有一定的共性，一般可能会按照以下顺序逐个攻克和优化：
1. 环境搭建
2. 代码部署
3. 测试的准备和执行
4. 紧密耦合的架构
杜绝浪费现象
在DevOps工作团队里需要尽快能地避免以下浪费现象的发生：
* 半成品
* 额外/多余工序
* 额外/多余功能
* 任务切换
* 等待
* 移动
* 缺陷
* 非标准或手工操作
* 填坑侠
《凤凰项目》对三步工作法的解释
在本书中，我们阐述了这一基础原理，即所有开发运维模式都来自“三步工作法”，它旨在阐明指导开发运维的流程与实践的价值观与理念。
第一工作法 是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。
必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。
第二工作法 是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。
“必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。
第三工作法 是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。”
“尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。
必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。” |
