从技术运营中台建设到AIOps实践，看着一篇就够了

文章来源：51cto朱世翔

?作者简介：

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

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

文章目录：

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

一、背景介绍

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

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

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

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

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

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

第一个挑战，传统的运维系统是按照烟囱式进行建设的，按域来划分有业支运维（B域运维）、网络运维（O域运维）。

业务运维就是业务支撑系统运维，就是平时订购流量包的套餐计费完成，是基于传统的IT 系统技术栈来完成这个过程。

而网络运维，是围绕网络设备的运行状态进行，保障的是我的基站是不是有信号等，这是网络设备的运维。不同域的运维，甚至同一个域内不同的运维系统，在系统能力建设上也是隔离的过程。

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

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

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

第四个挑战，网络运维开始引入了IT技术，CT领域开始跟IT融合，所以会导致运维模式、生态圈发生一个比较大的变化。

那么，5G时代 ICT 融合的背景下，运维能力是可以进行赋能的。第一，网络运维软件化之后可以随着技术引入，可以向 IT 领域进行发展。

同时5G时代的网络切片更加灵活，可以对不同行业不同场景提供支撑，所以对网络需求的交付速度提出了更高敏捷要求。所以网络域运维需要有一个持续交付以及一个敏捷的过程。

因此搞 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的值，我们定了一个标准化的东西，形成了一个清单。

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

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

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

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

我们还可以做运行风险的分析和输出，以前监控平台是做不到这块的，我只管建，你告诉我监控什么我就可以给你做，但是没有介入业务，也不知道在系统运维的风险。基于这一点使我们的团队进行转型做赋能，就会达到这么一个好处。

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

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

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

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

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

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

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

第七，分析定位是链路分析。这个也是基于业务全链路监控来实现的。

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

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

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

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

四、AIOps 探索?

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

再说一下学件概念，学件的概念大家应该都听过，在我们北京移动是如何理解学件和它的实践价值呢？就是参照以前的 API 做了标准化接口，学件就是把数据和算法合在一起，合成了完整的学件，在下一次同样场景、同指标类型数据来的时候，就可以调动同样的学件。

你要想达到使用技术效果时，你要根据值做大量的调优，我们怎么把其沉淀下来，就会变成学件。

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

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

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

五、未来展望

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

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

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

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

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

因此，中台的未来，应该是具备和加强这样的管控和调度能力，甚至是达到智能编排适配的程度，也就是用智能技术来自动分析场景需要什么运维能力，怎么组合等。

发表于: 2020-01-082020-01-08 09:44:00
原文链接：http://news.51cto.com/art/202001/609032.htm
如有侵权，请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长进交流群

领取专属 10元无门槛券

私享最新 技术干货

从技术运营中台建设到AIOps实践，看着一篇就够了

一、背景介绍

二、技术运营中台

三、技术运营实践

四、AIOps 探索?

五、未来展望

相关快讯

扫码

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