DevOps中开发的作用和主动性

前段时间接到右军的命题作文,要聊聊DevOps中开发的作用和主动性这个话题。


命题作文的好处就是,逼迫自己从不同的角度去思考同一个事物,这段时间以来也让我不断回顾和琢磨,对这个问题又有了很多新的认识。


我们讲现在的DevOps和运维,之所以越来越受到重视,跟分布式架构在业界的广泛实施这个背景是紧密相关的。


也就是,DevOps是分布式架构场景下的DevOps,运维是分布式架构场景下的运维,会更加的准确,后面我们介绍的案例基本都会以此为背景。


回到开发的作用和主动性的命题上,其实我的理解,应该是在这种背景下:


系统复杂度远远超出人力掌控范围,超出人脑认知范围,开发和运维必然要紧密协作,共同面对新挑战和新场景的问题。


也就是,除了合作,别无选择,如果有任何一方不主动,就会造成效率的极大下降,以及稳定性的极大损害。


面对这样的场景,多少有些“被动”意味,所以所谓的“主动性”更多的是被现实场景,被业务场景倒逼出来的。


这里,我根据不同公司的做法,总结了三种典型的模式来参考,以便于后面更深入的分析:


第一种,文化使然,开发主导模式。


最典型的就是Netflix的“Freedom and Responsibility”,Netflix号称是没有运维岗位的,连SRE角色也只有极少数,与此类似的还有Amzon,他们的运维工作基本都是由开发自助完成。


无论极致的Netflix,还是大名鼎鼎的Google,还是老牌的Amzon,正是在这种*和责任共存的文化驱动下,无论开发还是架构师,天然地对自己的系统、平台甚至是应用端到端负责,从而逐步构建起了能够支撑海量业务的基础设施和服务平台。

这样到了后期,很多繁杂和重复的工作,开发都可以基于平台自助完成,而不是依赖运维的人来完成。


所以,我们仔细观察,你会发现,国外的大厂其实极少提DevOps这个概念,因为他们天然就是这么干的,是理所当然的一种研发模式。


这种模式对于组织来讲是最为高效的,但是文化导向之所以能够发挥这么大的作用,也有一个极为重要的前提就是技术团队和人才的能力问题,只有当团队能力足够强的时候,才能够支撑起如此完善的体系建设,再加上国外强烈的工程师文化,让他们能够耐住性子,沉下心来,稳扎稳打。


反观国内,一个是技术人才的能力还达不到这个程度,再就是,国内的公司和产品往往追求业务增速和发展,往往会牺牲一些非功能性的能力。


单纯从技术角度来看,国内公司在这方面很明显是落后很多的。


第二种,自上而下的决策,开发和运维“被动”执行模式。


最典型的就是阿里的DevOps转型,阿里应该是在2015年左右,甚至更早,就启动了DevOps转型。


体现在组织架构上,最明显的就是取消了PE应用运维这个岗位。

这个转型有两个必要因素:


第一个,多年技术积累,基础设施和平台非常完善


原来基础能力不够的时候,很多运维工作也是要依赖PE这样的角色人肉去完成,但随着平台不断完善,有很多事情,开发完全可以基于平台自助完成,而不再需要多一个PE这样的环节去做。


所以,从技术角度,阿里已经完全具备了DevOps的基础条件,从组织效率角度,提升研发整体的交付效率也势在必行。


第二个,也是最关键的一点,自上而下的决策执行。


虽然基础条件具备了,这时无论是开发还是运维,都不具备能力去做组织层面的调整和融合。


但是,从研发高层的角度,当意识到DevOps转型时机成熟,且经过论证和实践是可以带来效率极大提升的时候(国外大厂的模式已经证明),组织上的职责和岗位调整,就势在必行了。


我在几个大会上听到的分享,以及线下与经历DevOps转型的工程师交流,可以看到,上面的决策一下达,研发团队就制定了非常详细的交接和培训计划,原PE团队职责逐步交接到开发团队,经过多轮培训和交接后,历时两年左右,完成了整个DevOps的转型。


讲到这里,我们可以看到,对于两个团队来说,都有一些被动的意味。但是,这个结果的达成,是离不开前期这么多年,技术能力不断积累完善这个前提条件的。


所以,准确一点讲,应该是结果达成的阶段相对被动,但是前期的准备和积累阶段,都是主动的。


稍微总结一下,以上两种模式的案例,我们可以看到都是大厂的案例,他们有一个共同的规律,就是基础设施和基础平台完善且强大到一定程度后,DevOps转型和落地更多的是水到渠成的结果


但是,上面的案例已经是结果,但是对于一般企业,DevOps的演进过程应该什么样的,这个过程中,开发应该怎么做?运维应该怎么做?


下面我就结合蘑菇街的案例讲一些更细节的部分。


第三种,技术战略项目切入,开发和运维合作共建


所谓技术战略项目,可以理解为当业务发展到一定程度或某个阶段时,技术层面为了更好的适应业务趋势和场景,而做出的一些整体技术架构调整,这里可能包括软件架构、研发组织架构、基础设施建设等等。


