DevOps（开发运营）运动在修补残缺的部署流程方面取得很大进步。从表面上看，为开发者提供的解决方案是更多地站在运营者的角度去思考，反之亦然。然而，这种表象级的想法也只能到这里了。需要具体的、可操作的步骤去克服技术方面的欠债，向Amazon（顺便说一下，今年5月该公司的平均部署时间间隔为11.6秒）之类的应用开发组织的效能靠近。

在Agile 2013上，演讲者Gene Kim展示了一个在应用开发和部署流程中做出可操作改变的可行框架。Kim是Tripwire的创始人，也是该公司2010年夏以前的CEO。现在，3年之后，Kim出版了一本小说，名字叫做《凤凰项目》，书中解释了如何给死板的开发组织带来灵活性。这本小说生动描述了Kim对DevOps现象14年的研究当中学到的3个主要概念。

根据Kim的说法，相对于没有开始DevOps计划的组织，那些参与DevOps计划达到或超过12个月的组织展现出了显著的效能提升。Kim说高绩效的DevOps团队会更加敏捷（部署频率高30倍，周期时间快8000倍）且更可靠（成功变更次数最多可增加1倍，响应时间仅是平均响应时间的一小部分）。

组建一支高绩效的DevOps团队需要3个要素，Kim说。在其最新的小说中，Kim将每一个要素阐述为“3种方法”之一，由他的神秘大师展现给领导者。这三种方法可归结为过程流、反馈及持续学习。

方法1：流

在构建过程流中，Kim概括了5项主要规则。首先，理解工作流。如果缺乏理解，任何变更都会有随机效应。第2和第3，永远都要增加流，永远不要把缺陷传给下游。如果你把生命周期管理流程想象为一条河流，就很容易看清为了修正而逆流回溯项目有多困难，尤其是在过程迅速流转的时候。

第4，永远都不要让本地优化导致到全局的退化。在内部开发组织各自为政的大型组织当中这是很棘手的。每一个团队都希望自己的部分成为演出的明星。然而，让一切保持平衡对于整个系统来说好处要大得多。最后第5点，对整个系统要有深刻的理解。这一点跟第1点相呼应。你必须理解每一部分的细微差别，知道它们是如何相互适应的，这样才能维持一切平衡有序。

从这些规则当中，Kim发现了一个改进开发时间的重大方法。其诀窍是找出流程瓶颈然后打破它。Kim引用了Eliyahu Goldratt《目标（The Goal）》里面自己喜欢的台词，说的是“任何地方的变化都能带来改进，但是在瓶颈之处那只是一种幻觉。”也就是说，整个部署流程链的速度取决于最慢的环节。

Kim说大型软件组织有6个领域是最有可能成为瓶颈的：环境创建、代码部署、设置以及运行测试、过度紧密的架构、开发及产品经理。Kim说，根据2012年Puppet Labs的一项调查，组织当中两个最常见的展现出一致速度和品质的链环是基础设施版本控制（89%采用版本控制）及自动部署流程（82%对部署进行自动化）。

方法2：持续反馈

第2种办法是反馈，也有4条重要规则。首先，理解并响应所有客户的需求，包括内部和外部的。其次，缩短并放大所有的反馈环。Kim说这条规则效仿流量丰田精益生产线，后者让任何一名员工在看到有缺陷的情况下均可停止生产线。第3，从源头建立品质。意思是说积极地将品质注入到一切东西上。最后是第4点，在需要的地方创建并嵌入知识。

Kim建议把脆弱的服务返还给开发者，让他们对服务的稳定性负责。为了说明为什么这么做有效，Kim引用了BrowserMob CEO Patrick Lightbody的话，他发现“凌晨2点叫醒开发者时缺陷被修复的时间就会前所未有的快，”当然，他们并不是为了激怒开发者而在半夜叫醒他们。除非代码出错开发者才要凌晨2点起床。这当然会激发开发者写出高质量的代码。“这可以归结为有难同当。”Kim解释说。

Kim还建议为各种指标设立简单的自动化监视器。比方说，开发者也许可以建立简单的增量计数器来跟踪成功及失败登录尝试。这一监控可为团队提供验证服务运作情况的反馈。甚至还可以找出恶意活动。

方法3：持续学习

Kim的第3种方法是培育一种鼓励实验（哪怕要冒风险）、奖励成功、从失败中学习以及认识到重复是精通的先决条件的文化。Kim说成功组织形成了一种靠着能令自己在危险中生存的习惯不断向危险区推进的文化。

Kim援引了Netflix云架构师Adrian Cockcroft的说法。“痛苦的事情做得越多你就能让它带来的痛苦感觉越少，”Cockcroft建议说。他说自己的开发者不会回避痛苦的任务，因为他们知道这可以让大家的部署流程流畅的多。Cockcroft的方法在2011年4月得到验证，当时EC2中断导致Reddit和Quora服务停止，但是并未严重影响到Netflix—即便Netflix也一样跟EC2捆绑在一起。

Cockcroft的团队开发了一种名为Chaos Monkey的测试工具。Chaos Monkey的目的是随机禁用一些服务以便测试其他所有服务的独立性。当然这是个多少有点极端的例子，但是的确说明了尽早失败及经常失败的价值。这么做让开发组织成长，一旦应用进入生产阶段，可处置任何有可能出问题的情况。

为了坚持这3种方法，Kim提出了3点建议。首先，处处都要强制要求一致性—代码本身如此，环境和配置也一样。其次，在代码中使用Assert（断言）语句找出配置错误并执行最佳实践。最后，采用自动化持续集成测试的同时也要利用静态代码分析。