面向5G的技术运营中台实践和AIOps探索

彭小阳

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

一、背景介绍

今年11月1日是商用的启动开始，明天就推出了5G套餐，其实就是说5G时代来了之后需要下一代运维，因为5G、4G是一个延续的过程。

我们就对下一个运维是怎么理解呢？其实当5G来了之后，我们理解了两个大点:第一，我们的能力、我们的实质性要求以及一些场景会变得复杂化，对能力的要求也更高了。第二，5G来了之后运维边界是不断拓展的。

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

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

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

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

第一个挑战，我们的运维系统分为一个烟囱式的建设，有信软运维。业务运维就是业务支撑系统运维，就是平时订购流量包的套餐计费完成，是传统的IT系统站完成这个过程。我的基站、宽带没有信号的，这是网络设备的运维。在传统电商行业里面烟囱是隔离的，系统能力建设上也是隔离的过程，这就是所说的闭门造车了。

第二个挑战是提供端到端服务时，没有办法提供保障服务。举个例子，有一天用户手机正常时没有办法上网是什么情况呢？有可能是计费出错了，导致停机了没有办法上网了。如果是用户面临再投诉时，我们传统响应特点就是各查各的，我们整个过程反映的是比较长的同时效率是比较低的，反映不及时，就会带来不好的用户体验感。

第三个挑战，近几年的生态社区都是在围绕运维对象发生变化。
第四个挑战，网络运维开始引入了IT技术，CT领域开始跟IT融合，所以会导致运维模式、生态圈发生一个比较大的变化。

5G时代ICT融合运维可以进行赋能，网络运维软件化之后可以随着技术引入，可以向IT领域进行发展，我们的切片更加灵活，可以对不同行业提供不同的运维技术，所以需求交付速度提出了更高敏捷要求。

所以网络域运维需要有一个持续交付以及一个敏捷的过程。所以，就是说总5G时代发生开始，我们提到的挑战在4G时代已经存在了，为什么没有好的切入点解决呢？因为搞IT运维的发现网络运维开始需要IT运维能力，因为系统架构和5G网络特点导致他们需要IT运维的能力，这时候发现我们的IT运维是可以赋能的。因为从一开始的建设就在紧跟IT变化，所以说从移动开始就做了基于IT的技术战。

基于这个切入点，我们可以看到ICT融合进行过程。我们的IT运维有之前的ITOA、ITOM等，我们是从技术主管到DevOps平台，以前的网络特点是电子工单，但他们的网管系统是非常好的。在5G时代技术开始进入了软件化时代，这两个可以逐步融合了，可以建设一个灵活可用的平台，来赋能促使CT和IT平台进行融合。基于5G时代的切入点和面临的挑战，最后汇总到一起可以让技术运营中台，打通整个全领域的运维能力。

二、技术运营中台

什么是技术运营中台？简单来说，不仅关注传统，可能传统的运营团体理解的系统稳定、系统安全的指标是很多的，从技术角度去关注、体验效率的指标。

我们对中台理解是什么的呢？第一，企业级是很关键的，如果你是一个小的团队，你自己做一个中台是没有意义的。前台是比较另，中台比较重，后台是赋能的，所以企业级是很重要的，你现在是给企业里面的所有的应用团队和业务团队使用你的中台。在5G时代条件下，我们的中台要面向B域、M域和O域，就是我们的网络、IT系统等全局来考虑问题。

第二，能力是中台主要承载的的对象要从业务中抽离出来，梳理技术运营的公共能力。第三，复用是中台的核心价值，要去重早复用对比平台更细粒度的抽离。

我们讲一下设计中台时的关键点，这是从架构方面做的简单分享。其实你要做一个中台，你要把各个团队场景的重复建设能力和重复用的场景抽象出来，做成一个统一的公共组建能力，这是一个例子。其实我们的能力是不止这些的，在以前流程有一个业务平台，用户管理有一个平台，流量管理有一个，他们都在不同平台对数据进行采集、传输、检测、管理，这些冗余都是重复的。
第一步，我们要把各个运维建设能力要做一个逻辑上的抽象，做一个技术上的传输，这个其实可能跟微服务治理有一些类似的理念。

