DevOps的三条基本原则：流动/反馈/文化。第一条原则（流动）需要达成快速平稳地从开发向运维的价值流动，从而更快的进行价值交付。在这个过程中，作为开发或者运维的局部目标被弱化，而开发和运维等协同所产生的整体的共同目标在这条原则中得到强化。
从业务需求到交付客户，贯穿着从开发到运维的这条正向的通路。在这条原则的使用中，我们经常使用很多方式进行实践以期达到交付价值的单位时间最大化，比如

项目	详细
规模	减小批次的规模
间隔	减小工作的间隔，消除等待
可视	工作的可视化
缺陷	防止缺陷向下游的流动
…	…

而我们的目标则是降低变更交付到生产环境为止所需的时间以及提高交付的服务的质量和可靠性。

可视

区别于制造业最显著的一个区别是：工作不像制造业那样可视，而且也有着显著的不同。就像制造业中的WIP，在我们实际的项目中也是一样，由于没有仓库存储的警告，浪费的发生在不经意间随处发生，如果再加上缺乏有效管理，这些问题可能只有在快要着火的时候才会被察觉。
可视化有很多种方法可以帮助到我们，比如看板等，通过这个我们能够看到实实在在的任务，可以移动它从一个状态改变为另一个状态，确认整体的WIP状况等等。如下是一个使用看板使用的例子

从这里可以清楚地看到瓶颈，看到等待队列，看到任务的分布，以及在此基础上可以做出的短时间范围的预测。

限制半成品 (WIP)

像制造业那样，控制半成品，可以达到消除浪费的目的，减少了库存的压力以及费用，同时更为重要的是使用原本在半成品上进行的时间和成本完成更多的交付，仅仅通过流程的控制就达到了交付能力的提升也是存活下来的制造企业最基本的实践能力了。
软件的开发的WIP不像制造业那样很明显地堆积，存储的成本也不高，但是由此造成的更好的交付能力的下降却是同样的，举个极端的例子，如果有100个功能模块，本来一个月可平均作10个，但是第一个月就同时展开30个，结果在第一个月和第二个月都没有任何交付，到第三个月开始有爆发式的交付，结果给部署带来极大压力，以及bug同时出现需要对应，以及各种情况组合出现的各种复杂现象可以想象一下。
所以限制半成品非常重要，方法也很简单。借用“Kanban: Successful Evolutionary Change for Your Technology Business”这本书的作者David J. Andersen所说的一句话进行总结：Stop starting. Start finishing.”

减小批次大小

作业内容的批次的大小会对交付和产生浪费的根源的等待产生什么样的影响呢?可以通过“envelope game”来研究一下。“envelope game”游戏是James P. Womack 和 Daniel T. Jones在”Lean Thinking: Banish Waste and Create Wealth in Your Corporation”中提到的一个很有趣的游戏。
拿“envelope game”这个精益练习中常用的游戏为例，可以很容易地看出批次大小的调节能够对交付产生的影响。游戏的内容简单说明如下：

项目	说明
原料	纸/信封/邮票/胶水：原料均足够（假定单人）
Step 1	fold: 折纸
Step 2	insert：将折纸装入信封
Step 3	seal：封信封
Step 4	stamp：贴邮票
交付标准	全部完成Step 1 - Step 4的所有步骤的信封

使用不同的方式，Large Batches把Step 1的内容完成之后，才开始全部做Step 2的内容。而Single-Piece方式则是一个每次一小步。具体的等待和交付的情况如下图所示：

可以看出，Single-Piece很快就可以稳定地提供交付成果了。有Agile经验的开发者可能会立即意识到这在很大程度上简单展示了传统开发方式和Agile在价值交付方面差别。正是这样，“小步快跑”避免摔跟头，有问题也可以及时调整，这正是减小批次大小的意义所在。

降低手工作业次数

