9月7日-8日,相约 2023 腾讯全球数字生态大会!聚焦产业未来发展新趋势! 了解详情
写点什么

运维十年回顾:当前很多新技术的本质都是在解决运维问题

  • 2019-04-26
  • 本文字数:5758 字

    阅读完需:约 19 分钟

运维十年回顾:当前很多新技术的本质都是在解决运维问题

2008 年到 2019 年这 10 年多的时间里爆发了很多重要的技术和技术浪潮,运维技术也在这十年间发展到了深水区。随着云计算技术的普及以及容器技术的兴起,运维效率大大提升,运维平台得以将运维人员从繁重的人工操作中解救出来;而人工智能的发展也使得 AIOps 成为可能,让运维人员能够先用户发现故障,更好得保障业务运行。


此文系 QCon 十周年特别策划《技术十年》系列文章,在技术发展 10 年这个特殊的时间节点上,我们邀请了蘑菇街技术总监赵成来谈谈他在过去十年间的感受。一起回顾一下运维行业十年来的发展变化和趋势,以及这中间的演进逻辑,以期给更多的运维同行一个参考。本系列还有移动、大数据和云计算领域的回顾文章。访问 QCon 北京 2019 官网日程,了解最新技术趋势与实践。


很高兴能在 QCon 10 年之际接到邀请,写一写运维行业发展的这十年,非常感谢 InfoQ 社区的邀请和信任。


在我正式写文章之前,我仔细回顾了一下我个人经历的运维的过程,也去翻了很多其他公司公开能看到一些分享材料,也找很多业界的同事做了交流,让他们也一起回忆一下过往的经历,因为十年很长,还是有很多东西值得回味和探讨。


最终,我总结出 5 个结论,也是规律,分享给大家,期望带给各位读者和所在的企业一些思考和启发:


  1. 第一,运维行业的发展,是有规律可循的,是一个逐步演进的过程。这也说明,其实我们有很多经验可以向先行者们学习。

  2. 第二,运维行业的发展,不是孤立的,它与业界的整个技术趋势发展是相辅相成的。这就要求,关注运维的同时,我们也要关注整个技术趋势和背景。

  3. 第三,运维行业真正高速地发展,真正地被重视,其实就在最近 5、6 年。运维这个行业还很年轻,仍有非常大的发展空间。

  4. 第四,运维行业当前的痛点,本质上更多的是企业层面的痛点,而不是运维个体的痛点。所以,要尝试自上而下的解决问题,而不是自下而上。

  5. 5 第五,未来,一定是云计算的时代,未来已来,只是分布不均。所以,云计算时代下的运维转型升级,将是一个非常明确的方向。


如果用一张图表示这 10 年运维发展的过程,下图再合适不过:



接下来,我们分过去、现在和未来三部分来分享一下我对运维发展过程及未来趋势的理解。

过去(2009-2013):人工运维

第一个阶段,人工作坊阶段,也就是我们遇到的所有运维问题,基本靠人工操作完成。这种情况下,系统规模不大,遇到的问题相对简单,大多集中在硬件、网络和系统层面,所以有一定操作系统或网络维护经验的人就可以搞定。


这种场景下的运维,也就是我们常说的 SA,系统管理员,而且一般身兼多职,人数也不太多。


第二个阶段,脚本工具阶段,一般绝大多数企业都会很快从第一阶段过渡到第二阶段,因为上一阶段的大量重复繁琐的操作,完全可以转化为脚本来实现,而不是每次都去敲一堆类似的命令。


早期的 SA 主要以各种 shell 为主,所以很多 SA 如果会 shell 编写一些批处理脚本,就会很有竞争力了。再往后,我们大家所熟知的 Perl、Ruby、Python 等动态语言也被广泛应用于脚本工具的实现,特别是一些逻辑和场景相对复杂的自动化实现。


