跳转至

02 DevOps的价值:数字化转型时代,DevOps是必选项?

你好,我是石雪峰。今天我们来聊聊DevOps的价值。

前段时间,因为工作的缘故,我参访了一家在国内数一数二的金融企业。在跟他们科技处的同事交流的过程中,有一件事情让我非常吃惊,想跟大家分享一下。

虽然在一般人眼中,这家企业是典型的传统企业,但他们的绩效目标采用的却是OKR模式

我简单介绍一下OKR。OKR也就是目标与关键成果法,是在硅谷互联网公司很流行的绩效制定方法。简单来说,O代表目标,也就是我们要做什么,KR代表关键结果,用于验证我们是否已经达到了目标。

这家金融企业的大老板,也就是科技处的老大,给全体员工制定的众多OKR中,有且只有一条属于愿景指标。说出来你可能不相信,这个愿景指标就是,到今年年底,让DevOps在全行的三个试点项目中成功落地。

而且,这并不是简单的说说而已,如果最终达成了这个愿景指标,所有员工的年终奖将在原有的基础上上浮10%~20%。由此可见,关于实施DevOps,他们是在玩真的了。

全行的核心系统改造都没能成为愿景指标,那为啥DevOps会有如此大的魔力,让大老板都为之着迷,并且成为愿望清单列表中的第一名呢?这就是我今天要跟大家讨论的话题:DevOps的价值以及它对现代企业的意义。

如果要选一个近年来在各大企业战略中曝光率最高的关键词,数字化转型绝对是排名最高的,没有之一。

比如,传统汽车巨头大众公司今年宣布启动全面数字化转型,计划到2023年年底投资约40亿美元,实现管理和生产的数字化。而且,预计到2025年,大众集团的软件研发的比例将从目前的不到10%增长到60%。

为什么软件如此重要?

对于软件从业人员来说,这绝对是令人欢欣鼓舞的事情。同时,这也再一次印证了那句流传已久的名言,每一家公司都将成为软件公司。那么问题来了,在数字化转型时代,为什么软件会如此重要呢?

互联网的普及和移动通讯技术的发展所带来的移动互动网的兴起,深刻地影响了我们每个人的生活方式。

举个最简单的例子,几年前如果我们要办理银行业务,我们首先要找到附近的营业厅,抽空跑过去排号,经过很长时间的等待,才能坐到柜台前,同银行的柜员面对面地完成业务办理。当然这还是在顺利的情况下,如果忘记带证件或者排队人太多,可能还要再跑一次,办事成本相当高。

现在呢,大多数情况下,我们只要掏出手机,打开银行的APP,点击几下屏幕,业务就办好了,完全不用受时间和空间的限制。用户对银行服务的体验直接来源于手机应用本身。如果哪家银行的应用界面很丑,操作还总是出现各种问题,就会直接影响用户对这家银行的印象,甚至会在潜意识里觉得这家银行不靠谱。显然,没有任何一家银行愿意给人留下这样的印象。

所以,软件慢慢从企业内部的支撑系统和成本中心,变成了企业服务的直接载体和利润中心。企业通过软件降低运营成本,提升服务水平,而用户在获得便利的同时,也加强了同企业之间的联系。

这本是一件双赢的事情,可问题是,我们所身处的是一个VUCA的时代,VUCA是指易变性(Volatility)、不确定性(Uncertainty)、复杂性(Complexity)和模糊性(Ambiguity),它代表了这个时代的典型特征。比如共享单车这个行业从冉冉兴起炙手可热,到逐渐归于平静,前后不过短短几年的时间。

企业能快速满足用户的需求,在行业大势之下灵活转身,在跨界打击越发普遍的情况下脱颖而出,已经不仅仅是good to have的能力,而是must have的能力。

可以说,软件交付的效率和质量成了当今企业的核心价值和核心竞争力,所以,任何一家企业,无论是行业巨头还是初创公司,无论是互联网行业还是传统行业,无论是领先者还是颠覆者,都有强烈的意愿去改善自身的软件交付能力,而这恰恰和DevOps的理念和诞生背景不谋而合。这么看来,DevOps能够成为企业愿望清单中的第一名也就不足为奇了吧。

