从制造业/高度稳定的组织/高度信任的管理模型等数十年的积累下来的各种基本理论以及原则是DevOps需要继续继承的宝贵遗产。从这个角度来说，DevOps与之也是一脉相承的。
价值流
制造业中的价值流
传统的制造业的精益运动中，价值流是一个非常重要的概念，Karen Martin 和Mike Osterling是这样定义
| | 定义者 | 价值流 |
|---|
| Karen Martin &Mike Osterling | “the sequence of activities an organization undertakes to deliver upon a customer request,” |
| “the sequence of activities required to design, produce, and deliver a good or service to a customer, including the dual flows of information and material.” |
从这些断片的描述中我们能够清晰地理解到制造业中价值流的存在：明确定义了的需求的业务以及价值交付的对象客户，而在这之间的行为的序列和流动，就构成了价值流。
在制造业中，从接到客户订单的那一刻起，价值的流动用眼睛就能清晰地看到。碓在工厂里面的原料，开来开去的叉车，精益运动带来的价值流改善甚至直接能够从堆放的WIP半成品的高度来进行确认。
IT领域的价值流
在科技领域看到的堆放的原料和叉车告诉我们价值流动的无处不在。在软件开发等科技领域，价值流同样存在，而且制造业的原则和经验同样适用。同样是接到由业务部门提供了的明确的需求定义，开发，测试，部署，交付给运维，最终价值的流向同样流向了客户。区别于传统制造业的产品，一般科技领域的价值流最终交付的形式更多是以服务的形式进行的。
价值的体现只有在我们开发/测试了的软件运行在面向最终客户的生产环境之上时，在IT领域价值的流动才最终完成，在那之前也都只是WIP而已，这个就是为何我们一直在强调交付时间。而这些也是在最近十年之内互联网公司诸如Amazon作的比较好的一个地方。
虽然交付时间非常重要，在DevOps中，交付时间也不是全部。“快”很重要，但是可靠性/稳定性/扩展性/安全性同样重要。DevOps追逐的快速价值流动，是建立在不会因此而带来服务中断/安全事件等混乱性事件的基础之上的。
交付时间
讨论交付时间需要了解开发的全生命周期，软件开发领域的全生命周期细化可以作的无比复杂，而且各个公司也有多多少少的区别。但是如果概略的讨论，则基本一致地分为：设计/开发/测试/交付。结合精益相关类似可以参照的方法，对于交付时间的可能影响，简单整理如下
| | 阶段 | 特点 | 类似可参照的精益方法 |
|---|
| 设计开发 | 创造性高/不确定性大/难度大等导致预测和实际交付时间差别可能很大 | Lean Product Development |
| 测试运维 | 经验性/不确定性小良好的实践很容易降低预测和实际之间的差别 | Lean Manufacturing |
交付时间和处理时间
交付时间是客户在体验到的一个关键指标，在需求明确提出的那一刻起，交付时间的时钟已经开始在运行了。而在软件开发生命周期中，我们更多关注的则可能是我们什么时候开始/什么时候结束的，而这个在概念上来说应该叫做处理时间。
通过精益实践的改善，减少处理时间是在非常常见的一种实践改善，处理时间的减少，等同于交付时间的减少，而等待时间的减少也能够减少整体的交付时间，减少浪费和消除等待也是精益实践中最重要的策略，而这些在需要整体的角度去协调和控制。
软件开发的价值流
和传统领域一样，软件开发领域的价值流也非常复杂，甚至更为麻烦，但是精益的方法和实践原则在此是可以通用的。比如如下是Damon Edwards在2015年“DevOps Kaizen,”中展示的一个例子。
通过精益原则和方法的实践，软件开发领域一样能和已经成功转身的制造业那样切实提高实际的交付速度。
部署时间指标
理想的DevOps：按分计的部署时间
关于理想化的DevOps，在下面这篇文章中有着详细的说明，不再赘述。
如果将经过质量确认的测试的应用放到生产环境这个被称之为部署的环节来举例，一个理想化的DevOps在这个环节应该能够实现到什么样的量化标准呢？它可能应该是这样的：
C/A指标
C/A: Complete / Accurate .是一个用来衡量REWORK的指标。
| | 定义者 | C/A |
|---|
| Karen Martin 和 Mike Osterling | the %C/A can be obtained by asking downstream customers what percentage of the time they receive work that is ‘usable as is,’ meaning that they can do their work without having to correct the information that was provided, add missing information that should have been supplied, or clarify information that should have and could have been clearer. |
一般在DevOps实践中，比较常见的会计算出在某一个交付周期之内，所作的全部的Story Points和被客户接受了的Story Points，而没有被接受的则表明由于各种原因将会产生的REWORK。
DevOps的三个基本原则（Three Ways）
在Gene Kim的凤凰项目的那本书中提到了Three Ways的基本原则，每条原则都有其所侧重的内容，适用这三条基本原则能够帮助DevOps在实际的项目中更好地展开。
第一条原则：流动
流动：价值的流动，从上图中可以看到从左到右，从业务需求到交付客户，贯穿着从开发到运维的这条正向的通路。在这条原则的使用中，我们经常使用很多方式进行实践以期达到交付价值的单位时间最大化，比如
| | 项目 | 详细 |
|---|
| 规模 | 减小批次的规模 |
| 间隔 | 减小工作的间隔，消除等待 |
| 可视化 | 工作的可视化 |
| 缺陷 | 防止缺陷向下游的流动 |
| … | … |
第二条原则：反馈
反馈：在整个价值链的各个阶段，通过自右向左的逆向反馈以期达到问题确认/持续改进/提高质量的目的。通常使用这条原则的实践活动有很多，比如：
| | 项目 | 详细 |
|---|
| RCA | 放大反馈，防止问题再次发生 |
| 检测 | 通过监视机制，保证问题发生时候的快速定位 |
| 恢复 | 通过强化恢复机制，保证故障发生时也不至于服务的中断或者服务质量的大幅降低 |
| … | … |
第三条原则：文化
文化：文化方面主要从两个方面进行推进，持续试验和持续学习。在DevOps实践极大降低了生产环境中的实验性的尝试可能带来的风险的前提下，鼓励勇于尝试和创新以及高度信任的企业文化，持续试验结合持续学习，推动整个企业一个整体的方式不断推进。
总结
在这篇文章中，我们了解了价值流/交付时间/原则等DevOps实践中相关的基础知识，尤其是Three Ways，在后续的文章中，将会围绕这些基本原则进行展开。
Referrence
| | 参考文献 | 作者 |
|---|
| The DevOps Handbook | John Willis, Patrick Debois, Jez Humble, Gene Kim |