第三个阶段,流程和工具阶段,当我们把一些复杂的操作封装成一个个的脚本后,效率确实会提升很多,但是我们所面对的业务场景和体量也在变得更复杂。比如,对于运维同学,以前就是负责安装和配置一下操作系统,如果是几十台或百台的规模,脚本批量执行完全可以搞定。


但是,再往后,运维还要负责软件的频繁发布,每周要多次,甚至是每天都会有,这是由业务特点决定的,特别是互联网类型的业务,与原来传统的每个月、甚至几个月发布一次的场景要求完全不一样了。而且随着用户体量的增加,服务器数量可能已经到了几百上千台,而且部署的业务也不尽相同,所以单纯靠脚本执行,已经完全不能满足要求。


这时候,就要面临更加复杂化的场景实现,比如做一次业务部署,运维同学可能要安装服务器,做系统配置变更,安装软件包、启停进程,然后再负载均衡上配置服务等等。这时,就需要有一个流程将一个个的脚本功能串联起来,同时还要有一些脚本执行结果校验及判断的过程。


所以,这就对流程和工具平台有了更大的诉求。同时,在一些 IT 化比较早的行业,如电信运营商和金融行业,由于对变更过程的严格控制,这就需要更加科学和规范的管理措施,所以会引入 ITIL 这样 IT 服务管理体系,对整个 IT 系统及其变更进行管控。


其实,第一到第三阶段,在 2009 年到 2013 年期间仍是绝大部分公司主流的运维模式。如果能够做到工具化,或者有一些工具化平台,那应该算是比较先进的运维模式了。

现在 (2014-2019):自动化运维

但是,对于一些大厂,步伐会更快一些。2013-2014 年,就已经有国内大厂进入到了第四个阶段,运维已经体系化,完全的自动化。


直到目前为止,从笔者交流和了解到的实际情况看,绝大多数企业基本都在第四阶段的建设过程中,所以我们把 2014-2019 这个阶段定义为现在。


到了这个阶段,就凸显出几个明显的特点,也是我们上面提到的其中几个规律,我们分别说一下。


第一,国内的运维行业的爆发,运维岗位真正地被重视,其实就是近 4、5 年左右的事情,也就是 2014 开始到现在


为什么这么讲?其实我只要关注下,运维行业有自己垂直的技术大会,类似 QCon 以及 ArchSummit 这样的顶级技术峰会,开始专门设置运维专题,基本就是在 14 年左右开始的。这个现象说明,运维的技术复杂度已经上升到了一定程度,各大企业也开始意识到运维对于企业的效率、稳定和成本有着决定性作用,对运维的诉求和要求也越来越高。


从这个角度讲,新兴的运维行业其实才算是刚刚起步,未来仍然会有很大的潜力和空间。


第二,运维的发展不是孤立的,它与整个技术趋势发展是相辅相成的


大厂之所以在这方面会走在前列,一方面是因为业务复杂度和体量所决定,另一方面,是因为这样的场景倒逼着整个业务和技术架构发生了很大的变化。比如我们现在早已耳熟能详的服务化和各类分布式技术,就是在这种场景下倒逼着技术体系演进出来的。


也正是在这样新的技术体系下,运维所面临的场景复杂度也急剧上升,原有的运维技能如操作系统维护、系统配置、脚本编写已经完全满足不了要求。同时,由于软件系统复杂度的提升,也需要运维投入更多的精力去关注业务软件架构和应用服务上。


所以,这种场景下,我们所熟知的 DevOps,SRE、PE、应用运维、技术运营这些新的名字、岗位或理念,开始如雨后春笋般浮现出来。


其实这里很多概念早在 10 多年前就已经出现了。比如 SRE 最早是在 2003 由 Google 提出;DevOps 理念的影子在 2007 年左右就开始浮现出来,2009 年的 DevOpsDays 大会上正式提出了这种叫法;而像 PE 这样的角色,最早是在 Yahoo!设置的。


这些优秀的运维或者稳定性的理念,在国内兴起前,其实已经在国外被广泛实践了很多年。究其原因,还是因为国外的技术发展是超前于国内的,比如 Google 在分布式领域的“三驾马车”,直接开创了一个新的技术时代,让业界有机会充分实践分布式的技术。


