运维怕是要凉了？？？丨话题接力

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

这显然不是简单两句就能下的定论，我们首先需要认清：云原生时代的基础设施有什么变化？能解决什么问题？运维人员应该重点关注什么？传统运维如何向云原生运维转型？容器化、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能力建设中，是运维人员技术发展的重要方向。

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

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