作者简介：

朱世翔，北京移动信息系统部技术运维中台产品经理、系统运维组主管。

具备较丰富的运营上部域系统一线运维管理经验，今年带领团队进行技术运营能力的建设，初步完成了北京移动业务支撑系统运维能力自动化、智能化转型。目前致力于AIOps和运维中台体系实践、运维开发团队构建和管理。

文章目录：

• 背景介绍
• 技术运营中台
• 技术运营实践
• AIOps 探索
• 未来展望

一、背景介绍

5G商用启动开始，三大运营商正式推出了5G套餐，5G是下一代通信技术，那么5G时代来了之后同样需要下一代运维。

我们就对下一代运维是怎么理解呢？其实当 5G 来了之后，我们理解是有两个新的要求：第一，我们面临的一些场景会变得复杂化，对原有运维能力的要求也更高了。第二，5G 来了之后运维边界也是不断拓展的。

第一点怎么理解呢？大家可以思考一个问题，我们运营商和互联网行业、金融行业核心提供业务形态是不一样的。

比如，一个电商企业提供了业务形态把产品卖好，可以在网站上完成购物，金融行业是围绕钱提供一些服务，我们的运营商核心服务形态是资源，包括语音、流量等，这个业务形态有什么样的特点呢？流量和资源服务每时每刻都在不断变化的，所以在这个过程当中给客户提供一些什么样的运营服务呢？会有例如流量提醒等。

我们的团队会做一些流量及时性保障，这是我们的运维核心工作之一。我们原来的东西是在变化的，因为 5G 已经变化更快了，要保障客户进行实时提醒的难度在增大，要求更高。

第二，运维的边界要进行拓展。那么，拓展方面的是什么挑战呢？

第二个挑战是提供端到端服务时，没有办法提供端到端的运维保障服务。举个例子，有一天用户手机正常时没有办法上网是什么情况呢？有可能是IT系统的计费出错了，导致停机了没有办法上网了，有可能是网络设备故障导致没有网络信号了，导致无法上网。

我们传统运维响应特点就是各查各的，整个核查过程是比较长的，同时效率是比较低的，反映不及时，就会带来不好的用户体验感。

第三个挑战，我们是如何看待运维技术的发展和升级呢？实际上我们理解运维能力升级更新围绕运维对象的技术变化而发生变化的，随着运维对象引入云计算、容器等，导致运维技术和要求需要随之迭代升级。 

基于 5G 时代到来这么一个很好的切入点和我们传统运维面临的挑战，最后汇总到一起可以让技术运营中台，打通整个全领域的运维能力。

二、技术运营中台

什么是技术运营中台？其实分为技术运营+中台。 

简单来说，技术运营不仅关注传统运营团体理解的系统稳定、系统安全等指标，还会从运营角度去关注效率、客户体验等指标。

那么我们对中台理解是什么的呢？

第一，企业级是很关键的，如果你是一个小的团队，你自己做一个中台是没有意义的。前台是比较轻，中台比较重，后台是赋能的，所以企业级是很重要的，你现在是给企业里面的所有的应用团队和业务团队使用你的中台。

在5G时代条件下，我们的中台要面向B域、M域和O域，就是我们的网络、IT系统等全局来考虑问题。

第二，能力是中台主要承载的的对象，要从业务中抽离出来，梳理技术运营的公共能力。

第三，复用是中台的核心价值，要去重早复用对比平台更细粒度的抽离。

举个简单例子，其实我们的能力是不止这些的，在以前流程有一个业务平台，用户管理有一个平台，流量管理有一个，他们都在不同平台对数据进行采集、传输、检测、管理，这些冗余都是重复的。 

第二，他们在能力开放平台去做一些场景运维分析，比如说这个能力时长、调动量、成功率是不是满足要求，如果不能满足要求要及时提出，去通知后端系统和能力去进行改进。 

三、技术运营实践

我们基于生态能力做了很多实践场景，这些都基于中台能力做了场景化。  

我们现在做了一些简单场景的东西，因为拓扑是从资源盘点来进行研究的。如果你想用好CMDB必须要流量和数据支撑，怎么保障数据是准确和稳定的呢？CMDB有两个来源渠道：第一，我们每个月变更次数是在1万次，你没有办法靠人工去做准确性，我们后面会讲到监控，这是基于监控平台做的，我们都会抓过来同步过来。

第二，CMDB自己有自发现平台能力这个也会独立采集到系统运行的数据，我们会对不同信源进行一个稽核，基于稽核结果有一个分析和更新算法，来保证数据是更新的。