这里,我想表达的一个观点是,这些理念在国内真正的落地,还是因为有实际的场景驱动。业务体量和复杂度到了那个程度,技术体系必然会找朝着分布式的方向发展。而配套的,必然会有 SRE、DevOps 以及 PE 这样相辅相成的体系出现


国内大厂有机会提前走到这一步,从绝大部分公司发展的过程看,也必然会遵循这样的规律,只是早跟晚,快跟慢的问题。这里的决定性因素其实是业务复杂度和体量所决定的。


目前很多企业和公司之所以能走到运维的第四阶段,其实很大程度上也是因为广泛采用分布式技术,引入了服务化和各类分布式组件,在这种情况下,业务架构越来越清晰,对应的对运维的诉求和要求也就逐步提升了上来。

典型的技术和发展特点

从技术角度,我们关注下这 4、5 年来技术的发展,说两个最典型的:


一个是容器技术,以及以容器为核心的编排系统,现在基本是以 K8S 为标准了。


首先,Docker 的创始人 Solomon 其实是运维出身,并不是做开发的。当时他的想法也很简单,就是希望能够屏蔽一些跟应用无关的底层细节,Run any application,anywhere,提升部署和发布的效率。


后来一经推出,大受关注,特别是在 14 年左右,可谓是大红大紫,且围绕着容器的一整套生态也在逐步成长起来。到目前为止基于容器和 K8S 的基础平台,已经成为 PaaS 体系建设的标准,如果哪项技术不适配 K8S,那基本是没有发展空间的,也基本不会被认可。


从运维的角度看,容器解决的最大的问题就是运维的问题,特别是运维的效率问题。从目前业界的实践来看,容器确实发挥了极大的作用。


现在更为极致的一种理念是无服务器技术,也就是我们熟知的 Serverless,也叫函数服务器。这种理念极致的地方在于,以后纯粹就是 NoOps 的时代,开发写完代码直接部署发布到云上,完全不用考虑服务器和资源的问题。这种场景无疑是将整个迭代周期压缩到了极致,理想状态下,让整个技术团队无需考虑运维的事情。


但是,实际场景下,新技术发展仍需要一定周期和周边配套体系完善。同时,新技术能够发展完善,也需要找到适合自己发挥的业务场景,有时新技术出现并不是要为了完全替代早期的技术。


简单总结一下,我们会发现,当前非常多的新技术和新趋势的产生,从本质上都是在解决运维问题,未来也一定是这样一个趋势


从最佳时间角度,到了这个阶段,从我个人认为,现在业界运维问题,更多的是企业层面的运维问题,而不是个体运维的问题。这一点跟开发者社区特别强调个人能力极为不同,很多运维的问题解决不了,有时候很大程度上是受限于企业体制、组织架构、文化等方面的非技术层面的因素,而不单纯是个人能力所能解决的。


所以,要解决企业的运维问题,有时是需要自上而下的推进,整个技术团队共同执行落地才可以。从运维的角度单方面发起,是不会有效果的。

未来(2019-Future):智能运维和云计算

关于智能运维

智能运维或 AIOps,我之所以把它定位在未来阶段,主要是我认为目前能在这个领域有成果的,还是集中在大厂。对于绝大多数企业来说,特别是中小企业,时机仍然未到。


从 AI 的角度,AIOps 有三个方面的充要条件:机器学习算法、计算能力如 GPU、海量数据


从上面三个条件看,也就不难理解,为什么 AIOps 做的比较超前的都是国内外的大厂,因为有技术实力、有足够的资源和数据,最关键的是有足够复杂和变态的业务场景以及运维场景,在倒逼着 Ops 往这个方向上走。


但是,对于一家企业来说,实施 AIOps 最重要的前提条件是数据,海量数据。目前来说,能够具备这个条件的只有大厂,因为只有大厂有这个业务和资源体量,能够产生海量数据。