一旦当我们积累了数月以上的新功能特性或者修正后的模块，很多情况下在把应用部署到生产环境上会不可避免的碰到很多的手工作业，比如服务器的设定/存储的管理/网络的更新/负载均衡/安全管理等等，可能需要很多项目的技术高手也协同解决这些问题。
这些很难避免的手工作业，随着次数的增加会导致沟通成本的上升，以及等待时间的显著上升，因为这些技术高手一般都很繁忙。而且，在实际的情况下，手工作业也不可避免地造成部分信息的丢失以及潜在隐患的埋下。
因此通过自动化或者其他流程上的改善，比如避免大规模的交付同时出现，以稳定可预期地方式稳定地更新和改善着交付给客户的应用，能够降低由此带来的不好的影响。

持续评估

为了降低交付时间增加交付吞吐，需要持续确认和评估现状以及可以改善的余地。而这其中的关键则在于确认瓶颈然后再瓶颈上进行改善。正如TOC（Theory Of Constraints）的提出者Goldratt 所说的那样：“In any value stream, there is always a direction of flow, and there is always one and only constraint; any improvement not made at that constraint is an illusion.”任何不再关键流程上的改善都不是真正的改善。
而如何找出这需要改善之处，Goldratt 博士也给出了解决的方法：五步聚焦法（“five focusing steps”）

项番号	步骤
No.1	找到系统的制约因素
No.2	彻底激活制约因素,比如通过轮班保证关键机器不停运转
No.3	调整其他所有因素以适应此制约因素,以降低WIP
No.4	提升制约因素的能力,比如当轮班仍然没有足够生产能力时,启用旧机器,购置新设备等手段也需要纳入考虑范围
No.5	制约因素消除后重新回到步骤1,进行持续改善.

在典型的DevOps实践的过程中，可以使用五步聚焦法确认对象和进行改善。比如为了降低交付时间，需要改善的对象（Constraint）一般如下：

项目	说明	改善方式
环境创建	如果环境创建本身都需要很长时间，按需交付则是无法实现的	按需自服务的环境提供方式
代码部署	代码部署需要很多手工操作等	通过Automation提供按需服务
测试和运行	测试环境以及数据的准备以及手工测试需要花很多时间	按需自服务的环境提供方式，同时进行TDD的自动测试，并行执行以缩短时间，分级测试用例，标准化上线所需的最小限的测试用例
紧耦合架构	紧耦合的架构导致扩展困难，测试复杂，影响范围巨大	架构进行耦合优化，降低耦合

关于消除了主要制约因素的情况的美好情景，在这篇文章中已经有过说明。

DevOps能为我们带来什么	http://blog.csdn.net/liumiaocn/article/details/54696731

消除困局和浪费

浪费在精益中被如下定义：

项目	说明
waste	the use of any material or resource beyond what the customer requires and is willing to pay for
浪费	超出客户需求而且客户不愿为之支付的任何材料和资源的使用

TPS(Toyota Production System)先驱者之一的Shigeo Shingo（新郷重夫）更是认为浪费就是对业务生存能力的最大威胁。Shigeo Shingo将制造业中的浪费分为七种。让我们来看一下Shigeo Shingo所总结的”浪费的七宗罪”：

项目	说明
inventory	库存
overproduction	生产过剩
extra processing	不必要的加工步骤
transportation	运输
waiting	等待
motion	不必要的动作
defects	缺陷

现代的精益实践过程中逐渐意识到单纯地消除浪费（eliminating waste）可能会带来demeaning 和dehumanizing 的工作氛围的风险。每个人都在象是工业时代的一个无法停止的自动挥动的扳手，任何不必要的动作则会陷入需要改善的反省中，完美对应的结果就变成了或者近乎变成了一个机器人。相反，通过每天的持续学习来解决单调乏味繁重无意义的工作困局和浪费以期实现组织的目标，这是现代精益实践正在着力解决的问题。而这种现代对浪费的定义则更加接近我们所提倡的DevOps。
在精益软件开发领域，同样也有很多这样困局和浪费一直在困扰着我们，比如：

