提到 DevOps 这个词,我相信很多人一定不会陌生。

 

作为一个热门的概念,DevOps 近年来频频出现在各大技术社区和媒体的文章中,备受行业大咖的追捧,也吸引了很多吃瓜群众的围观。

 

 

那么,DevOps 是什么呢?

有人说它是一种方法,也有人说它是一种工具,还有人说它是一种思想。更有甚者,说它是一种哲学。


 

 

越说越玄乎,感觉都要封神啦!DevOps 这玩意真的有那么夸张吗?它到底是干嘛用的?为什么行业里都会对它趋之如骛呢?

 

今天这篇文章,小枣君就和大家好好聊一聊这个 DevOps。

 

DevOps 的起源

这个故事有点长,从头开始讲起吧。

 

上个世纪 40 年代,世界上第一台计算机诞生。从诞生之日起,它就离不开程序(Program)的驱动。而负责编写程序的人,就被称为“程序员”(Programmer)。

 

 

 

程序员是计算机的驾驭者,也是极其稀缺的人才。那个时候,只有高学历、名校出身的人,才有资格成为程序员,操控计算机。

 

随着人类科技的不断发展,PC 和 Internet 陆续问世,我们进入了全民拥抱信息化的时代。越来越多的企业开始将计算机作为办公用的工具,用以提升生产力。而普通个人用户也开始将计算机作为娱乐工具,用以改善生活品质。

 

 

于是,计算机的程序,开始变成了一门生意。程序,逐步演进为“软件(software)”,变成了最赚钱的产品之一。


在软件产业里,程序员有了更专业的称谓,叫做“软件开发工程师(Software Development Engineer)”,也就是我们常说的“码农”。
 

 

我们知道,一个软件从零开始到最终交付,大概包括以下几个阶段:规划、编码、构建、测试、发布、部署和维护。

 

 

最初,程序比较简单,工作量不大,程序员一个人可以完成所有阶段的工作。

 

 

随着软件产业的日益发展壮大,软件的规模也在逐渐变得庞大。软件的复杂度不断攀升。一个人已经 hold 不住了,就开始出现了精细化分工。


码农的队伍扩大,工种增加。除了软件开发工程师之外,又有了软件测试工程师,软件运维工程师。
 

 

分工之后,传统的软件开发流程是这样的:

 

软件开发人员花费数周和数月编写代码,然后将代码交给 QA(质量保障)团队进行测试,然后将最终的发布版交给运维团队去布署。所有的这三个阶段,即开发,测试,布署。
早期所采用的软件交付模型,称之为“瀑布(Waterfall)模型”。

 

 

瀑布模型,简而言之,就是等一个阶段所有工作完成之后,再进入下一个阶段。

 

这种模型适合条件比较理想化(用户需求非常明确、开发时间非常充足)的项目。大家按部就班,轮流执行自己的职责即可。

 

但是,项目不可能是单向运作的。客户也是有需求的。产品也是会有问题的,需要改进的。

 

 

随着时间推移,用户对系统的需求不断增加,与此同时,用户给的时间周期却越来越少。在这个情况下,大家发现,笨重迟缓的瀑布式开发已经不合时宜了。

 

于是,软件开发团队引入了一个新的概念,那就是大名鼎鼎的——“敏捷开发(Agile Development)”。



敏捷开发在 2000 年左右开始被世人所关注,是一种能应对快速变化需求的软件开发能力。其实简单来说,就是把大项目变成小项目,把大时间点变成小时间点,然后这样:

 

敏捷开发

 

有两个词经常会伴随着 DevOps 出现,那就是 CI 和 CD。CI 是 ContinuousIntegration(持续集成),而 CD 对应多个英文,Continuous Delivery(持续交付)或 Continuous Deployment(持续部署)。


美其名曰:“持续(Continuous)”,其实就是“加速——反复——加速——反复……”,这样子。

 

画个图大家可能更明白一点:

 

 

敏捷开发大幅提高了开发团队的工作效率,让版本的更新速度变得更快。


很多人可能会觉得,“更新版本的速度快了,风险不是更大了吗?”


其实,事实并非如此。


敏捷开发可以帮助更快地发现问题,产品被更快地交付到用户手中,团队可以更快地得到用户的反馈,从而进行更快地响应。而且,DevOps 小步快跑的形式带来的版本变化是比较小的,风险会更小(如下图所示)。即使出现问题,修复起来也会相对容易一些。

 

 

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度,但是它的效果仅限于开发环节。研发们发现,运维那边,依旧是铁板一块,成为了新的瓶颈。

 

 