同时,对于 AIOps 来说, 还有很重要的一个前提条件,那就是高度完善的运维自动化,也就是 Ops 的部分。自动化都没做好前,AIOps 是没有任何意义的,千万不要本末倒置。


我的理解,AI 和 Ops 要解决的还是两个层面的问题。可以类比到人,AI 相当于人的大脑,我们手脚和躯干是执行系统,大脑负责决策判断,手脚躯干负责完成大脑下发的动作指令。对应到运维上面,AI 要解决的是怎么快速发现问题和判断根因,而问题一旦找到,就需要靠我们高度完善的自动化体系去执行对应的运维操作,比如容量不够就扩容、流量过大就应该触发限流和降级等等。


最后,AIOps 的发展一定是一个长期演进的过程。AI 是 Ops 的有力补充,进一步降低运维的工作强度和压力,但是 AIOps 一定建设在高度自动化和完善的运维体系之上的,是一个演进的过程,不会是一个跳跃性的过程,也不会产生一个完全颠覆性的 AIOps 模式,将现有的 Ops 体系替代掉。

云计算:未来已来,势不可挡

其实仔细关注下技术趋势的发展,我们会发现,现在很火的一些概念,比如 Serverless、FaaS、边缘计算、弹性计算、云原生、IoT 等,甚至是我们耳熟能详的 Docker 容器、K8S、机器学习、AI 等等,基本都跟云计算相关。很多都是在云计算这个趋势下衍生出来的新技术,而且又因为云计算提供的基础设施,相互之间又有紧密的联系。


说地严格一点,这些技术只有在云上,甚至是公有云上才会发挥作用和价值。脱离了云计算,这些技术没有任何意义。因为,云计算带来的最大的好处就是“按需索取”,也就是我们说的弹性,进而带来成本上的最优化。如果我们自己机房里还维护着上千台设备,都是我们自己的成本,说实话,再弹性也没多大意义,因为不解决实际的成本问题。


再就是,到了机器学习领域,特点是周期性地需要大量 CPU 和 GPU 资源,并不是持续需要,所以如果还是延续老的思路自己采购,这个成本就大了去了,对于一般企业根本不现实。况且有时候还要考虑资源在不同区域分布的问题,比如边缘计算,一个普通企业搞一个机房还可以,但是要管理和维护很多机房,就不太现实了。


所以不难理解,未来的技术趋势,一定是跟云计算相关的。这个是大势,不可逆。


因此从个人成长的角度,我觉得,如果想要更好的发展、更大的空间,就朝着云计算这个行业走,做跟这个行业相关的岗位。一些岗位参考,比如,公有云平台的运维,至少在规模和体量上足够大,挑战也足够大,还能接触到很多新技术。其他由云计算衍生出来的解决方案架构师、技术运营、CRE 这样的岗位也都是不错的选择。


对于企业来说,尽快拥抱云计算,将更多的精力放到自己的核心业务能力上,通过云的能力,为自身的业务带来更多可能性,或许是一个更好的选择。

写在最后

这些年经历下来,特别是近几年,最大的感受就是变化之快,让人目不暇接。新事物、新技术、新产品、新平台层出不穷,有时不知从何下手。


面对这样充满了不确定性的场景,运维人员,包括其他技术人员,唯一能做的就是坚持学习,拥抱变化,脚踏实地的解决问题。对于个人要不断提升能力,对于企业要审时度势,选择好未来的技术方向,我想未来一定会更有挑战,更有乐趣,也必将更加精彩。

作者简介

赵成,资深 DevOps 和运维专家,现任蘑菇街平台技术总监,腾讯云 TVP,极客时间运维专栏作家,多届 ArchSummit 运维专题明星讲师和优秀出品人,SRECon19 Asia/Pacific Speaker,个人专注于云计算、SRE 和 AIOps 领域。

相关文章

云计算十年回顾(上):风雨兼程


云计算十年回顾(下):势不可挡


