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

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

观点一：从传统运维到云原生运维是一个持续迭代、不断进化的过程。我们的运维从传统的手动运维到脚本化、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倍。全链路微服务间的放大倍数，可以通过全链路压测平台的自动计算出来，这有助于我们更高效、准确的做容量评估。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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