可是,即便软件如此重要,却依然有很多公司在用一种手工作坊的方式开发软件,引用国家智库的某位领导的话来说,“工业革命消灭了绝大多数的手工业群体,却催生了程序员这个现存最大的手工业群体”。这句话看似危言耸听,但这种开发软件的方式的确存在,其中伴随着大量的效率浪费。企业内部的软件开发交付效率已经成了一座值得探索挖掘的金矿,效率经济可能成为新的业绩增长点。

DevOps的价值

那么,实施DevOps带给企业的价值究竟是什么呢?要回答这个问题,我们就不得不提到DevOps业内非常著名的现状调查报告了。

高效的软件交付方式

从2014年至今,这个报告每年都会发布一份,由业内大咖和行业领袖基于科学的分析方法,通过大量的数据分析得出,可以说是业内最具权威性的报告,其中的很多数据和理念都被广为传播。我发现,在这洋洋洒洒大几十页的报告中,被引用频率或者说出镜率最高的,就是DevOps的4个结果指标。

  1. 部署频率:指应用和服务向生产环境部署代码的频率。
  2. 变更前置时间:指代码从提交到成功运行在生产环境的时长。
  3. 服务恢复时间:指线上应用和服务出现故障到恢复运行的时长。
  4. 变更失败率:指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。

每年,这个报告都会基于这4个核心指标统计行业内高效能团队和低效能团队之间的差距。从去年的数据来看,与低效能团队相比,高效能团队的部署频率高了46倍,变更前置时间快了2500多倍,服务恢复时间也快了2600多倍,失败率低了7倍。

我们先不管这份数据是怎么计算出来的,当你第一次看到这个数据的时候,它带给你的冲击是不是很强大呢?用具体的数字形式来呈现企业之间效率的差距,是很有震撼力的。

而世界上最令人“绝望”的事情,就是那些比你优秀的人,实际上比你还要更加努力。当你仔细查看这份报告的时候,你会发现,那些常年被人提及的明星公司,很多都在践行DevOps,甚至很多来源于这些公司的实践案例,都成为了DevOps行业的经典案例。

另一方面,DevOps状态报告中提到的四项结果指标,分别代表了软件交付的两个最重要的方面,也就是交付效率交付质量。而且,从数据结果中,我们还能得到一个惊人的发现,那就是高效能的组织不仅做到了高效率,还实现了高质量,由此可见,鱼与熊掌可以兼得。

可是,这就颠覆了很多人心目中的“慢工出细活”的传统软件开发理念。因为按照传统软件开发的V模式来说,软件开发完成后,需要经过单元测试、集成测试、系统测试和验收测试等层层关卡,以此来保证软件的质量符合预期。但是,对于现代软件开发而言,如此重的流程和管控显然有点跟不上时代的节奏。

我们在不断提高软件交付效率时,往往是以牺牲质量为代价的,结果做得越多,错得越多,从而陷入进退两难的境地。

DevOps却反其道而行之,它试图通过体系化的研发实践导入、软件架构的整体革新、组织管理理念的不断升级和企业文化的影响塑造,来帮助企业改善整个软件交付过程,在实现高吞吐量的同时保证服务的总体稳定性,从而真正实现又快又好的软件交付目标。

激发团队的创造力

我们刚刚谈到的这些内容,当然是DevOps带给企业的重要价值,但并非全部。在专栏中,我不仅希望能跟你分享知识,还希望能跟你分享一些不同的观点,我们一起思考和讨论,获取灵感和新知。

之前,我在跟Jenkins创始人KK聊天的时候,他提出过这样一个问题:熟悉云计算的同学可能或多或少地了解过容器编排领域的事实标准Kubernetes以及它背后的CNCF基金会,那么,企业为什么热衷于加入这样的基金会呢?即使要付出一笔不菲的费用也在所不惜,企业这么做的收益究竟是什么?

不可否认,CNCF是一个非常成功的运营案例,成为会员还能享受白纸黑字上的福利,但是,对于很多中小企业而言,他们的诉求可能不止如此。

很多时候,企业加入这样的组织,也是为了向内部员工表态,我们正和世界上最著名的公司站在同一条起跑线上,关注着同样的问题。这对他们的员工来说,既能起到激励作用,也能增强对企业自身的信心。