运维工程师,和开发工程师有着完全不同的思维逻辑。运维团队的座右铭,很简单,就是“稳定压倒一切”。运维的核心诉求,就是不出问题。


什么情况下最容易出问题?发生改变的时候最容易出问题。所以说,运维非常排斥“改变”。

 

于是乎,矛盾就在两者之间集中爆发了。

 

 

这个时候,我们的 DevOps,隆重登场了。
 

DevOps 到底是什么

DevOps 这个词,其实就是Development 和 Operations 两个词的组合。它的英文发音是 /de'vɒps/,类似于“迪沃普斯”。

 

 

DevOps 的维基百科定义是这样的:


DevOps 是一组过程、方法与系统的统称,用于促进开发、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

 

 

这个定位稍微有点抽象,但是并不难理解。反正它不是某一个特定软件、工具或平台的名字。


从目标来看,DevOps 就是让开发人员和运维人员更好地沟通合作,通过自动化流程来使得软件整体过程更加快捷和可靠。

 

破墙工具


很多人可能觉得,所谓DevOps,不就是 Dev+Ops 嘛,把两个团队合并,或者将运维划归开发,不就完事了嘛,简单粗暴。


注意,这个观点是不对的。这也是DevOps这些年一直难以落地的主要原因。


想要将 DevOps 真正落地,首先第一点,是思维转变,也就是“洗脑”。不仅是运维的要洗,开发的也要洗。员工要洗,领导更要洗。

 

DevOps 并不仅仅是组织架构变革,更是企业文化和思想观念的变革。如果不能改变观念,即使将员工放在一起,也不会产生火花。

 

除了洗脑之外,就是根据 DevOps 思想重新梳理全流程的规范和标准。

 

在 DevOps 的流程下,运维人员会在项目开发期间就介入到开发过程中,了解开发人员使用的系统架构和技术路线,从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中,并提供系统部署的优化建议。

 

DevOps 的实施,促进开发和运维人员的沟通,增进彼此的理(gan)解(qing)。

 

在思维和流程改变的同时,想要充分落地 DevOps,当然离不开软件和平台的支持。

 

目前支持 DevOps 的软件实在是太多了。限于篇幅,就不一一介绍了。话说回来,现在 DevOps 之所以被吹得天花乱坠,也有这些软件和平台的功劳,可以趁机卖钱啊。

 

DevOps 生态圈中令人眼花缭乱的工具



上述这些关键要素里面,技术(工具和平台)是最容易实现的,流程次之,思维转变反而最困难。


换言之,DevOps 考验的不仅是一家企业的技术,更是管理水平和企业文化。


对比前面所说的瀑布式开发和敏捷开发,我们可以明显看出,DevOps 贯穿了软件全生命周期,而不仅限于开发阶段。
 


下面这张图,更明显地说明了 DevOps 所处的位置,还有它的价值:

 

 

 

 

DevOps 的发展现状

DevOps 这个词来源于 2009 年在比利时根特市举办的首届 DevOpsDays 大会,为了在 Twitter 上更方便的传播,由 DevOpsDays 缩写为 DevOps。

 

目前,DevOps 处于高速增长的阶段。尤其是在大企业中,DevOps 受到了广泛的欢迎。

 

根据 2018 年的调查发现,74%的受访者已经接受了 DevOps,而前一年这一比例为 66%。

 

越大的企业,越喜欢 DevOps。包括 Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Walmart、Sony 等公司,都在采用 DevOps。

 

如今,DevOps 几乎已经成为了软件工程的代名词。

 

DevOps 迅猛发展,相关专业人才的薪资待遇也跟着水涨船高。

 

根据调研,DevOps 工程师在美国的平均年薪为 130000 美金,在中国平均年薪也在 40 万 -50 万区间,能力强者年薪百万也是比比皆是。

 

数据来自招聘网站

 

薪资的猛涨,又带动了 IT 工程师们学习和认证的热潮。

 

DevOps 的认证目前最受欢迎的就是 EXIN DevOps Master 和 EXIN DevOps Professional。这些认证的培训费用不低,但是仍然吸引了很多人踊跃报名。

 

EXIN DevOps 认证体系

 

DevOps 与虚拟化、容器、微服务

 

 

这几年云计算技术突飞猛进,大家应该对虚拟化、容器、微服务这些概念并不陌生。当我们提到这些概念的时候,也会偶尔提及 DevOps。

 

它们之间有什么联系呢?


其实很简单。


