DevOps通常作为下面这三个方式而为人所熟知，而在我眼里我是把它们看成是一条高速公路上的三条车道。你从第一条车道开始，然后加速进入到第二条车道，最终在第三车道上高速行驶。
车道1 – 系统级别的整体效率考量是最主要的关注点，这超过对系统中任何一个单独个体元素的考虑
车道2 – 确保能提供持续不断的反馈循环，且这些反馈不被忽视。
车道3 – 持续的学习和吸取经验，不停的进步，快速的失败。
车道1 – 获取速度
要采纳DevOps的原则，理解整个运作系统的重要性并对工作事项进行合适的优先级排序是组织首先要学的事情。在整个价值流中不能允许任何人产生瓶颈并降低整个工作流程。
确保工作流程的不可中断是身处流程中的所有成员的终极目标。无论一个成员或者团队的角色是什么，他们都必须力图对整个系统进行深入的理解。这种思维方式对质量会有着直接的影响，因为缺陷永远不会被下放到“下游“中，这样做的话将会导致瓶颈的产生。
确保整个工作流程不会被瓶颈堵塞住还不够。一个高产的组织应该时常考虑该如何提升整个工作流程。有很多方法论可以做到这一点，你不妨去看下“约束理论”，“六西格玛”，精益，或者丰田生产系统。
DevOps原则不关心你身处哪个团队，你是否是系统架构师，DBA，QA，或者是网络管理员。相同的规则覆盖所有的成员，每个成员都应该遵循两个简单的原则：
保持系统运作流程不可中断
随时提升和优化工作流程
车道2 – 换挡加速
不可中断的系统流程是定向的，且预期是从开发流向运维。在一个理想的世界中，这就意味着快速的开发出高质量的软件，部署，并为客户提供价值。
但是，DevOps并非乌托邦式的理想国。如果单向的交付方式是可行的话，我们的瀑布模式早就能胜任了。评估可交付产品和整个流程中的交流对确保质量是至关重要的。这里首个必须实现的”面向上游”的交流通道是从Ops到Dev。
我们独自意淫是件非常容易的事情，但是获取别人的反馈和提供反馈给别人才是探究事实真相的正确方法。下游的每一步(反馈)都必须紧跟着有一个上游的确定。
你如何建立反馈循环机制并不重要。你可以邀请开发人员加入技术支持团队的会议，或者将网络管理员放到Sprint计划会议中去。一旦你的反馈机制就绪，反馈能够被接收并被处理，你就已经可以说是走到了DevOps高速车道上来了。
车道3 – 飞速前进
DevOps这条快速车道并不适合意志脆弱的人。为了进入这条车道，你的组织必须要足够的成熟。这里充满了冒险和对失败教训的学习，不断的尝试，并认同屡败屡战和不断的实践是走向成功这条康庄大道的前提条件。在这里你应该会经常听到”套路“这个词，这是有原因的。不断的训练和重复所以能培养出大师，是因为其让复杂的动作常规化。
但是在你要将这些复杂的动作连接起来之前，你很有必要先去掌握好每一个单独步骤。
“适合大师的动作并不适合新手，脱胎换骨之前你必须先要明白道的真谛。“
DevOps的第三个方式/快速车道包括每天分配时间来持续的进行试验，时常的奖励敢于冒险的团队，并将缺陷特意引入到运作系统上来以增加系统的抗击打能力。
为了确保你的组织能够消化好这些方法，你必须在每个团队之间建立好频繁的反馈循环，同时需要确保所有的瓶颈都能够及时的被清理掉，并确保整个系统的运作流程是不可中断的。
实施好这些措施可以让你的组织时刻保持警惕，并能够快速且高效的应对挑战。
概要 – DevOps清单
下面是一张你可以用来检验你的组织对DevOps的应用情况的清单。当然你也可以在文章评论后面给出你的观点。
开发团队和运维团队之间没有障碍。两者皆是DevOps统一流程的一部分。
从一个团队流到另一个团队的工作都能够得到高质量的验证
工作没有堆积，所有的瓶颈都已经被处理好。
开发团队没有占用运维团队的时间，因为部署和维护都是处于同一个时间盒里面的。
开发团队不会在周五下午5点后把代码交付进行部署，剩下运维团队周末加班加点来给他们擦屁股
开发环境标准化，运维人员可以很容易將之扩展并进行部署
开发团队可以找到合适的方式交付新版本，且运维团队可以轻易的进行部署。
每个团队之间的通信线路都很明确
所有的团队成员都有时间去为改善系统进行试验和实践