我回顾了下,蘑菇街整个DevOps体系的逐步形成,基本就是在这些技术战略项目的执行中,不断形成和完善的。


第一个,Java服务化体系的建设


2015年初,蘑菇街研发部启动业务架构的服务化项目,对原来的PHP单体架构改造。

当时,这个项目是为了能够快速响应业务变化而做出的改变,并不是单纯为了DevOps的目的。


不过,后来项目进行过程中,我们遇到了分布式架构体系下的一系列效率问题,比如应用发布、资源申请,快速扩容、问题定位以及故障响应等,统统跟不上节奏了。


到了这个阶段,我们发现效率上不去,工具跟不上,最关键的问题就在于各种标准缺失

所以,我们花了大量时间和精力做了标准制定,从机型选择、OS版本、系统参数、到应用命名、部署目录、依赖管理,配置管理再到后面分布式组件和框架的标准约束等等。


再往后,我们开始基于标准又配套提供了很多解决棘手问题的工具平台,一开始这些平台很简陋,但是能解决问题,再往后慢慢完善和重构,能力就越来越强大了,比如持续交付系统。


开发在这个阶段,最主要的作用就是与开发共同制定标准,并在后续的架构设计和研发过程中,严格遵从标准,否则,接入不了工具平台,效率和稳定也就谈不上了。


一开始强制约束,不按标准来,不给资源、不给发布,开发感觉非常不灵活,被限制了创造力,但是随着后来效率的提升,大家都慢慢认可了这种模式,而且会主动执行。


这个过程下来,我们所理解的DevOps,其实是被现实场景倒逼出来的,开发和运维必须更紧密的合作,一步步尝试和探索,才能让团队运转下去,其它别无选择。


第二个,电商大促的常态化


电商企业的大促越来越频繁,已经呈现出日常化的形态。


蘑菇街也不例外,为了保证业务峰值状态下的稳定,技术手段上,对线上压测、故障模拟、预案演练以及容量评估等,提出了更高的要求,从这个维度,又在驱动着整个稳定系体系的不断完善。


这里要做的非常关键的一点,稳定性的标准化,并且在开发阶段严格执行。举个例子,我们要做限流,在开发的代码中,哪些API、函数需要限流?限流的阈值多少?限流对外部的影响是什么?


这就需要对业务和代码都非常熟悉才可以,不然限流的点的方式不对,稳定性就无从谈起。


对于容量评估、全链路压测等等也是一样,只懂技术,不了解业务场景和模型,就没法有效实施。


所以,在这种场景下,开发是要发挥核心作用的,运维可以通过指标和模拟等手段去推到,但是始终是黑盒,作用终究有限。


第一和第二个项目中涉及的平台建设细节,我就不再赘述了,大家如果感兴趣可以看我公众号的文章或者极客时间专栏文章。



第三个项目,业务上云


到了2018年,我们决定业务整体上云,依托于腾讯云完善的基础设施体系,将更多的精力专注在业务研发领域。


这里带来的一个变化就是,很多服务都是现成的,如云主机、缓存、消息、数据库等等,申请即用,大大提升了我们资源和服务交付的效率,但是面临的问题,就是大量的服务实例成本如何管理的问题。


最简单的方式,就是将能力暴露出来,由开发自助使用,而不是再通过运维审核或控制,最终通过成本分摊来控制合理使用。


之前,自建IDC模式,服务器一旦采购,成本就已经形成,用与不用,成本并不会有差别。


但是上云之后,按需付费,开发就要开始形成成本意识,必须要对自己所做事情,对自己的设计和写的代码的的ROI,有明确的分析。


场景不同,要求也就完全不一样了。


限于篇幅原因,这部分内容,包括我们在云上的双活站点建设,我会再开新文章来介绍我们的经验。


三个部分做个总结,我们可以看到运维更像是技术运营,在驱动一些事情,但是真正的落地和执行,仍然在开发。同时,我们可以感受到,双方合作是否顺畅和紧密,心态和意愿,也是关键的要素。


最后,总结


上述的过程,如果倒过来看,其实就是一个公司随着业务发展和增长,技术体系演进的一个缩影。


也就是,业务场景驱动,组织手段推进,文化导向覆盖。


蘑菇街从无到有的建设,随着体系完善,终究会走向阿里DevOps转型后的模式,而阿里随着转型的完成,更深入的发展,必然会朝着Netflix的文化导向的趋势发展,让团队中每一个技术人员都能够具备端到端意识。


所以,DevOps的实施和落地,不是某个点的改变,它必然一个体系的要求,比如业务上,体量和场景达到一定规模,技术层面必须达到一定高度,组织层面必须具备足够的力度和决心,同时文化宣导上覆盖要足够广,足够彻底。

而开发在这个过程中的落地执行,无疑又有着决定性的作用。

上一篇:解读Tom介绍的Oracle Database 12c的12个新特性


下一篇:【VNC】手工kill掉VNC进程的故障处理