作者简介：朱世祥，北京移动信息系统部技术运维中心产品经理、系统运维组。具有丰富的上域系统一线运维管理经验。今年，他带领团队打造技术运维能力，初步完成了北京移动业务支撑系统运维能力的自动化、智能化改造。目前致力于AIOps与运维中台体系的实践，以及运维开发团队的建设与管理。文章目录：背景介绍中台技术运营实践AIOps探索未来展望1.背景介绍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时代的到来作为一个很好的切入点，以及我们传统运维所面临的挑战，最终的总结可以让技术运维中心打通全领域的运维能力。2.技术运营平台什么是技术运营平台？其实分为技术运营+中台。首先，我们如何理解技术操作？技术运维和传统运维有什么区别？简单来说，技术运维不仅仅关注传统运维团队所理解的系统稳定性、系统安全等指标，还从运营的角度关注效率、客户体验等指标。那么我们对中国和台湾了解多少呢？第一，企业层面很重要。如果你是一个小团队，你自己做中台是没有意义的。前台轻，中台重，后台赋能，所以企业级很重要。您现在正在为企业中的所有应用程序团队和业务团队使用中间台。在5G时代的条件下，我们的中台必须面对B域、M域和O域，也就是我们的网络、IT系统等整体的考虑。第二，能力是中台的主要对象，应该和业务分开来梳理技术运维的公共能力。第三，复用是平台的核心价值，将平台与重复复用分离出来更细粒度。下面说说中台设计时的重点。这是一个从架构角度的简单分享。其实要做中台，需要将各个团队场景的重复构建能力和可复用场景抽象成统一的公共构建能力。举个简单的例子，其实我们的能力不止于此。过去有流程的业务平台，用户管理的平台，流量管理的平台。它们都在不同的平台上收集、传输、检测和管理数据。冗余就是重复。第一步，我们需要对各个运维建设能力进行逻辑抽象，并进行技术传递。这其实可能和微服务治理有一些类似的概念。第二步是复用能力。我们构建运维能力开放平台。首先，能力抽象完成后，需要在能力平台上进行注册，实现开放。比如B域和M域的不同场景，通过能力平台统一转换驱动后端。能力。同时，这也会带来运维团队职责和技能的转变。任何前端领域有需求的时候，团队管理能力需要看中台有什么能力来支撑你的场景。我要对运维做一个管控的能力。二是在能力开放平台上做一些场景运维分析，比如能力持续时间、动员量、成功率是否满足要求。如果不能满足要求，应及时提出，通知后端系统和能力进行改进。.这样，你的组织结构就会发生变化。你必须有一个有特定能力的技术团队，会基于技术平台做一些服务治理，所以你必须把控服务。第三步，中台搭建好之后，需要开放给第三方和其他团队，你要有一些灵活的服务能力。比如限流、隔离、断路器，就是控制中台能力的过程。我们确定了一个技术框架，还是体现在中台的分配逻辑上。我们把它分成了各种管理操作，我们在里面不断的补充我们的原子化和宣传能力，以便复用。本篇（见上图）讲的是技术运营中心如何设计思路的过程。每个团队在设计中台的时候，里面的东西的分类可能不是这样的，也可能组件不是这样设计的。原理是一样的，因为你是在给前台提供赋能和运营能力，所以你要同时管理和控制，这是一个核心原则。3、技术运营实践我们基于生态能力做了很多实际场景，这些都是基于中台能力的场景化。这个技术操作蓝图是我们团队在2016年提出来的，是从集团的标准化战略到省公司的全屋。正面是视觉的核心。同时，实现愿景要做什么，做这些事情需要什么样的保障。其实运维团队在传统上，在企业里，或者在自己的认知里，就是一个后台成本部门，不断的花钱，保证万无一失。我们团队一直在思考，技术运维和运维有什么区别？运营就是创造社会价值，这是信息部团队在2016年提出的蓝图，并在不断优化中。我们不是替别人顶罪，也不是替别人弥补。基于这一愿景，核心是确保业务满意度，开展风险防控。基于这些核心，进行分解，这些就是能力的分解。从标准化到自动化、可视化、智能化，这是我们的蓝图设计，我们的工作设置都是基于这张图来不断实现愿景的目标。第一篇讲的是CMDB。我们现在分享两点。CMDB的设计更加全面，我们做了灵活的定制。比如属性定制和模型定制，其实这两种场景不同，你的业务模型管理也不同，主要包括IaaS和PaaS。如果你是做软件版本管理的，你的模型分层是按照软件开发流程进行分支的，那么我们的模型是可以定制的，包括模型里面的属性关系，更加灵活。我们现在做的是一些简单的场景，因为拓扑是从资源盘点研究出来的。想要用好CMDB，必须要有流量和数据支撑，如何保证数据准确稳定？CMDB有两个来源渠道：第一，我们一个月改10000次，不能靠人工来保证准确性，我们后面会讲监控，这个是基于监控平台，我们会抓过来同步。其次，CMDB有自己的自我发现平台能力，也会独立收集系统运行的数据。我们会对不同的来源进行审计，并根据审计结果有一个分析和更新算法，以确保数据是更新的。第二部分是系统稳定性保障。这部分其实是核心，每个核心环节都有自己的痛点和思考。稳定性保障的核心是CMDB，即做好异常发现、分析定位、运行恢复等工作。在异常发现中，建立了监控体系，即运行对象、标准指标的定义和指标体系的实施。我们的指标包括内存利用率和处理时间等指标，这些附加指标是一个标准化的列表。例如，请求总量的属性包括采集频率和采集数据值的单位。还有一个门槛。我们将所有传统指标都基于我们自己的理解，例如服务器CPU的值。我们设定一个标准化的东西，形成一个清单。我们这样做之后有什么好处呢？首先，监控能力的标准化是指监控平台。标准化后，后台自动运行和时间反转进行全局编码。稍后，您需要知道哪些功能受到监控。你只需要看看列表就知道如何返回就可以了，这就是能力的标准化输出。二是数据质量治理精细化。我们将找出系统中哪些对象没有被监控。在运维生产过程中，我们发现可能有100台主机被监控，但是其中80台可能没有完整的监控指标，所以当其中一台主机的内存率很高时，是没有办法发现异常的,因此对象被细化到指标级别。我不仅要看每台主机是否up，还要看是不是黄金指标。如果有一点不同，那就是不完整，我们监控点采集的细粒度已经变成了一个指标级别。监控有制度、有规范、有门槛。您所有的监控动作都基于运行数据。如果将数据作为原始数据的一部分进行采集，将会形成非常标准的运维数据。我们都是根据这个数据来细分的。三是团队转型赋能。以前监控组是一个被动响应的过程，不知道大家有没有？监控系统建成后，将成为主控团队。你上线的时候要95个单位。我想看看有没有这么多基于CMDB的？如果没有，它不会让你上网。我们还可以分析和输出操作风险。过去，监控平台做不到这一点。我只是建造它。你告诉我要监控什么，我可以为你做。的风险。基于这一点，我们对我们的团队进行改造和赋能，就会达到这样的效益。四是全链路监控。传统的开源APM产品都是基于后端链接。我们实现了业务端到端的全链路监控。说完业务，我们就进入用户体验页面。其实技术上的复杂度不难，但就是个问题。管理场景的思想得到体现。这样做之后有什么好处呢？我能看到业务从最开始到最后的流程，会带来运维的一些改造。如何将发展与转型相匹配？第一，如果运维团队是架构管控团队，那肯定是被埋没了。我有一个规范的规范方法，你要根据这个埋点做这种识别，就是实现我们的流程和技术的一个衔接。第二，我们有三个下钻，分别对应不同的人员：第一个下钻对应业务经理，可以知道每个业务流程的节点是什么；第二个下钻是集群实力和具体指标，这些对应到平台应用人员，你要看集群业务的实力，甚至他现在的数据和状态是否完好；第三，下钻看到每个单单的业务链条，这个就是对应的Developers，看到问题的时候是某个方法有问题，方便开发人员处理。我们的三个深入分析旨在满足不同的管理者并基于不同角色的需求。.五是应急响应闭环管理。我们做了比传统更横向的扩展，这跟知识库和自动化运营平台有关。我们的技术操作标准提出了更清晰的管理。对责任部门原因、整改措施是否落实有详细要求。这些要求也需要在系统中实践。您将提出一些纠正措施。这些措施将被跟进。进程也需要覆盖在节点上才能打通。六是运维秘密赋能。我们在处理故障的时候，会有一个故障应急响应微信群，领导、业务人员、各种故障人员都会往里面发很多信息。我们将同步一个小秘密机器人。当突发故障上报需要收集信息时，运维秘会自动汇总信息。它只要判断有故障就可以直接总结出来。当一、二、三线的处理会涉及流转问题，那么运维秘书直接处理，然后在审核过程中形成报告。第七，分析定位是链接分析。这也是基于对服务的全链路监控来实现的。第八，智能根因分析。之前看过广发证券分享的一个主题。你的数据很多，但是你的数据的组合形式和展示内容对故障排除的效率有很大的影响。这张图左边的统计分析不是AI过程，不是智能过程。这样，在显示出故障范围和故障原因后，就可以清晰直观地看到故障原因和当前情况。这张图把传统信息和智能分析过程放在一起，形成一个完整的视图，会带来“1+1大于2”的结果。第九，运营恢复是平台层面的支持。我们已经成为支持场景的原子组件，在故障分析和回放时恢复轨迹对我们来说非常重要。第十，自动化计划策略。我们中心的核心价值就是实现应急策略的配置，那么什么是策略呢？策略就是根据什么样的异常场景，执行什么样的规则，这个规则就是策略。比如限流断路器里面的算法都是正则化的，我们现在已经实现了接口化配置。4.AIOps探索首先我们来说说功能架构。如果你熟悉大数据，就是处理层和基础组件。我们从去年年底到今年引入了AIOps。我们现在离线和在线都使用Flink。下面说说学习软件的概念。大家应该都听说过学习软件这个概念。我们如何理解北京移动的学习软件及其实用价值？它是指以前API的标准化接口。学习软件就是将数据和算法结合起来，综合成一个完整的学习软件。下次来相同场景、相同指标类型的数据时，可以调动相同的学习软件。当你想达到使用技术的效果时，你必须根据值做很多调整。我们如何解决它将成为一个学习的部分。比如我们第一次调算法的时候，指标会很好。如果下次有新的指标，可以直接复用，因为你已经按照周期调好了，所以直接效果会更好。如果同一个算法用原来的算法做指标，你计算出来的指标和复用的指标是不一样的。今天上午，浙江移动提出了学习件的可视化过程。在我们这边，整个学习件的生产过程也是可视化的。你需要一个数据源，你还需要配置指标，然后进行算法训练，最后实现复用。异常检测分析。我们在里面做了算法应用、实际效果和根本原因分析。我们首先会根据拓扑结构确定异常现象的范围，然后进行系统分析。同时，我们会对一些非告警资源指标进行多变量分析，最终汇总后计算出一个列表。5、展望5G时代，5G技术生态圈不断扩大。对于我们5G时代的运维团队来说，5G在提供传统行业或者创造新行业的同时，新覆盖的行业也需要系统运维和技术运维。尽管这些行业的业务和运营模式可能千差万别，但核心能力是不会变的。所以，如果中台在适配过程中，会基于中台所有不同的行业进行赋能，最不变的核心Stuff留在下面支持。这是我们今年刚建立的中台，我们对未来的演进模式有一些思考。一是服务运营。随着生态圈的扩大，可以提供更多的场景，场景可以千变万化。中台是一个适应一切变化的过程，需要积累更多的通用运维能力。二是中台运营。参考主流技术的发展，在我们的容器技术出现之后，逐渐发展起来的容器管控平台如K8S。这些平台本身都有自己的管理、调度等节点，可以实现容器和资源的灵活调动。所以，未来的中台应该具备并加强这样的管控调度能力，甚至达到智能编排适配的水平，即用智能技术自动分析场景需要哪些运维能力，如何组合它们等
