DevOps的出现受到众多的企业人士热捧，每个人的引用也只是只言片语，真正了解的人极少。更多的只是单纯从“研发团队”与“运维团队”之间的转变谈起。现在大家的关注慢慢从最开始的开发转移到了狭义当中来讲DevOps的概念或者方法论，特别是创业中的企业或者中小型企业纷纷效仿，慢慢的觉得这个概念很好，从自动化代替了大部分开发人力时，短期见效很快，然后开始量化。但是当更高的业务端去扩展的时候就会发现财力（新技术财力，新角色财力，工具购买财力等等）支撑不住，又开始去抱怨。当然，土豪公司除外。
在前段时间，IBM收购DevOp(开发与运营合作)解决方案提供商UrbanCode，如果从狭义的DevOps去定义UrbanCode这个领域，它实际上就是全球的NO.1，而在去年1月也收购了Greenhat公司，对其在测试领域中的DevOP概念形成了支持；再去年5月收购了Tealeaf公司，则是在反馈领域中加强了这种概念。那么这一连串的收购，IBM真正的目的是为了什么？小编认为，IBM真正的目的就是为了加快DevOps的落地，减少开发流程费用，把开发测试打通到运维发布端，稳固自己在软件行业的竞争力。
这时候问题来了，中小企业和创业公司没有那么大的财力支撑怎么办？其实对于DevOps很多人理解不同，根据小编的理解以及对前段时间与IBM 大中华区技术总监 孙昕对DevOps交流的总结，给大家列出一二三，如有不同观点欢迎共同探讨。
DevOps为什么盛行
这个我们得从软件工程开始说起，从软件工程初期发展的独立主义，那时候的软件其实就是一个人独立开发，从需求到开发到测试，都一个人完成。因此那时候的软件很简单，功能单一，所以一个人完全可以。当从90年代开始强调了软件工程化至今完全进化成为一个产业链，软件工程应是由最早的需求、架构设计、开发、测试、发布一个完整的过程进化的时候，这时孙昕谈到了一个概念， 那就是ALM。如何去理解这个ALM？就是把你的软件当成一个应用，这个应用就像人一样，有出生到成熟到死亡。官方专业的说法就是应用程序生命周期管理。但是时代在进步，我们的需求越来越大，软件的生产链条还要扩展，所以就是这次谈的DevOps这个概念。
为什么这么说？
在任何公司里，开发一个软件最终都是为了赚到钱，于是它有了大的商业规划，产品的需求，才有软件的开发这样的一个流程。那么软件再往上端走就直接到业务层，而软件的下一端理所当然是运维了。为什么这么说？如果在金融业，电信业，一出问题不及时解决就是个灾难。所以软件往下走一定是运维，不断产生缺陷不断及时修复，所以现在的软件工程链条变得非常长，这就是DevOps这么个概念。
DevOps为什么这几年才开始提提及？用孙昕在IT客上的话说，就是有一个重要的技术瓶颈是这几年才突破的，在前几年一直在谈的一个概念叫JAZZ，翻译过来就是爵士乐，意思是需要协同起来才能奏出非常好的爵士乐。JAZZ的出现就是为了让软件真正的与底层全部打穿数据，让数据在说话。在之前还没有这个国际化标准的时候，但是今天我们能够看到了希望。
JAZZ的出现对整个行业包括软件，从业者等都会有着一定的改变。这个改变就是把程序员或者测试人员一直一来做的复杂且重复性的工作完全脱离出来，用更多的时间去做更有创造性的工作。小编记得孙昕说过这么一句话，如果没有JAZZ提及出来，就不会有今天的DevOps真正的出现。（详细请关注DevOps专题）
说到这里用一句话来感慨一下：软件从业者本身就是一个艺术家，不停地用创意改变着世界。
“土豪”的本质
如果从上面来看你对DevOps的概念有了了解，那么DevOps到底是用来解决什么问题呢？是解决公司的技术问题还是业务问题？
刚刚也说了，软件的上一端是业务端，任何一家企业开发软件，其实目的就是为了赚到钱。虽然说技术也是DevOps中的关键部分，但是从DevOps本质来说就是个就是个业务问题。不解决业务如何赚钱？光靠技术当然是不行的。
那么这个业务的流程是怎么组成的呢？从DevOps的活动组成部分中分为两种，第一是技术的驱动，第二是人为的驱动。比如说开发者，QA，架构，发布，安全，运维，其实都在这一流程中发挥了自己的作用。
无论是在传统行业或者软件研发这条工具生产线上做一些业务的规划，我们叫做产品线工程（PRE），在这些产品线本身其实就受到很好的工程化管理。从规划到实现，业务这部分已经占据了非常重要的地位。其实大家可以理解为项目管理，企业架构，数据架构，或者流程整合等等，做好哪些决策，投入到哪些大的项目中，这些都跟DevOps相关，实际上这些规划好了以后需求才会变成业务往前推，这样才能更好的获取你的需求是来自于支撑你的业务目标，对市场的压力做出快速，高效，经济，可靠的变化能力。小编认为，如果把业务抛开去谈DevOps，其实毫无意义。
也许有人会说，既然DevOps是业务流程的，为什么还要管它叫“DevOps”？
在早期，DevOps的出现就是为了解决开发与运维之间的问题，没有指明DevOps到底真是的范围，即使是解决问题到底多大，工程链条到底有多长。但是经过了在不断的实践过程中，大多的实践者就认识到面对市场压力的业务问题不解决，再怎么实践DevOps都没法真正意义上去解决企业上的问题。
所以要解决业务问题，我们就要从开发与运维两者之间的文化开始说起，这两者从诞生以来到现在已经存在着很大的冲突与脱节，每个企业的组织结构不同也会影响他们之间划分程度。要解决两者之间的脱节，所以你现在看到的谈DevOps最多的就是如何改善部署问题上，这是一种合理的选择。但是如果你说DevOps的出现就是为了改善部署问题那就是误导别人了。
#p#
发掘“土豪”的共性
现在我们来谈谈DevOps的发展需要落实哪些事情，其实小编认为，新的话题出现都有一个共性特点，找到解决方案发展就越来越快。下面说3个共性：
1.标准流程统一化
回归到上面概念讲到应用程序生命周期管理，其实就是一个点对点的过程，那么在这个过程中不同阶段采取什么样的方法，这都需要建立起一套标准流程规范。这就得是国内外的土豪厂商们联合起来规划一个行业标准。
2.统一的工具使用
简单的说，一个大的团队，分布到世界各地的时候要做沟通和协调，你的第一反应是必须依赖工具，你必须花大量的金钱去购买工具，无论是利用云的技术，或者自动化部署，自动化发布，这都要依赖工具建立起来的桥梁下完成。
3.公司文化
我们都知道如果企业有心的技术出现，当你需要把其中某个部门合并了，那么他们之间就会造成很大的隔阂。这些隔阂可能会造成公司文化，工作习惯的改变，再者是一些角色的改变。如何让他们慢慢的整合在一起形成一条业务线，这也是一件不易的事。总而言之，不改变企业文化，就别谈DevOps。
所以，三者的依赖关系决定着企业实现DevOps的成败关键。
认识DevOps的落地
说到落地才是本文的关键，但小编的理解甚少，所以这里更多的借用孙昕的话来表达。
一个新兴技术或者方法的落地，其实我们不能用狭义的眼光去看它，广义才是它真正的本意，也是最有说服力的。
从狭义方面去讲的话其实DevOps已经落地，如果从广义来讲，目前DevOps还只是雏形。孙昕认为，落地现在主要是聚焦在开发和运维本身现在两部分，其实现在就已经有非常多的企业做到了，当然这只能说是市场的成熟度。在国外，特别是美国很多地方其实都已经有很多大的应用案例，但是在国内，据孙昕所说，据他观察，尤其是在国内的开发领域，我们经常比别人晚2-4年的时间。所以这就造成了为什么国外在实践，国内开始谈的局面。
想真正的落地你就要认识到：按时交付软件产品和服务，开发和运营工作必须紧密合作，只有才能更快，更安全，更准确的推进公司的业务，这才是DevOps的过程。
愿景：
最后总结的话其实对于DevOps也不好说，我们就来说说对它的愿景吧。
我们之所以能看到软件工程的将来，DevOps实际上就是软件从事于行业下一代发展的一个未来。那么所有以软件为驱动的创新将来是一个软件爆炸的时代，同时DevOps也将会是解决当代大数据上的移动互联，云计算转型的关键，将会更加驱动很多创新来改变人类的生活。
