运维行业前景堪忧?丨话题接力

发表时间: 2021-12-03 10:03

运维平台标准化难以同步、运维体系建设推进缓慢、研发运维间技术无法打通……近年来传统运维的发展困境越来越显著,随着云原生时代的到来,这些困境将使运维陷入危机还是迎来转机?


这显然不是简单两句就能下的定论,我们首先需要认清:云原生时代的基础设施有什么变化?能解决什么问题?运维人员应该重点关注什么?传统运维如何向云原生运维转型?容器化、DevOps、AIOps、微服务、混沌工程等新兴技术该如何选择和学习?


为此,dbaplus社群邀请到京东科技数据库团队负责人-高新刚、美图SRE负责人-石鹏、腾讯游戏混沌工程负责人-吴召军,希望通过汇集三位运维专家的研究成果和实践经验,给运维人员的转型和发展,以及企业的运维体系建设等提供借鉴和启发。



三位嘉宾针对云原生时代的运维转型,都有着以下独到见解:


高新刚

“传统式运维要转向运营式运维”


我的观点主要是围绕传统运维和运营运维的对比思考。


观点一:从传统运维到云原生运维是一个持续迭代、不断进化的过程。我们的运维从传统的手动运维到脚本化、DevOps、再到现在的数据化和AIOps,整个过程是不断演进、不断提升的。


传统运维是从关注代码构建、应用测试、集成部署实施、线上性能故障排查,再到后期的集群扩容、缩容的所有环节的角色。而在云原生时代,我们的运维流程则更加标准、高效,在自动化、智能化的程度上比传统运维要高。研发以微服务的架构形式去开发应用功能,以敏捷的方式去完成持续的交付和集成。到了后期,运维和研发可以通过DevOps的方式,去实现协同的一体化。最后,我们所有的应用都能跑在容器上面。


观点二:从传统运维到云原生运维,整个运维技术栈发生了很多变化。以前我们是面向操作系统和多种组件工具的运维。而现在我们需要转型和聚焦到统一的、面向云原生的、以k8s为通用的云资源控制层面的自动化运维


以往的传统运维,我们关注的是操作系统、存储、网络、数据库包括各种中间件等方面的技术栈。而云原生运维,基本上就是以dorckerun或 podman的命令一键式地部署和运行;然后由 K8s帮助我们解决容器编排的问题;最后通过service mesh,让云原生应用运行起来,它是这个云原生应用的载体。


观点三:运维重心虽然转移,核心能力依然是稳定性、安全性和容灾能力的保障防护与应急处理。


云基础资源提供了资源的容灾能力和扩展能力,运维重心偏向以应用为中心,业务指标可视化和应用链路分析。服务网格可以帮助运维,实现服务注册、发现和负载均衡,分布式追踪,认证授权,加密通信和审计,以及多服务版本,分段服务等特性。


石鹏

“拥抱新技术,关注核心技术能力输出”


我的看法分为以下三点:


1、拥抱变化,顺势而为:


对于大势已成、来势汹涌的云原生浪潮,你没有办法去拒绝或者阻挡它,我们能做的只有尽可能地调整自己去适应它。


以美图为例,我们从19年开始做上云项目,花了大半年的时间,把我们所有的业务,整体从IDC搬移到了云上。这里面带来了很多变化:以前很多基础设施、IDC硬件需要你自己去关注,现在可能不需要了;以前有很多基础服务需要你自己构建,但在上云之后,我们可能会优先选择用云上的Pass,甚至是SasS来解决,这就意味着你维护的对象发生了变化。由此而来的,是对你工作内容的范畴的重新定义。


大概是19年的5月份,Gartner的报告里就指出:现在全世界的企业对于基础设施的选择,已经达到了一个拐点。企业会更倾向于选择云,而不是自建 IDC。综上所述,上云已成大势,我们要调整心态去拥抱它。


2、思维转型,重新定位:


我们的思维需要发生转变,同时工作职责的边界也要重新做定位。