第二步，能力复用。我们建设一个运维能力开放平台，首先抽象出来的能力把做好之后，需要注册在能力平台上实现开放，比如说B域、M域不同场景是通过能力平台做一个统一的转换来带动后端能力，这个也没有特别多，我们有一个团队会做能力建设。

当前端不管是哪一个领域有需求时，团队治理能力需要看的是中台有哪些能力支撑你的场景，我要做对运维能力做一个管控。第二，他们在能力开放平台去做一些场景运维分析，比如说这个能力时长、调动量、成功率是不是满足要求，如果不能满足要求要及时提出，去通知后端系统和能力去进行改进。这样你的组织架构就会变化点，你要有一个特定的能力技术团队，会基于技术平台做一些服务治理的事，所以必须对服务进行管控。

第三步，做了中台之后，需要给第三方和其他团队进行开放，你要有一些柔性的服务能力。比如说，对其进行线流隔离、熔断，这个是中台能力管控过程。我们确定出来了一个技术框架，这块还是体现在中台分配逻辑，我们分成了各种管理操作，我们在里面不断补充我们的原子化、公共化能力做复用。

这块讲的是技术运营中台怎么做设计思路的过程，每个团队做中台设计时里面的东西分类不一定是这样的，或者组件不一定这么设计，原理是相通的，因为你是给前台去提供赋能和运营能力，所以你同时要进行管控，这是一个核心原则。

三、技术运营实践

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

这个技术运营蓝图是我们团队在2016年提出来的，是从集团规范战略到省公司落地全画房子，前面是愿景核心，同时达到愿景做什么事情，要做这些事情需要做什么样的保障。其实运营团队传统里面、企业里面或者自己本身认知里面是一个后端成本部门，是在不断花钱保障不出事。

我们团队在不断思考，技术运维和运营的区别是什么呢？运营就是可以创造社会价值，就是信息部团队在2016年提出的蓝图，这中间也在不断优化，我们不是在去替别人擦屁股，不是给别人补漏。基于这个愿景提出了核心，就是要保障业务满意，要进行一个风险防控。基于这些核心做了分解，这些是能力的分解。从标准化到自动化、可视化、智能化，这样是我们一个蓝图设计，我们的岗位设置都是围绕这张图不断满足愿景的目标。

第一块讲一下CMDB。我们现在分享两个点，CMDB设计时想得比较全面，我们做了一个灵活自定义。比如说属性自定义、模型自定义，其实这两个场景是不一样的，而你做业务模型管理也是不一样的，里面主要就是IaaS和PaaS的东西。假如说做一个软件版本管理时，你的模型分层是根据软件开发流程有分支的，那我们的模型是可以自定义的，包括模型里面的属性关系都是自定义比较灵活的。

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

第二块讲一下系统稳定性保障，这块其实是核心，在每个核心环节都有自己的痛点和思考。稳定性保障围绕核心就是CMDB，也就是要做好异常发现、分析定位、操作恢复。在异常发现做了一个监控体系，就是运营对象、规范指标定义和指标体系落地。我们的指标有内存运用率、处理时长等指标，这样的对于加指标是一个标准化清单。比如说，请求总量的属性包括采集频率、采集数据值是什么单位。

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

我们做这个事之后有什么好处呢？第一，把监控能力规范化，是指监控平台，把其变成标准化之后，给后端自动化操作、时间扭转进行了全局编码，后面是要知道监控了哪些能力，只需要看清单就知道怎么回事了，这是把能力进行了规范化输出。

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

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

第三，团队转型赋能化。以前监控团队是一个被动响应过程，我也不知道你是不是全了呢？当做了监控体系之后就会变成主控团队，你上线时提出说要上多少，我要基于CMDB看是不是95台？如果不是的话就不让你上线。我们还可以做运输风险和输出，以前监控平台是做不到这块的，我只管建，你告诉我监控什么我就可以给你做，但是没有介入业务，也不知道在系统运维的风险。基于这一点使我们的团队进行转型做赋能，就会达到这么一个好处。

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

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