最新一届的 QCon 即将于 5 月 6-10 日在北京国际会议召开。除了涵盖架构、移动、运维、安全、大数据等经典方向以外,QCon 还策划了智慧零售、用户增长、Chaos Engineering 等新兴方向的话题,超 150 位技术大咖将分享最值得参考的技术实践案例。访问 QCon 北京 2019 查看大会日程,收获技术成长。


活动推荐:

2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。

2019-04-26 18:049064

评论 1 条评论

发布
用户头像
不是解决运维问题,是解决产品效率问题,只是落脚点在运维。云环境提供的成熟产品,在中小企业来看,最终的结果应该是淘汰“运维”。
2019-05-12 10:11
回复
没有更多了
发现更多内容

软件测试 | 测试开发工程师必读经典好书清单

测试人

软件测试 测试开发 测试工程师 测试书籍

鸿蒙开发实例 | 可复用列表项的ListContainer

TiAmo

华为 华为云 云开发 10月月更

Linux系统-进程信号

可口也可樂

Linux 信号 10月月更

写个JS深拷贝,面试备用

helloworld1024fd

JavaScript

分布式事务-两阶段提交协议(2PC)

zarmnosaj

10月月更

软件测试 | 测试开发 | 校招面试真题 | 显式等待与隐式等待的区别?与强制等待的方式分别是什么,有什么区别?

测吧(北京)科技有限公司

测试 测试开发

谈谈曾经做的一个测试报告平台(2)

MegaQi

测试平台 10月月更

ReactDOM.render在react源码中执行之后发生了什么?

flyzz177

React

直面数字化挑战,戴尔PowerEdge R750最全面的通用服务器

科技热闻

阿里前端二面高频react面试题

beifeng1996

React

一文梳理vue面试题知识点

bb_xiaxia1998

Vue

有奖测评 | 今天种下{1},明天就会收获一片{11.11}——程序员日暨11.11狂欢季来啦

京东科技开发者

云主机 测评 双十一 京东云 程序员日

三次握手与四次挥的问题,怎么回答?

loveX001

JavaScript

DOM,Diff算法与Key机制

beifeng1996

React

React源码分析4-深度理解diff算法

goClient1992

React

Linux网络-基础概念

可口也可樂

Linux 网络基础 10月月更

js手写前端需要掌握的点

helloworld1024fd

JavaScript

前端食堂技术周刊第 56 期:Solid v1.6.0、2022 State of GraphQL、ViteConf 回放、Lerna v6、SEO 入门指南

童欧巴

前端经典面试题合集

loveX001

JavaScript

即时通讯技术文集(第3期):高性能网络编程系列 [共14篇]

JackJiang

网络编程 即时通讯IM

vue组件通信方式有哪些?

bb_xiaxia1998

Vue

Linux网络-套接字编程

可口也可樂

Linux 10月月更 套接字编程

个promise

helloworld1024fd

JavaScript

MASA Framework 缓存入门与设计

MASA技术团队

.net MASA Framewrok MASA

HummerRisk V0.4.1发布:新增依赖文件检测功能,优化 AWS 检测规则组,优化资源态势等内容

HummerCloud

云计算 云安全 云原生安全 10月月更 安全合规

React Context源码是怎么实现的呢

flyzz177

React

react的jsx和React.createElement是什么关系?面试常问

beifeng1996

React

嵌入式 Linux 入门(四、Linux 下的编辑器 — 让人爱恨交加的 vi )

矜辰所致

vim Linux VI 10月月更

软件测试 | 测试开发 | 测试开发工程师必读经典好书清单,抽奖赠书送福利!

测吧(北京)科技有限公司

测试

React源码分析3-render阶段(穿插scheduler和reconciler)

goClient1992

React

vue这些原理你都知道吗?(面试版)

bb_xiaxia1998

Vue

  • 扫码添加小助手
    领取最新资料包
运维十年回顾:当前很多新技术的本质都是在解决运维问题_软件工程_赵成_InfoQ精选文章