今天分享的主题其实是:看SRE稳定性的运营,而不是运维。运营和运维一字之差,但它代表的意思是不一样的。当你以运营的视角来看待你的运维工作时,你的边界其实是在拓展,建议工作内容“左移”和“上移”。


“左移”指的是,在一个业务的生命周期里,从设计、开发、测试,再到交付、部署,以及后期对它稳定性的保障,这是一条从左至右的流水线。当我们把视角转化成运营的视角之后,可能不仅需要关注服务上线后的稳定性保障,而是要提前介入,在服务设计阶段就更早地去做一些工作。把一些对服务稳定性的设计,比如熔断、柔性策略等,在设计阶段就跟研发协作把它做起来。


“上移”指的是,我们上云之后,基础设施发生了变化,你的关注点可能就不仅是底层的基础设施,不再是那些硬件或操作系统,而是上层的业务,这就是我指的“上移”。


关于这方面我还想再多说一句,Google最近有一个对外分享,讲了 SRE怎么去跟研发协作。随着你能力边际的扩展,你会发现,你做的工作不仅是传统的保证服务稳定性了。或者说,要保障服务的稳定性,不仅是你一个运维团队就能搞定的,还需要其他团队的支持。


像上面说的,当你去做一些高可用的方案,比如去做柔性设计的时候,可能在代码层就要去实现,而这需要研发的支持。现在工作发生了变化,大家在观念上也要产生认同。


3、关注价值输出,升级核心技术能力:


前面讲我们上云了,基础设施发生了改变,工作范畴也拓宽了。现在各种云原生、微服务、服务治理、AIOps等等新鲜的名词层出不穷,也在某种程度上造成了大家的慌张,或者说叫“内卷”。


可能大家会觉得:都已经上云了,那这个工作是不是就不需要我了?因为你的很多工作都已经被云厂cover了,那这时候我们要怎么做?


我的观点是回归价值,回归我们这个岗位对外输出的核心价值。按照我的理解,稳定性、效率、支撑、成本,包括一些安全范畴的内容,只要我们能明确自己岗位的核心价值,持续、高效、高质量地去输出价值,并且在一些必要的技术点上保有新鲜能力,其他的问题都可以不用特别去关心。因为我们只要能够葆有价值,就可以面对来势汹涌的浪潮,做到泰然自若。


吴召军

“云原生时代,运维大有可为”


服务上云的大趋势不可逆、不可阻挡,我们差不多是从19年开始,把服务从IDC切换到腾讯云,我们现网所有的服务现在都跑在腾讯云上,微服务是跑在腾讯云的TKE上,也就是腾讯云的K8S上。


最开始我们做上云的时候,听到了一些声音:上云之后,运维就要被淘汰了,上云之后服务可以做到弹性伸缩,通过流水线就能取代运维在机器上做发布的工作,运维没有工作可做,可能会面临被下岗。


但我们从19年到现在,做了两年多时间,从具体的实践上看,我们运维在云原生这波浪潮下其实大有可为,能做的事情非常多。包括最开始,我们想说有了K8S,是不是可以直接让开发来把服务部署到K8S上呢?


答案是不行。因为我们发现,云原生使用起来有一定的门槛,而开发来学 K8S的知识,他要学习Dockerfile怎么写,YAML文件怎么编排等,这里面的成本可能很高。所以我们运维主动出击,想办法把门槛降低。我们做了一个上云流水线平台,开发在这个平台通过拖拉拽可视化编排,制作发布流水线,包括自动构建镜像、生成Dockerfile、推送镜像到腾讯云仓库,生成YAML文件,部署服务等。


这个过程非常丝滑,学习门槛很低,开发同学上手很快。虽然云原生来了,但我们运维不但没有被淘汰,反而通过平台的建设,提高了开发运营效率。同时,我们运维自己也享受到了上云的红利,现在的服务具备了弹性伸缩的能力,如果有一天,机器挂了,或者机房挂了、整个可用区挂了,我们的服务也可以做到自动化漂移,获得了故障自愈的能力。


