警惕文化空谈的陷阱，落地DevOps工具才是关键
警惕文化空谈的陷阱，落地DevOps工具才是关键
恍惚间，DevOps已经被讨论十年了
“如果系统是集中式的、环境是同质化的，从开发环境向生产环境推送程序变化的过程非常简单，不需要太多的自动化；但是今天的应用需要7×24小时运行、采用分布式架构、部署到多种环境，变更过程变得愈加复杂、难以自动化……不论在大型组织还是小型组织，施行DevOps在技术上都非常具有挑战性。”
上面这段文字如果放在今天，那只是段关于DevOps的、稀松平常的讨论，但是如果它写于十年前，各位读者会不会感到有一些惊讶？
这段文字写于2007年8月的下旬，很快就距今整十年了，这是我所知道的业内最早的关于DevOps的系统性讨论，我在整理收藏夹的时候偶然发现了它，这让我突然意识到：DevOps已经十年了。
可是，为什么雷声大雨点小？
博客网站dev2ops.org（据说是devops.org被抢注了，所以他们只能加个2，而devops.org至今仍是个空域名）的文章“What makes dev2ops so hard anyway?” 文中还罗列了阻碍DevOps施行的几个因素：
- 变更结果的可靠性和可预见性
- 不同类型的变更（数据、代码、配置、内容、平台等）对系统造成的不同影响未被充分评估
- 对分布式系统各部分的变更非常难以协调
- 开发与运维的组织边界难以界定
这几个因素在今天依然阻碍着DevOps的施行。由于滚动更新、金丝雀测试等方法和Kubernetes等系统的流行，前三个阻碍有了一定的改善，但是由于方法和系统仅仅提供了操作原语，所以带来的改善十分有限。而第四个阻碍在很多组织中依然如故。
而且，这四个因素远远不是全部，我想每个正在实践DevOps的读者在读到这里的时候，头脑中都会闪现出其他的一些因素，例如老系统的云化和测试自动化需要很大的投入、DevOps的工具链过于繁杂等。所以，DevOps的施行依旧非常的困难。
说到这里，作者还很应景的补充了一句：“尽管如此，DevOps最终仍然可以施行，办法很简单，让最强的技术人员通宵加班即可。”这句话简直是神补刀，前段时间我刚好支持了一个老项目上线，那感觉简直就像是误入了一个野蛮的原始部落，这使我不禁反思：十年来，DevOps究竟改变了什么？
公认首个DevOps成功案例，
Flickr的每天10+次部署？
2007年，比利时独立IT咨询师Patrick Debois参与了一个政府部门的数据中心迁移项目。在这个项目中Patrick需要交替的和开发团队还有运维团队一起工作：第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，两种工作的切换令他十分恼火。
正是因为这段经历，Patrick充分体会到了开发团队和运维团队的工作方式和思维方式存在巨大差异：他们简直是活在两个不同的世界之中，两个团队的工作之间到处都是冲突。Patrick Debois开始思索如何弥补开发团队和运维团队之间的鸿沟，这些思考的结果就是DevOps的雏形。
两年之后的2009年，John Allspaw和Paul Hammond在Velocity 大会上发表了名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，演讲的PPT有五十多兆，里面充满了来自Flickr的高质量的图片，DevOps也由此正式走入公众视野。演讲中有两个想法在我看来非常重要：
- 运维工作的目的并不是保持系统稳定，而是促进业务敏捷；如此，开发和运维工作的目的就统一起来。
- 开发团队和运维团队为了促进业务敏捷，应该打造一系列支持快速发布软件的工具和文化。其中工具包括：自动化基础架构、共享的版本控制系统、持续集成、持续部署、共享的度量和消息机器人。
近年来，自动化基础架构、共享的版本控制系统、持续集成这三种工具已经普及，而持续部署、共享的度量、消息机器人这三种工具应用的还不是很多，也没有很好的标准化，相关的开源项目还处于战国时期，不过按照目前这个趋势，想必很快也会尘埃落定。在这三种工具也得到了普及之后，前文罗列的阻碍因素会得到相当大的改善，那么，DevOps能够随之得到普及吗？
普及DevOps，工具才是关键
- 警惕空谈陷阱，文化转变不一定是必要条件
很多人认为工具的普及和DevOps的普及是两码事，因为DevOps不仅仅是一系列的工具，更是一种文化；甚至很多人认为文化要比工具重要的多。Cloud Technology Partners公司的首席架构师Mike Kavis曾说：“DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作以便于更快地构建可靠性更高、质量更好的软件的运动。”
但是恕我直言，我非常反对这种说法，众所周知，一个组织在成型之后再对组织文化进行根本性的转变，难度之大超乎想象，如果把文化转变作为施行DevOps的必要条件，那无异于把DevOps送上了绝路。
在我看来，DevOps更应该是一系列工具加上如何使用这些工具的知识，鉴于任何工具都需要相应的使用知识，所以简单的说，DevOps就是一系列工具。
让我们回顾一下，持续集成和Scrum都已经提出了有二十余年之久，易于工具化的持续集成在近几年已经普及，而不易于工具化的Scrum却没有，在很多团队里仅仅是站会都会沦为一种形式。所以，你应该明白我的意思：如果DevOps更多的是一种文化，那么它的普及将遥遥无期。或者说即使DevOps是一种文化，那也需要有工具来支撑这种文化，否则极易落入空谈。
所以，DevOps应该像个生产软件的流水线，开发人员、测试人员和运维人员在补充了必要的知识之后，就能在这个流水线上以DevOps的方式生产软件。
- 这是一种软件开发模式和方法论
还有人认为DevOps是一种软件开发模式和方法论，从瀑布模式到敏捷模式、再到DevOps，一脉相承，这个观点我基本认同。我们目前在做支撑DevOps的产品，有次我问我们同事：“如果DevOps也是一种软件开发模式或者软件工程方法论，那么它如何能成为一种产品呢？之前的瀑布、迭代、螺旋和敏捷又为何没有成为一种产品？”同事答到：“因为DevOps吹的大。”
我不认为他是在戏谑，因为拉里·佩奇曾经说过：“只要你想的足够大，那就很难全盘皆输，即使是失败，其中往往也会隐藏着珍宝。”吹之前当然需要想，所以吹的大也就包含想的大，所以我想，即使多年以后，DevOps潮水退去，也会留下一些由DevOps工具链演化成的优秀产品。而且应该有很多人还记得， 统一软件开发过程，即RUP（Rational Unified Process），就是一种和产品相辅相成的软件开发模式和方法论，其支撑产品Rational几乎是上一时代最为成功的软件开发套件。虽然Rational很贵，很多人都没有用过，RUP也是一种重量级方法，但是很多组织都在或多或少的应用RUP的某些子集，它的迭代开发、可视化建模、需求管理和变更控制在今天依然有非常好的指导性意义。
我们应该从RUP和Rational的联合运作中学到一些东西，并把它应用到DevOps的推广和支撑DevOps的产品的开发中，那么，DevOps会成为覆盖更广、更易用和更普及的全民RUP吗？随着DevOps会诞生一些像Rational一样成功的产品吗？既然用户有需求，历史上也有类似模式的成功案例，那么就值得我们这些工具类的软件企业努力去做。
- 继续生长和完善的DevOps工具链
另外还有一点就是，虽然很多人在诟病Java，尤其是诟病Java EE，但是很多其他语言的开发者非常羡慕Java完善的工具链和周边， 有些开发语言甚至连个完善好用的打包工具都没有。DevOps刚好可以提供这种补充，尤其是在微服务模式下，这种补充变得史无前例的重要，Docker、Kubernetes、Istio、Namerd、Linkerd这些开源项目，对于其他语言就像Java的应用服务器和Spring Cloud，当然它们同样也可以给Java使用。它们都是DevOps工具链和产品的必备环节和组件。这是历史上第一有望将所有开发语言纳入到同一个全流程的管理框架之中，目标一旦达成，那将是软件工业的一次重大转变。
Mike Kavis在说明DevOps是一种文化的时候，曾提到很多DevOps团队通过编写Chef、Puppet或Ansible脚本来施行DevOps，而Mike Kavis认为大量的专有脚本实际上是增加了系统的浪费，而DevOps提倡的是效率，这些团队的行为并没有体现DevOps的理念。
但是在我看来，这种状况的产生正是因为工具的缺失，如今Docker和Kubernetes在很大程度上提供了标准化的部署环境和流程，让很多用户不必再花大量精力编写专有脚本，还有一个更大的优势就是，Kubernetes可以在让系统达到用户定义的状态之后继续维持这种状态，而Chef、Puppet和Ansible的脚本则不能。
所以，我想说的是，也许DevOps曾经是一种文化，但是正在越来越成为、也必须成为一系列工具，文化的比重逐渐变小，直至成为非常次要的条件，因为只有这样，DevOps才能获得广泛的应用。
写在最后
持续集成在提出了十几年之后才获得广泛应用，而DevOps刚刚十年，虽然DevOps的战线要远长于持续集成，但是让我们保持乐观，也许未来的几年就是DevOps的加速阶段，我们还有几年的时间来打磨支撑DevOps的产品，以帮助客户解决开发和运维的效率问题，帮助客户实现业务敏捷。
十年了，如果你觉得DevOps改变的还不够多，那么DevOps自身首先应该做出改变，那就是由虚无缥缈的文化，变成看得见摸得着的工具。
7月21日，本文作者所在的公司普元从企业敏捷深度需求出发，正式发布了全面的开发运营一体化方案Primeton DevOps 5.0，并已助力万达网络科技集团实现IT精益运营。
关于作者：
宋潇男
普元云计算架构师，Unix和分布式系统专家，网格时代的幸存者，在云计算行业有近十年的研发和市场工作经验，对操作系统、中间件和云平台有深入研究和大型项目经验。曾在华为云计算部门负责产品规划、商业洞察、以及EMEA地区的市场推广与技术合作工作。
