警惕文化空谈的陷阱,落地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地区的市场推广与技术合作工作。

原文发布于微信公众号 - EAWorld(eaworld)

原文发表时间:2017-08-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏华章科技

在腾讯2年,我学会了这15条内容运营干货

两年前,我从人大硕士毕业,误打误撞进了移动互联网行业。来腾讯以后,我所在的部门是手机腾讯网,当时我对门户兴趣不大,得知我们小组有做手机QQ浏览器push运营业务...

1371
来自专栏VRPinea

语音控制化繁为简,让你在VR中的交互方式更自然

6118
来自专栏姬小光

你为什么还没有博客?

最近两年,博客这个词已经很少有人提及了,基本上已经被微博,公众号等淹没。有人说,博客已死,然而我并不这么认为。

1043
来自专栏养码场

一年拦截垃圾达400亿条? | 网易云创沙龙解密如何利用互联网业务赋能解决企业数字化转型

分享讲师分别为网易云资深解决方案架构师张亮、网易大数据的资深数据产品专家王文开、网易云安全技术总监高民、网易云企业服务部首席架构师李鲁。

2112
来自专栏云加头条

重磅发布:腾讯云大数据与AI新品「数智方略2.0」

在云+未来峰会 AI与大数据专场,腾讯云一口气发布了EMR(弹性MapReduce)、文智公众趋势分析、智能推荐、大数据可视交互系统(RayData)、DI-X...

1.4K0
来自专栏悦思悦读

大型IT企业内部数据分析的现状和发展趋势

大数据时代,数据已经成为战略资源。掌握前沿科技的大型IT企业在数据的分析和利用上走在了时代的前列。笔者浸淫IT业十余年,近几年专注在数据分析平台研发和数据分析上...

36412
来自专栏ThoughtWorks

打造你自己的技术雷达

Neal Ford ThoughtWorks 20世纪90年代的大部分时间以及21世纪初,我一直都在一家小型培训咨询公司担任CTO。在这份工作开始之初,主流平台...

3494
来自专栏程序员的知识天地

来自10位成功IT人士的23条经验教训

我们是从一个只有3个人其他啥都没有的创业公司逐步成长为一家大型的具备可扩展性,业务操作能力,数据库和产品开发的企业。如果你真心醉心于做企业,那么这就应该成为你的...

1041

值得注意的3个SaaS站点

每隔几个月,我就需要谈谈当时流行在线的最佳SaaS网站。不像许多最佳列表,SaaS日新月异,所以这不是一个半年或一年份的名单,这个必须频繁发布。 SaaS是一个...

2188
来自专栏EAWorld

在微服务世界度量DevOps,你准备好了吗?

1.无度量不DevOps DevOps的推广打破了开发,运维之间的壁垒。全员以产品交付为目标,提高效率,完成业务。久而久之消费者就会形成一个潜意识就是:买了这个...

3057

扫码关注云+社区

领取腾讯云代金券