这些都是我们上云取得的技术上的红利。所以说,主动拥抱这个变化,只会让运维获得更好的收益、更大的价值,而不是淘汰。


同时我们也在做其他一些工具建设,这里介绍我们现在正在做的几个平台:


可观测性平台。我们之前的log、metrics、trace,这些所有的指标、日志等散落在各个地方。通过可观测性平台的建设,把业务的指标、日志、追踪的数据等全部串联在一个平台里。这样的话,服务一旦出现问题,就可以通过可观测性平台,快速定位到根因。


在运维没有做这个平台之前,现网遇到问题时,定位问题是非常困难的。但在有了这个可观测性平台之后,定位排查的效率就大大提高了,这就是我们运维的价值的体现。而这些点肯定也是要由运维主动来想的,因为开发主要负责业务逻辑的开发,负责版本的迭代,不可能去花心思和精力来想这些问题。


混沌工程平台。混沌工程平台建设的出发点,旨在提升业务的可用性。因为大家知道,上云之后,服务治理起来会非常方便,用户一般都会根据自己的模块要求,去拆分自己的服务。一个单体服务会被拆分成更多的微服务,而微服务一旦变多,服务的拓扑链路就会变得非常复杂。


所以我们通过混沌工程主动去注入故障,主动发现隐患,比如把服务间的不合理的强弱依赖关系点发掘出来,让这个非常复杂的服务变得更有韧性。


全链路压测。传统的压测工具,就只是用来制造请求,作为压力源来用。我们做的全链路压测平台,在压测的过程中会同时描绘链路拓扑,同时把服务之间的放大倍数给计算出来。比如说,入口服务是1万的QPS,到了DB以后可能变成10万的QPS,也就是说放大了10倍。全链路微服务间的放大倍数,可以通过全链路压测平台的自动计算出来,这有助于我们更高效、准确的做容量评估。


通过这些平台建设,我们运维的天地会越来越广阔,不仅没有被淘汰掉,而且我们能做的事情会越来越多。


dbaplus社群还搜集了一些运维同学的痛难点,跟三位嘉宾一起探讨,下面来听听他们的答疑解惑:


Q1

传统运维在业务迅猛发展下,同时面临着领导不断下要求给指标,但人手不足、工具跟不上、平台不给力的困境和压力,您认为应该从何突围?是否有可参考的演进路线?




我确实经历过类似的场景,有段时间业务发展非常迅猛,运维这边人力确实跟不上了,但需求量就这么大,我们该怎么办呢?


当时我的想法是:主动地跟领导沟通。告诉领导,现在的人力确实不够了,能否申请加人力?同时,我这边也主动分析哪些需求是不合理的?是否可以把优先级调低?我们可以先把这部分低优先级需求挡一挡,给自己腾出一些时间,想一想有没有一些需求是可以做自动化、自助化的?


我们运维其实很多事情都是在打杂,在给用户做一些非常琐碎的事情,比如说帮忙查一个数据,导一份文件等等。这些事情其实完全可以自助化,我可以在企业微信里做一个机器人,做好机器人之后,业务同学可以在企业微信里面跟机器人聊天,给它发指令,让它把数据导出来,整个过程可以做到自助化了,不需要我们再去参与。


通过这种琐碎工作自动化方式,把大部分的时间和精力节省出来,去做更多自动化工具方面的建设。



吴老师分析得非常好,前面是加人力,然后看能不能解决,再就是分析自己的需求。大家常讲“事分轻重缓急”,你要先分析哪些更重要,然后先做关键部分,如果关键部分人力也排不开,那就要先实现最核心的功能。


先把当前的盘子稳住,有些东西要先有,然后再逐步去优化。今天我分享的几个实践,其实也有用到企业微信的机器人去自动化做一些事情,包括日常的巡检。你需要去看服务的质量,然后写巡检报告,这些都很麻烦。我们把它搞成自动化,那这样就可以释放出人力来了。要提取出哪些东西是更重要的,一定要看做的事情是否贴合着你的价值。