对于DevOps而言,道理也是同样的,因为说到底,企业的问题都是人的问题,最核心的价值最终都会归结到人身上,所以,单纯关注软件交付的能力而忽视人的感受,结果往往都是片面的。

在企业内部建设DevOps工具平台的时候,我也经常在思考这个问题,我们费尽心思通过平台能力建设提升了5%的交付效率,即便节省下来的时间只是让员工多休息了一会儿,也是非常有意义的事情。因为DevOps本身也包含了改善软件从业人员的生存状态,提升他们的幸福水平的理念

这么看来,实施DevOps,一方面可以通过种种流程优化和自动化能力,改善软件开发团队的工作节奏,另一方面,也可以让大家关注同一个目标,彼此信任,高效协作,调动员工的积极性和创新能力,从而让整个团队进入一种积极创造价值的状态,而这所带来的影响远非建设一两个工具平台可比拟的。

总结

DevOps作为软件工程的第三次革命,在数字化转型的大潮之下,几乎成了所有通过交付软件来提供服务的企业的必选项。因为,DevOps不仅可以改善企业的软件交付过程,实现高质量和高效率兼得,同时也可以持续改善企业内部的工程师文化,提升员工信心,激发员工的活力和价值创造,从而帮助企业在VUCA时代占得先机,获得更大的成功。如果一家企业真的可以通过DevOps落地达到以上目标,而只需要多付出10%~20%的年终奖,岂不是大大赚到了吗?

思考题

最后,给你留一个思考题:如果你觉得DevOps可以解决公司现有的问题,想要跟领导申请立项的话,你会如何说明DevOps的价值呢?

欢迎在留言区写下你的思考和答案,我们一起讨论,共同进步。如果你觉得这篇文章对你有所帮助,欢迎你把文章分享给你的朋友。