大家可以设想一下,如果要对一项工作进行精细化分工,我们是对一个大铁疙瘩进行加工方便?还是拆成一块一块进行加工更加方便?

 

显然是拆分之后会更加方便。


所谓“微服务”,就是将原来黑盒化的一个整体产品进行拆分(解耦),从一个提供多种服务的整体,拆成各自提供不同服务的多个个体。如下图所示:

 

单体式架构(Monolithic)→ 微服务架构(Microservices)


微服务架构下,不同的工程师可以对各自负责的模块进行处理,例如开发、测试、部署、迭代。


而虚拟化,其实就是一种敏捷的云计算服务。它从硬件上,将一个系统“划分”为多个系统,系统之间相互隔离,为微服务提供便利。


容器就更彻底了,不是划分为不同的操作系统,而是在操作系统上划分为不同的“运行环境”(Container),占用资源更少,部署速度更快。

 


明白了吧?虚拟化和容器,其实为DevOps提供了很好的前提条件。开发环境和部署环境都可以更好地隔离了,减小了相互之间的影响。


这也是DevOps为什么 2009 年时不火,现在越来越火的一个主要原因之一。

 

 

 

 

DevOps 和通信

作为一名通信工程师,小枣君再说说 DevOps 和通信的关系。


最开始接触 DevOps 的时候,我和很多人一样,都以为这是一个纯 IT 的概念,和我们通信没有什么关系。


后来,随着对 DevOps 的深入了解,我才发现,这个理念和我们通信有密切的关系。甚至说,早在十多年我刚入行的时候,其实就已经遇到了 DevOps 所面对的问题。


那时候(2005 年左右)的电信业,产品的稳定性和可靠性是压到一切的(其实现在也是)。所以,电信业的软件版本,更新速度非常慢。对朗讯、爱立信这样的传统巨头来说,通常大半年才出一个正式版本。这个版本经过重重把关、精雕细琢,所以非常稳定。
随着 3G 的兴起,全球运营商开始对网络进行更新换代。华为和中兴开始趁机切入国际运营商市场,试图从国际巨头那边分一杯羹。

 


除了价格之外,华为中兴最大的杀手锏是什么?就是响应速度。


那个时候,运营商客户对电信设备软硬件的需求非常多、非常频繁。像印度这样的地方,客户尤其难缠,每天都会提出新的需求。


当时几家海外设备商的响应速度是非常慢的,从不轻易同意接受需求。即使接受,也会答复半年甚至一年后实现。客户听了直接就崩溃了。


而华为和中兴则不同,两家公司的售前市场人员对于客户需求非常“大方”,基本上有求必应。(当时售后同事都会骂售前同事,可是仔细想来,不答应的话,根本没有进入市场的机会。)

 

 

当时华为和中兴的版本发布频率,快到什么程度呢?最快的时候,三天一个版本。甚至,长期都有大批研发人员驻扎在客户办公室,现场改版本,提交“热补丁”。

 

 

那时候是 2006 年,DevOps 这个概念的影子都还没有。研发那边,好像也就是刚刚提出敏捷开发。在没有理论框架和工具平台的支持下,纯靠人力,实现了版本的飞速迭代。当然,这其中的代价和风险也是很高的。

 

不仅是开发人员很累很辛苦,项目里的工服(工程服务)工程师,也就是技术支持工程师,本文里面的运维工程师,更是苦不堪言。你想啊,以前几个月升一次级,现在几天就要升一次级,能不辛苦么?

 

但就是这样的辛苦付出,才硬生生从传统巨头嘴里抢下来市场份额,最终一步一步做大做强。

 

后来,才慢慢有了敏捷开发的概念,现在更是有了 DevOps,各种工具啊平台啊都有了,给版本快速迭代提供了很好的条件。

 

对通信行业的运维来说,DevOps是机遇更是挑战。

 

就像前面说的容器、虚拟化。5G 核心网采用的 NFV 虚拟化技术,让网元功能隔离,就大大降低了核心网工程师的操作风险和难度。这是一个积极的变化。但是,DevOps对运维工程师的能力要求,是大大提高了。。。

 

通信软件是 IT 软件的一个重要分支,和 DevOps 有很紧密的关系。建议通信工程师好好了解一下DevOps,升级一下自己的知识库,做好技能储备。

 

最后的话

天下武功,唯快不破。

时代发展到现在,客户的需求瞬息万变,市场的风向也难以预测。作为企业,想要生存下去,只有让自己变得更快。作为员工,必须让自己眼光更加长远,内心更加包容。


好了,以上就是今天的内容,谢谢大家的耐心阅读!下期再见!