我们在公司里其实也有一定的行政手段,就是大家在讲的OKR。我们都在讲OKR,而我们的OKR其实紧贴着我们刚才说的:目标的三个价值点。围绕着这个来展开,就可以很大程度上避免做一些跟你的核心价值无关的事情。


另外,我们目前在做一个较为老生常谈的实践,但可能在运维工作里实践得不是很好,叫敏捷看板,这个可能在研发领域,尤其是西方那边用的比较多。


目前我们已经践行了几个冲刺周期,当然我们也是贴合OKR展开,然后去制定冲刺周期的。我们把日常的工作放到看板里,拆成不同的epic,然后思考整体要怎么排期。在一个大的看板里你可以看到,目前整个的人力的大盘的情况,哪些任务可以调一调?哪些需要往上提一提?我的进度怎么样?我要用什么办法来优化?这样就可以获得一个偏人力视角的大盘,就可以辅助你去做一些优化。



两位老师都分析非常得好,通过轻重缓急的优先级的调整,去满足领导下发的非常重要或者说非常紧急的指标。


我也给大家分享一下我的观点。拿京东来举例,领导不断地下指标、给要求,他的目的其实是降本增效。在京东内部,公司集团、部门比较多,就会出现这样一个情况:同样的技术栈、产品功能会有很多不同的部门来开发。所以我的观点就是:尽量避免重复性建设,把一些功能相似、技术栈相同的产品进行合并,减少不必要的研发成本,正所谓“力出一孔”。推动各个集团将自己的业务、技术向云看齐。


目前京东内部所做的一个非常重要的工作,就是所有的业务上云。通过云原生的技术,来加速京东各个业务应用的开发和交付效率,最终实现降低单位存储、计算成本、人力成本,提升整个企业的效率!


Q2

随着运维工具和平台的不断演进,容器、微服务、AIOps、混沌工程、云原生等新技术接踵而来,运维人员如何快速跟进和消化新技术?应该往“一专多能”还是“多专多能”发展?




相比之下,那肯定是“多专多能”更好,但在实践过程中,不管是精力还是投入都是很难。之前大家在讲T型人才——“一专多能”,后面又讲 π型人才。这在无形之中其实也给了大家焦虑感:你一专不够了,要多专才行。


在具体实践上,每个人都要有自己的定位,要持续地发挥长板,把自己的专项搞得精深,再去做横向拓展。至于说是“一专多能”还是“多专多能”,这要看个人的实际情况。如果我现在“一专多能”的“专”都做得不够,还想要去开多条战线,效果可能不见得会特别好,竞争力也不会特别强。


所以要看自己的能力,当然,如果你的学习能力、学习效率足够高,那当然是多多益善的,要视具体情况而定。



我非常赞同石老师的观点,特别是有一个点,我觉得很有感触,就是:回归业务价值。


“一专多能”?还是“多专多能”?需要根据所学的技能判断。现在云原生技术有很多,可观测、混沌工程等等。但所掌握的技术,对业务或者我们的服务到底有没有用呢?


如果我们发现,这个技术可以解决业务中的某一个难点,能够明显提升我们业务的质量,或者提升我们的效率,那这个技术我们就可以去学习、去落地,这应该也是业务方乐意看到的。


俗话说得好:不管白猫黑猫,能解决问题就是好猫。所以,不管是“一专多能”,还是“多专多能”,只要能解决业务上的问题,我们就应该把它在具体的业务场景里落地。



从管理的角度上看,在一个团队中,我希望底下的团队中的小伙伴是“一专多能”。当然这也因人而异,如果有的小伙伴的能力确实很强,那“多专多能”我们也是非常欢迎的。


如果不同的人在不同的领域或方向上,有非常“专”的一技之长,而我们通过组合的方式,将这些人组成一个团体。那这个团体就有了很强的研发能力,或者说解决处理问题的能力。所以,从这个角度来看,我倒觉得“一专多能”对一个团队来说,更有多元化发展的机会,也利于团队成员的职业发展。