精选留言(15)
  • linda.zx 👍(40) 💬(3)

    老师,请问关于DevOps现状报告哪里可以看到完整版呢?

    2019-10-10

  • 陈斯佳 👍(59) 💬(9)

    我会直接和老板说:“现在的测试发布每一次需要一个小时左右。如果DevOps实行后,预计只需要10分钟,节省了50分钟。这50分钟乘以运维组、测试组和开发组的20个人,省下的工作时间就是1000分钟。再乘以他们每分钟平均薪酬,大概1元钱(按照月薪8000算)。也就是每次测试环境发布就能节省1000块钱。每天预计需要平均5-6次测试发布,那么每天就能省5000-6000块。每个月(按照20天)就能省100000-120000。如果效率再高点,还能省更多。老板,您觉得如何?”

    2019-10-13

  • delly 👍(18) 💬(4)

    我所在的运维团队把自己一整套运维流程做成了DevOps:通过配置管理工具(chef)把需要手工配置的项目代码化,然后通过gitlab管理代码项目,jenkins实现持续集成持续部署,几乎所有以前需要手工配置的东西都变成了几行代码。同时也为app部署提供了更快捷的通道。配合三活的基础架构,部署以及变更也可以做到随叫随做,至少头天要求第二天做。 对团队整体来说算是极大地解放了双手和工作效率,对个人来说喜忧参半。。。因为我们这种大厂的运维团队,职能分的很细,有一部分人是负责客户沟通和应用的(现在都去开发配置代码了,开发完无论是一台server还是一万台都可以随时部署),另一部分负责具体干活的(部署,照手册配置),那目前的状况对第二部分人来说就比较惨了,无事可做,就必须要找到其他出路。人家说的DevOps干掉运维干掉的就是我们的这一部分人。

    2019-10-10

  • iiiqueena 👍(15) 💬(1)

    归根结底还是提高“人效”。从人、流程、工具出发实现这个目标,落地过程中由文化引导,的确是很困难的事情。尤其是人的本性是安于现状或恐惧改变带来的不利因素,但当他们看到改变带来的好处时,应该也是忧喜参半(喜的是效率提高,忧的是多出来的劳动力应该转向哪里?)。如果再往前想一些,当技术可以极大地提高生产力时,那核心是不是就是业务能力?

    2019-10-11

  • 砖瓦工 👍(15) 💬(3)

    老师,“DevOps 作为软件工程的第三次革命”的出处是哪里?前两次革命是什么?

    2019-10-10

  • 阿卡牛 👍(13) 💬(2)

    DevOps 有什么致命的缺点吗?毕竟没有银弹啊

    2019-10-10

  • Wesley 👍(9) 💬(2)

    《软件观念革命—交互设计精髓》,该书提到软件开发领域的三次革命: 1. 高级语言 20世纪50年代,使软件开发从机器语言的束缚中解放出来。 2. 软件工程 20世纪70年代,使软件开发的注意力从语言拓展到开发过程。 3. 人机交互 20世纪90年代,人机交互理论改变了一般商用软件的设计开发流程和方式

    2019-10-10

  • leslie 👍(7) 💬(3)

    老师在课程中提到的4个指标:我觉得其实更多的是对当期时代的Ops的要求吧,记得Google SRE提出过其实现代的Ops已经需要解决更多的问题,就像现在有AI Ops;做为从业多年的Ops其实一直在思考,传统Ops持续之路在何处? 这两年听到越来越多的Ops是最便宜最好找的甚至我觉得很多时候快接近90年代和20世纪初的网管了,可是Ops所承担的压力以及工作似乎完全不符;DevOps和AI Ops其实算是Ops的转型/升级吧?毕竟软件已经从过去的单机、发展到CS/BS模式、现在的分布式,Ops所承担工作已经完全不一样了。DevOps只是作为企业内部的一部分是不是有点弱化了价值?SRE中曾经提及其实其实DevOps其实还是一个Team存在:其实很多时候是OpsDev与DevOps组合值班,去解决问题;其实我觉得这是一种很好的探索吧。其实我现在是DBAOPS,不过由于Dev环节还是有些问题-在强化自己的Dev的基本能力,这样基本能完全把握问题在哪儿吧。 单纯的DevOps有些统称了:其实Ops不理解Dev是做不好Ops的;申请项目谈不上:设计项目和组织结构倒是在考虑,或许将来规模够大可以用,暂时只能一肩挑了。

    2019-10-10

  • 陈文涛 👍(6) 💬(2)

    这个“课后作业”可是个难题,最近也在思考这个问题,devops的好处显而易见,但毕竟请的起咨询公司还是少数,所以我觉得这个实施devops与实施敏捷其实套路差不多,首先要大家达成一致的认识,试点团队,打造明星团队,成果宣传推广。 devops是一套体系,如何体现出来他的价值,由众多流程环节进行保证,比如你的自动化测试、代码静态检查、自动化部署、自动编译打包,总之第一点要解放双手,从研发工具上入手,这第一点是从无到有的过程,建立起来并不难,然后才是进一步的推进。 而对于2b的行业devops的理念可能与2c行业也有不同吧,因为毕竟部署环节其实是割裂开的,这也是想请教老师的问题。 总之,我觉得如果还不是敏捷的研发模式首先要敏捷起来,而devops感觉就是敏捷思想的进一步的延续,就像微服务之余soa一样。

    2019-10-11

  • Bryan_7171 👍(4) 💬(1)

    老师,请问Agile Coach和DevOps master一起进入项目,进行Scrum培训和DevOps培训,怎么分配比较好呢,有些工作看起来有重复,并且有不同的地方,项目组的人员会感觉矛盾的,怎么才能合理地将Agile和DevOps一起融入到项目中呢?

    2019-11-05

  • 而立斋 👍(4) 💬(3)

    我会把老师的专栏背熟,让后直接去说服他。

    2019-10-12

  • 阿硕 👍(4) 💬(3)

    企业的数字化转型有没有一个通俗易懂的解释呢?devops的实施是否就代表着实现数字化转型或者有关呢?

    2019-10-11

  • 萨瓦迪卡么么哒 👍(4) 💬(1)

    建议在试读阶段写一点技术层面的干货,很多人也提到了所谓的落地实践。否则很难判断课程的实际价值。

    2019-10-10

  • Bryan Bai 👍(3) 💬(1)

    我的经验DevOps要走草根线路,从小组的单一功能的试运行,创造明星团队,逐步获得其他部门和老板信任,增加更多功能,并加入更多团队。由各个部门分摊成本。

    2019-10-10

  • 就不告诉你 👍(3) 💬(1)

    我的困惑是,Devops是以单项目方式推进,还是多项目共同推进?时间紧,任务急的情况下,这东西怎么去整合?常规的落地需要多久?

    2019-10-10