DevOps受到了很多业务人士的热烈欢迎，大家的引述也不过是三言两语，真正理解的人寥寥无几。更多的是简单的说“研发团队”和“运维团队”之间的转换。现在大家的注意力已经从最初的开发逐渐转移到狭义的DevOps这个概念或者方法论上，尤其是创业公司或者中小企业纷纷效仿，逐渐觉得这个概念很好，取代了大规模自动化开发。发展了一些人力，短期见效很快，然后开始量化。但是当更高的业务端做大了，就会发现财力（新技术的财力、新角色的财力、工具采购的财力等）支撑不住了，他们又开始抱怨了。当然，土豪除外。前段时间，IBM收购了DevOp（开发与运营合作）解决方案提供商UrbanCode。如果从狭义的DevOps来定义UrbanCode的领域，它其实是全球No.1。去年1月还收购了Greenhat，在测试领域形成了对其DevOP理念的支撑；并在去年5月收购了Tealeaf，在反馈领域强化了这一理念。那么这一系列收购，IBM的真正目的是什么？小编认为，IBM真正的目的是加速DevOps的落地，降低开发过程的成本，将开发测试打通到运维的发布端，稳定自己在软件行业的竞争力。这时候问题就来了，中小企业和创业公司没有这么大的资金支持怎么办？其实很多人对DevOps的理解是不一样的。根据小编的理解，以及前段时间与IBM大中华区技术总监孙昕的DevOps交流总结，给大家罗列一二三。如果您有不同的看法，欢迎一起讨论。为什么DevOps盛行？我们必须从软件工程开始。从早期软件工程的独立性来看，当时的软件实际上是一个人独立开发的，从需求到开发再到测试，都是一个人完成的。所以当时的软件非常简单，功能单一，一个人就可以搞定。当软件工程从20世纪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的开发中需要实现哪些东西。其实小编认为新的题目都有一个共同的特点，找到解决方案后发展会越来越快。以下是三个共性：1.标准流程的统一回归到上述概念。说到应用生命周期管理，其实是一个点对点的过程。那么在这个过程的不同阶段采用什么方法，就需要建立一套标准的过程规范。这就需要国内外土豪共同规划一个行业标准。2.统一工具使用简单来说，当一个庞大的团队分布在世界各地时，你需要进行沟通和协调。你的第一反应是必须依赖工具。你必须花很多钱去买工具，不管是用Cloud技术，还是自动化部署和自动化发布，都是靠工具搭建的桥梁来完成的。3、公司文化我们都知道，如果一个公司有意向的技术出现，当你需要合并其中一个部门的时候，那么他们之间就会有很大的差距。这些差距可能会导致公司文化、工作习惯和某些角色的变化。如何让他们慢慢融合在一起，形成一条业务线，也不是一件容易的事。总而言之，不改变企业文化就不要谈DevOps。因此，三者之间的依赖关系决定了企业实现DevOps成败的关键。理解DevOps的实现是本文讲到实现的重点，但是小编了解的很少，所以这里多借用孙鑫的话来表达。一个新兴技术或方法的实现，其实我们不能狭义地看待它。广义的才是它的真实意图，也是最有说服力的。从狭义上讲，DevOps已经落地。从广义上讲，DevOps仍处于起步阶段。孙鑫认为，现在的实施主要集中在开发和运维本身两个部分。事实上，很多公司已经做到了。当然，这只能说是市场的成熟。在国外，尤其是在美国的很多地方，其实有很多大的应用案例，但是在中国，孙鑫说，根据他的观察，尤其是在国内的开发领域，我们往往是2-4年后相对于其它的。时间。所以这就造成了外国在练，国内谈的局面。如果你想真正实施它，你需要认识到：要按时交付软件产品和服务，开发和运营必须紧密合作。只有这样，公司的业务才能更快、更安全、更准确地得到推广。这就是DevOps流程。愿景：最后总结一下DevOps其实不好说，说说它的愿景。我们之所以能看到软件工程的未来，是因为DevOps其实是一个软件从事下一代产业发展的未来。那么所有软件驱动的创新，未来都是软件大爆发的时代。同时，DevOps也将是解决当代大数据的移动互联网和云计算转型的关键，将带动诸多创新改变人类生活。