第二块讲一下系统稳定性保障，这块其实是核心，在每个核心环节都有自己的痛点和思考。稳定性保障围绕核心就是 CMDB，也就是要做好异常发现、分析定位、操作恢复。

在异常发现做了一个监控体系，就是运营对象、规范指标定义和指标体系落地。我们的指标有内存运用率、处理时长等指标，这样的对于加指标是一个标准化清单。比如说，请求总量的属性包括采集频率、采集数据值是什么单位。

还有一个是阈值，我们把所有传统的指标基于自己的理解来做，像服务器CPU的值，我们定了一个标准化的东西，形成了一个清单。 

第二，数据质量治理精细化。我们会发现系统里面哪些对象没有进行监控，我们在运维生产过程当中发现100台主机可能监控上了，但是其中80台可能没有完整的监控指标，那么其中一台主机的内存率高的时候是没有办法发现异常的，所以从对象细化到了指标级别。我不仅仅要看每台主机是不是上去了，还要是不是黄金指标，如果差一个就是不完整的，把我们监控点集合的颗粒度精细变成了指标级别。

监控是有体系、编码、阈值的，你所有监控动作都是围绕运行数据来做的，如果数据采集之后就是原数据的组成部分，就会形成很标准的运维数据，我们都是基于这个数据来做细分。

第三，团队转型赋能化。以前监控团队是一个被动响应过程，我也不知道你是不是全了呢？当做了监控体系之后就会变成主控团队，你上线时提出说要95台，我要基于CMDB看是不是这么多？如果不是的话就不让你上线。 

第四，全链路监控。传统的开源的APM产品是基于后端链路抓出来的，我们实现了业务端到端的全链路监控，既然到了业务就到用户体验的页面，其实这个技术复杂性不难，但是是一个问题管理场景的思路体现。这样做完之后形成什么好处呢？我能看到业务从最开始的环节到最后环节的流转过程，这样就会带来一些运维改造。

你怎么让开发配合改造呢？ 

第六，运维小秘赋能。我们在处理故障时会有一个故障应急响应微信群，领导、业务人员和不同故障人员会把好多信息发进去。我们会把一个小秘机器人实现了同步，当突发故障报时需要收集信息，运维小秘会自动汇总信息，它只要判断有故障就可以直接汇总。当一二三线处理时会涉及到流转问题，那时运维小秘就会直接进行处理，然后在复盘环节就会形成报告了。   

第八，智能根因分析。之前看过一个广发证券分享的主题，你的数据很多，但是你数据组合形式、展示内容对故障处理效率是有很大影响的。

这张图左边统计分析都不是AI过程，不是智能过程，这样展现之后从故障影响范围、故障的原因层层递进，就可以很清楚直观看到故障的原因是什么，现在是什么情况。这张图把传统信息和智能分析过程放在一起形成一个完整的视图，就会带来一个“1+1大于2”的结果。

第九，操作恢复是平台级的支撑。我们变成了原子化组件来支撑场景，我们在故障分析、复盘时轨迹恢复是非常重要的。   

四、AIOps 探索 

比如说，我们在做第一次调适时，把算法调优了，指标就会很好。如果下次有新的指标就可以直接复用，因为你根据周期性做了调优，所以就会直接有比较好的效果。如果同样的算法用原始算法做了指标，你算的指标和复用指标是不一样的。

今天上午浙江移动提出了学件可视化过程，在我们这边整个学件制作过程也是有可视化的，你要有一个数据员源，你还要配置指标，再进行算法训练、最终实现复用。

异常检测分析。我们在这里面做了算法应用、实践效果、根因分析。我们首先会基于拓扑拿到异常现象先做一个确定范围再做系统分析，同时把一些非告警的资源指标做多元分析，最后汇总之后计算出来一个列表。

五、未来展望

5G时代，5G本身技术的生态圈在不断拓展，对于我们的运维团队在5G时代，当5G给传统行业或者创造新生行业时，新覆盖行业同样需要系统运维和技术运营。

尽管这些行业的商业和运行模式可能是千差万别的，但是核心能力永远不变，所以还是说中台如果是在适配过程当中，基于中台所有的不同行业进行赋能，把最核心不变的东西保持下来进行支撑。

这是我们今年刚刚建立起来的中台，我们对未来的演进模式有一些思考。

第一，服务运营。随着生态圈的扩大，可以提供更多场景，场景是可以千变万化，中台是以不变应万变的过程，需要去沉淀更多共性的运维能力。第二，中台运营。

参照主流技术的发展，当我们的容器技术出现之后，K8S等容器管控平台逐步发展起来，这些平台本身有自己的管理、调度等节点，就可以实现对容器和资源的灵活调动。