第一个，如果运维团队是架构管控型团队，必须要买点（音）。我有一个标准化规范方法，你必须按这个买点（音）做这样的识别，是把我们的流程和技术实现了一个打通。

第二个，我们有三个下钻，并且它们分别对应了不同人员：第一个下钻对应业务人员，可以知道每个时点是什么；第二个下钻到集群实力和具体指标，这些对应的是平台应用人员，需要看集群业务下面的实力，甚至他现在的数据和状态是不是完好的；

第三个，下钻看每个单体的业务链，这块是对应的开发人员，当你看到有问题时是某一个方法有问题，这样就可以方便开发人员进行处理，我们三个下钻是满足了不同的管理者，因为角色需要去做这么一个设计。

第五，应急响应的闭环管理。我们比传统做了一个更横向的拓展，纵向这块本身不是要存在流程流转过程，还要进行故障分析和帮助，这块关联了知识库和自动化操作平台。我们的技术运营标准提出了一个更清晰化的管理，要对责任部门原因、整改措施是否落实有了细化要求，这些要求也需要在系统上进行实践，你会提出一些整改措施，这些措施后续流程也需要覆盖在节点上进行打通。

第六，运维小秘赋能。北京移动基于历史原因有一个特点，我们在处理故障时会有一个故障应急响应微信群，会把好多信息发进去。虽然那个事件流程是在扭转的，但是领导关注是群里面的信息，我们会把一个小秘机器人实现了同步，当突发故障报时需要收集信息，运维小秘会自动汇总信息，它只要判断有故障就可以直接汇总。当一二三线处理时会涉及到流转问题，那时运维小秘就会直接进行处理，然后在复盘环节就会形成报告了。

第七，分析定位是链路分析。

第八，智能根音分析。之前看过一个广发证券写的文章，你的数据很多，但是你数据组合形式、展示内容是有很大影响的。这张图左边统计分析都不是AI过程，不是智能过程，这样展现之后从表现范围、实现原因层层递进，就可以很清楚直观感受到原因是什么，现在是什么情况。这张图把传统信息和智能分析过程放在一起形成一个完整的视图，就会带来一个“1+1大于2”的结果。

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

第十，自动化化预案策略。我们这个中心配的就是策略，什么是策略呢？什么样的异常场景去做什么，这就是策略。比如说，线流熔断里面的算法都是有规则的，我们现在已经实现了界面化配置了。

四、AIOps探索

首先说一下功能架构，如果大家对大数据比较熟悉的话就是处理层和基础组建。我们从去年年底到今年引入了AIOps来做。我们现在离线和在线都是用Flink来做的。

再说一下学件概念，如果大家进行探索的话是可以看到的，什么叫做学件呢？就是参照以前的API做了标准化接口，学件就是把数据和算法合在一起，合成了完整的学件，在下一次同指标类型来的时候可以调动同样的学件。你要想达到使用技术效果时，你要根据值做大量的调优，我们怎么把其沉淀下来，就会变成学件。

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

今天上午移动提出了学件可视化过程，我们整个学件制作过程也是有可视化的，你要有一个数据员和探索，你还要配置指标，再进行探索、复用。

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

五、未来展望

5G时代就是5G本身技术的生态圈在不断拓展，对于我们的运维团队在5G时代，当5G给传统行业或者创造新生行业时，需要系统运维和运营。尽管呈现模式可能是千差万别的，但是核心能力永远不变，所以还是说中台如果是在试配过程当中去基于中台所有的不同行业进行赋能，把最核心不变的东西保持下来进行分析。

这是我们今年刚刚建立起来的中台，我们有一些思考。

第一，服务运营。随着生态圈的扩大，可以提供更多场景，场景是可以千变万化，中台是以不变应万变的过程。第二，中台运营。当我们的容器技术出现之后逐步引进管控平台，因为本身有自己的节点，就可以实现一个容器的调动。同时，在使用过程中，它会用智能告诉你这个场景需要什么样的能力，需要什么样的调度。