项目	说明
Partially done work	各种被搁置的WIP
Extra processes	任何不能带给客户附加价值的多余流程, 它作用仅在于消耗精力和拖慢交付
Extra features	比如项目管理上的镀金(gold plating)
Task switching	任务切换，同一个人被分配到多个项目上，项目间作业的切换会带来不必要的浪费
Waiting	等待
Motion	可以不需要的额外沟通等。比如必须需要手工作业或者准备的时候
Defects	各种情况引起的缺陷
Heroics	各种救火行为频发

而通过DevOps的实践，逐步消除这些浪费和困局，将对项目的良性发展起到一个很好的推动作用。

总结

改善价值流的快速流动对达成DevOps目标非常关键，而我们可以通过工作可视化/限制WIP/减小批次大小/降低手工作业次数等手段，并且持续评估和消除制约因素，从而更好地消除日常工作中的困境和浪费。

Referrence

参考文献	作者
The DevOps Handbook	John Willis, Patrick Debois, Jez Humble, Gene Kim

DevOps企业实践指南(3): 第一条原则：流动相关推荐

DevOps企业实践指南(4): 第二条原则：反馈
DevOps的第二条原则名为反馈,它存在于价值流的各个阶段的逆向过程中,通过反馈而使得工作更加安全和可控.而反馈的重要性在大型复杂系统中显现的更加重要,在故障出现最初端倪的时候就能检测到的能力对于一个 ...
DevOps企业实践指南(5): 第三条原则：文化
第一条原则体现了价值流的从左向右的流动,第二条原则是快速和日常的行为带来的从优向左的反馈.第三条原则聚焦于创造一个持续学习和持续实践的企业文化.而这些原则使得组织中的成员能够不断地积累知识和经验,而这 ...
DevOps企业实践指南(8): 安全机制
DevOps落地实践中,安全机制应该如何保证,这篇文章从当前安全状况调查解读开始,同时介绍了DevOps落地实践时应该遵循的原则. 安全问题现状 Kaspersky Lab对26个国家超过5500公司 ...
DevOps企业实践指南(1):DevOps能为我们带来什么
帮助盈利/提升文化/加速效率是DevOps实践的三大目标,上世纪八十年代在制造业领域展开的那场如火如荼的精益实践的变革还历历在目,而DevOps在软件领域将要或者已经掀起的风浪也是如出一辙. Dev+ ...
devops实践指南_开发DevOps的实用指南：减少八卦的步骤
devops实践指南我的一个软件开发的朋友最近问我,如果我可以告诉他,他可以做什么亲自来鼓励更多的合作与理解的工作环境-一个与更一致建议从未来的社区的DevOps . 我们之间的对话很长,他的情 ...
代码优化 5 大原则，第一条就是别优化了！！！
"让这代码跑得快一点!!"--我碰到的第一件代码优化任务就是这么开始的.那个项目是一个巨大的 SAP 云平台应用程序,总共含有超过 3 万行的代码. 整个 App 加载数据的过程非 ...
深入分析游戏设计的8条原则
原文链接:http://gamerboom.com/archives/78680 深入分析游戏设计的8条原则发布时间:2013-11-11 16:33:03 Tags: 反馈, 奖励, 平衡, 流 ...
阿里巴巴DevOps实践指南 | 为什么DevOps的必然趋势是BizDevOps？
简介:从精益思想出发,我们可以看到DevOps的必然发展方向,那就是向业务侧延伸.业务是产品开发和运维的源头,完整的价值流必须从源头开始.这不是预测,而是正在发生的事实编者按:本文源自阿里云云效团队 ...
重磅发布！阿里云云效《阿里巴巴DevOps实践指南》
简介:6月23日,在2021阿里巴巴研发效能峰会上,由阿里云云效团队20位专家共同撰写的<阿里巴巴DevOps实践指南>(以下简称指南)正式对外发布.本指南是阿里云云效团队对过去十年阿里巴 ...

DevOps企业实践指南(3): 第一条原则：流动

可视