对!可能“一专多能”大家还可以操作起来,但“多专多能”的话要求确实太高。



确实是因人而异。一个团队里不可能所有人都是特别优秀的、顶尖的技术人才,而应该是一个梯型的人才管理方式。高端的人才可能相对会少一点,中层的人相对比较多。所以,在这种人才的梯队建设中,我们不可能要求所有人都是“多专多能”的。


Q3

AIOps的实施应该先做场景还是先积累数据?几位老师在自己的实际工作中有没有什么感想?




AIOps这方面我们有一些具体的实践,目前主要用来做异常检测。比如,在服务出现问题时,会用到 AIOps的能力去定位它的根因。


在AIOps这一块,我们首先要做的是数据标准化。因为我们发现,当你要做AIOps时,最难的其实是数据的规范,不能出现太多的脏数据。因为基于脏数据算出的结果可以能会产生误导,所以我们首先做的就是数据的标准化。所有的上报、清洗、过程,全部按照规范去实施落地之后,接下来才是在具体场景铺开。



我坚定地看好AIOps这个方向,但我在这方面的实际的探索并不多,也仅限于一些比较基础常用的方面,主要集中在监控场景,就是异常检测、边检检测等,用一些常规的小算法,像是移动、加权等,去看一些突变点,做同比、环比这一类工作。


基于这些场景,我认为:首先,一定的数据标准化是肯定要做的。然后说到场景,以我浅薄的建设经验来看,这两个要素是相互推动的。AIOps的建设应该是一个螺旋上升的过程。可能你在建设的过程中发现:这个数据需要我去调整,然后在调整的过程中可能会延伸出更多的场景。


这方面我做的确实不多,还需要向两位学习!



我非常认同两位老师的观点:AIOps的实施是一个螺旋向上升的过程。


上文也有提到:整个运维的演进其实是人工手动、脚本化、DataOps到数字化、再到AIOps的不断迭代的过程。


所以,是先做场景还是先积累数据呢?大部分公司都是先有场景。在我看来,在手动阶段,或者说在脚本化、DataOps的阶段,场景就已经存在、已经积累出来了。在这些场景下,你不断去做的其实是数据标准化的一些事情;数据标准化之后,你会做一些数据的积累。当你有需求或者有意识要去做AIOps时,这些数据就是你的财富。


前面石老师也说过,大部分的运维场景下其实都是基于监控数据做智能基线、智能告警、根因分析这些方面的事情。在京东内部,我们其实也做了很多智能化的东西,无论是产品,还是工具,它们是服务于整个运维的链路的,大部分还是去做链路上的工作。


而这些东西的发展,可以推动AIOps不断迭代。在使用一段时间之后,你会发现:模型可能跟实际的业务有偏差时,拿历史积累的数据再去进行模型计算,如此反复,这种螺旋不断上升的方式,可以一步步的把AIOps推入成熟,推向下一个发展阶段。


如何适应云原生时代?被重塑的运维人需要具备哪些技能?想必大家看了三位老师的经验和见解,也有了自己的答案,也欢迎大家在评论区留下见解。


未来,云原生会和运维更加紧密,运维作为IT基础设施的管理者,在云原生时代的职能要求也将随之改变,将不再埋头于通过手工或脚本工具完成自动化特性,而应借助云原生平台的能力提供自动化运维系统。熟练掌握容器技术、基于DevOps打破与开发的屏障,并投注精力到AIOps能力建设中,是运维人员技术发展的重要方向。


再远一点,云原生会释放更多职责繁重的运维人力,自动化和系统化的特征会逐渐明显,在这个过程中,运维人员自身需要不断与时俱进,提升自己的核心竞争力。


与此同时,在云原生时代,运维团队的管理、企业运维体系的建设需要做出怎样的调整呢?下周五同一时间我们一起继续探讨。(未完待续……)


关注公众号【dbaplus社群】,获取更多原创技术文章和精选工具下载