帮助盈利/提升文化/加速效率是DevOps实践的三大目标，上世纪八十年代在制造业领域展开的那场如火如荼的精益实践的变革还历历在目，而DevOps在软件领域将要或者已经掀起的风浪也是如出一辙。

Dev+Ops = /h1>

传统的Dev和Ops之间是割裂的状态，如果Dev和Ops一起形成了DevOps的方式后将会怎样
产品负责人/开发/测试/运维/信息安全等相互之间不再只是相互帮助信息共享，而是作为一个整体保证整个组织的目标实现。他们通过快速的对应，迅速地部署，实现了一流的稳定性/可靠性/安全性的系统服务。
在这里，跨职能的团队的合作并不仅仅是为了实现用户要求的功能，他们保障的是：快速的对应在整个价值流中不会带来对内或者对外的混乱和困扰。

理想状况

测试/运维/信息安全等人员会一起工作降低摩擦而使得开发人员更有效率。通过给测试/运维/信息安全人员提供自动化的自助服务，过去那些必须各个团队的骨干在一起才能解决的问题通过这些工具和平台来实现，在每日的工作中，各个团队彼此之间倚赖性大大降低，这种情况下极大地提升了效率。
这使得一个小型的团队也能够快速独立的完成开发/测试/发布，将开发快速/安全/可靠地为客户做价值的转化。这使得组织能够最大化开发者的生产效率，提升员工满意度，在市场竞争中脱颖而出。这些是DevOps所带来的结果。

现实情况

而在更多的现实世界中，不存在一个整体，到处是割裂的碎片。
开发和测试是水火不容的，仿佛双方都是为了证明愚蠢的是对方而存在。
测试和信息安全行为的结合只是在项目的结束才会引入，一般都已经太晚基本上是走个过场，或者大体解决面上的问题。
留给我们很多手工去处理的余地，以及这些不稳定性所带来的各种副作用。不仅仅是交付时间变长，更多的是这些工作的质量往往是不可控的，因为在这种情况下，现实情况已经成为最终出场救火队员必须担负这些割裂所能带来的如同大厦将倾的趋势，在现实的世界中这些救火队员不断的扮演奇迹，但是也有很多很多的失败。成功的救火往往也能留下各种隐患，潜在以及时而出现的由此引起的问题给项目带来很大的影响，而且无法避免地影响到顾客和业绩。最终的结果就是，项目在短期目标上的失败，整个组织对IT的各种不满，以及由此带来的预算收紧，同时众多面对各种变更和不可知的质量部署的郁闷和无助的运维人员。

解决方法

怎么办要改变的是工作的方式，DevOps给我们指明了一条可行之路。

制造业的变革

为了更好的理解DevOps的变革，让我们把目光投射到上世纪八十年代制造业的变革上。通过践行精益原则，制造业组织成功地极其显著地提升了生产效率，降低了交付时间，提高了产品质量以及客户满意度，成功的企业在残酷的市场中赢得了一席之地。
在这场改革开始之前，制造行业平均交付时间为6周，而且只有少于70%的订单能够按时交付。而到2005年，随着精益实践的广泛推行，平均交付时间已经少于三周，而且95%的订单能够按时交付。那些没能跟上的组织失去了市场份额，他们之中的很多最终被淘汰出局。

软件行业的变革

总结

DevOps不是橱窗里面的展品，也不是旧酒装新瓶的噱头。应该像上个世纪八十年代精益实践浪潮的优秀企业那样，认真思考组织的不足，努力修炼内功，踏踏实实地改进，像Google/Amazon/Netflix那样实践，在新的改革中抓住机会。

Referrence

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8600 人正在系统学习中

来源：淼叔