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