传统的网工将消失?运维的出路在这里

805 阅读19分钟
原文链接: mp.weixin.qq.com

何维兵 | 腾讯网络平台部基础架构运营负责人

本文为腾讯何维兵老师在 GOPS 2018 · 上海站的分享,以下为分享内容:

做运营的同学,都有同样的感受,既希望被老板关注,又不希望被老板关注!因为觉得被老板关注时,常常是没什么好事发生。

记得微信红包兴起时,有一次我们网络运营就有幸得到了老板的特别关注!那一次刚好是微信年会,老板现场想发一个红包给大家,结果红包没发出去,因为网络出故障了,你们能想象到当时有多尴尬。

我们做这么重要的支付业务,这么关键的场合居然掉链子了。

随后老板找到我们提了需求,三分钟恢复,大家觉得这个需求怎么样?不能说不好,需求是对的。

我们来分析一下这个需求,这是截取的一些公开资料,大部分互联网公司都差不多,从A端到B端的访问路径算了一下,大概经过 32个网络结点,中间路径1000 条。

这么多路径、这么多节点,三分钟时间内搞定这些问题还是挺有挑战的。

刚才说了需求是合理的,老板的方向也是对的。

于是我们启动了一个项目,黑镜1.0:网络故障智能定位,尝试解这个需求。

运营工作最核心的就是处理好突发故障,故障最主要的就是三个阶段:发现、定位、恢复。

我们的出发点是:围绕着这三个阶段,看看每个阶段能做哪些事情或提升!

我们总结了一下思路,称之为“3M大法”。

  • 首先把自己的眼睛擦亮,我们通过 Meshping 的方案做了高精度的监控感知系统。

  • 第二,基于以往故障的经验总结哪些东西是跟故障强相关的因素,我们定义为Multi-KPI的体系,通过这种方式我们来定位故障。

  • 第三,我们会把所有的冗余组件封装好,用的时候直接调用组件Moveout故障点。

第一个Meshping探测,这个东西原理并不复杂。

我们以前网络上自身做了很多设备的监控以及采集,但是我们发现一个问题,每一次故障的时候,很多故障的时候都是业务先找到我们,我们没有感知到异常情况发生!

业务说:你们坐着干什么?

确实,我们7*24小时坐在NOC监控中心,也没有发现问题,都是业务找到我们,我们在干啥呢?为什么出现这样的情况呢?

业务非常多,它分布的太广了,它的敏捷度远远比我们高。那我们就像,干脆我们就从业务的角度监控,我们就拿机房的海量服务器去做这样的事情。

其实很简单,就是选取一部分机器作为探测对象,然后机器之间交叉探测。

听起来很简单,但是你要达到既能覆盖所有的路径,同时也在一定的时间之内,高效的把结果计算出来,并且达到高精度的报警,这还是很有挑战的,这件事情做了三年还在做。

一方面要解决海量 ping 侧任务和结果的计算,我们还把中间的探索路径记录了下来,这么多的样本记录下来挑战也很大,我们当时做的时候也缴了一些“学费”,我们把设备搞坏的情况也出现过

而且我们也发现探测的时候,包括探测模式需要不断的丰富。

初期我们就是基本的ping的探测,随后我们发现一些故障场景中,还需要更丰富的探测元素,比如说大小包的组合、QoS标记组合、UDP资源探测等等,我们现在还在持续的优化我们的这个 Meshping 探测方案。

做完这个事情之后,我们确实把“眼睛”擦的很亮。

这是真实的数据情况,可以敏锐捕捉到网络上大小事情的发生,比如:端口的down、TE路劲切换延迟变化,所以它的准确度非常的高。

第二个就是我们做的 Mulit-KPI 指标系统,这个的话其实也不复杂,只是说我们反思了以前的做法。

以前很多时候查故障想问题的时候,都要有很多的细节,你非要把问题找到,你找到问题的点需要花大量的时间分析数据、找线索,几乎都是人做的。

就像上面提到的从那么复杂的一个路径中,串行的执行那么多的分析工作,你时间非常的慢,基本上很难在很短的时间内定位故障的来源。

所以后来我们不找细节的东西了,我们就去找什么东西能够代表它的故障,或者说哪些趋势变化更故障强相关,我们就把这些东西找出来。

比如我们中的其中一个KPI指标:

设备转发效能比,这个是基于包量守恒原理,设备正常工作的情况下,入包量和出包量应该基本相当(二层环境除外)。

我们基于这个原理把所有的设备上的入和出的数据包采集出来。

大家可以看一下这个数据,这是真实的数据,平时是很稳态的,但是故障发生后,这个曲线会有明显的突变。

我们就把这样的类似的趋势变化,定义为故障关联的KPI指标,这些指标不一定要多,但一定要准确和故障关联。我们通过强相关趋势的变化,我们就不关注细节,关注细节你也找不清楚。

整个我们这一套定位平台框架大概是这样,有三个重点组成部分。

  • 第一个就是我们的探测和路径的采集

  • 第二种就是KPI的计算

  • 第三个就是隔离和屏蔽的组建封装,通过这三种方法就可以快速的完成故障的发现、定位和恢复

其中故障定位的原理也很简单,我会把所有的探测的流采集出来,记录下来探测流的路径,通过这些异常流的特性锁定一批设备,然后对这些设备我会计算KPI指标,通过KPI指标的叠加我就能看到谁是最可能的故障点了。

第三个是 Moveout 隔离屏蔽。我们对所有的网络冗余组件做了屏蔽操作的自动化封装。

有些不具备屏蔽的条件,我们也会设置一些静默的通道放在这里,平时不用,需要使用的时候就开启它。所以至少核心的层的组件都具备“逃生”的能力。

这是我们通过刚才这一整套思路做完了之后,我们可以在三分钟内检测到异常,并通过微信推送告警;然后4分钟内完成定位计算,推荐故障定位结论;下一步就是人去决策要不要做相应的动作?我们整个项目做出来的效果是这样的。

因为最后一步我们还没有做成全自动化,在少量的场景做成自动化,还是以安全为主,我们基础架构的影响面还是比较大的,初期仍然以安全为主。

通过这套黑镜网络自动化的诊断、定位系统,我们在网络故障时,最快可以十分钟内恢复故障,大部分场景在30分钟之内搞定故障。

以上是我们在网络自动化运营方面的一些持续的实践。通过这个方法,我们运营能力得到很大的提升,我们的监控很准确了,能够有90%以上的准确率,但是它的定位准确性不高,我们也分析了像我们的数据大概有50%(不准确性)。

我们也分析了一下原因:

  • 第一,我们的KPI主要是以阈值配置为主,这阈值很难适应复杂场景的组合,所以会有误告情况。

  • 第二,KPI之间没有权重的关系,假设我一台设备出了一个指标,另外一个设备出了三个指标,但就是就是这一个指标是决定性的,我们目前的方法就是简单的指标叠加,没办法区分权重影响,导致准确性收到一定影响。

    我们也发现我们沿着自动化这种传统的思路会有瓶颈,只能做到这样的程度了,我们就想有没有办法进一步提升它?现在这几年大家都在谈AIOps的理念,我们想能不能把AIOps引进来做一些尝试。

想法很好,如何落地呢?其实我们也没有特别多的信心,我们也开始在思考这个问题,应该是从去年下半开始,今年上半年真的实实在在做了一些事情。

我们想说大家谈 AIOps 挺多的,AIOps 也好、机器学习也好,主要的核心是要有高质量的数据,要有输入和输出,从这些数据样本中去找到一些隐含的规律把它提取出来,但是我们想网络的数据是什么样的?

网络上最主要应对的就是故障,我们对故障数据进行了一些分析,发现有个特点:

  • 第一个就是稀有性,网络上我们分析了自己的网络故障数据,恶性数据样本是非常少的,一年下来大概两只手就可以数过来了。常规的故障用这个必要性不大,大家还是解决一些有影响的故障。

  • 第二个就是新兴性,我们发现每次故障和上次故障重复的比例并不多,它都是新兴的故障,特别是配置,每次配置发生的问题都是有差异性的,它的规律性其实并不强。

  • 第三个是传播性,网络是一个mesh的连接,节点相互之间的影响是比较重要的,存在较大的干扰。

基于这几个特性,我们发现网络上的故障数据质量其实并不高,并不具备特别强的规律性。

那我们是不是不能做了呢?我们也看了一下网络上还有什么样的数据。

第一类是时序类的采集数据,比如我们通过SNMP采集的流量数据;还有一类是文本类的数据比如config、syslog数据;这些数据能不能有小应用的场景呢?我们结合一些行业的经验和做法,选取了2个场景来进行试点:第一个就是时序曲线的检测,这个是业界应用最多的;

第二个就是文本的聚类分析,对配置文件进行审计校验。

我们的想法是,一方面能看能否对KPI指标的监控准确性有所提升另一方面通过配置文件的管理,减少故障的发生。我们来看一看具体是怎么做的。

第一个流量的异常检测,我们联合内部SNG的织云做了尝试。我们做的比较简单,直接拿他们已经训练好的算法应用。

他们面临跟我们一样的场景,他们有大量的指标曲线图,也会有误报的情况。算法我们不不懂,其实也很复杂,每一幅图其中一个点都会算出180多个特征值,利用这180多个特征进行结果的计算。

我们直接把我们的实时流量数据和历史数据导到Metis平台,平台返回检测结果,不需要我们进行任何配置,只需要对结果进行标记反馈。用了这套方法之后,我们发现可以很好的解决单幅图的监控,帮助我们解决锯齿性、周需期性的误告问题。

但也发现还存在一些问题,主要是曲线之间的关联问题。

比如一个负载均衡的多个端口,像左边的图下降了,右边升高了,这是一个正常的网络切换行为,并没有流量的损失,并不需要告警。这是在传统的监控中没有解决的问题,这里仍然然解决不了。

那这种关联性如何解决呢?这一块我们其实也做了一些思考,我们认为过去我们对网络的管理的模式和方法不够精确。

我们很多的网络知识,比如对网络的连接、配置等,大部分是以PPT、WORD、excell的形式存在,或者装在脑子里面。

没有经过很好的抽象和封装,把这些东西以参数、函数的方式表达出来,简单说就是没有模型化、结构化的抽象,没有存在我们的数据库中,系统不太能理解网络上的一些含义,比如一条连线代表什么含义,一条配置代表什么含义,一条syslog代表什么含义,这些系统都不能理解,因此他不能做很好的深度的分析处理。

因此我们最近2年在对网络进行抽象建模,对硬件连接、对配置特性、参数,包括运营的状态进行模型化的抽象定义。我们希望通过这样一种方式,最终有一个全量的数据库,能很好的体现这里的关联关系,系统能也能理解网络网络上的一些行为、动作。

简单说就是构建比较完整的网络知识图谱。这个工作,挑战性也蛮大的,我们还在不断的摸索中,硬件部分我们已经完成了,并应用在我们的一些新建、扩容场景中,配置部分正在开展中。这是我们后续重点发力的方向。这个是我们的第一个实践。

第二个实践,我们尝试在配置管理上做一些突破。我相信配置的正确性的校验也是大家面临的一个比较大的挑战。

我们来看看网络设备的配置文件,这是一个不完整的设备配置样例。

我们分析一下自己的设备,一台TOR大概有5K行的配置,核心层上万行的配置,这么多行里挑哪一行错了是很难的。同时我们每一天都有变更发生,变更发生之后你的配置就会发生变化,你如何在动态的情况下管理它呢?这个挑战是很大的。我们在想怎么做呢?也无非就是找不同嘛,找谁的差异性比较大。

举个简单的例子,比如说有这么多篮的水果,我们如何把不同的水果篮挑出来呢?

我先把水果堆在一起,看看哪些水果出现频率是最高和最低的,然后把它进行聚类,然后把稀疏的项目筛掉了,我们就用这种思路去管理。

具体怎么做呢?我们参考了TF-IDF的文本分析算法,它主要是会过滤一些非关键的词项。

具体详细的算法我们不需要细究,我们用它的思想,它能帮助我们过滤一些非关键的词。我们把这套方法叫做聚类+降维分析法,把它应用在了配置文本的管理上。

首先我们会把配置文件拆分成很多的模块,每一个模块我们首先会把词聚集起来,比如说一百个文件中的同一个配置模块聚在一起,然后计算每个词出现的频率是多少,出现频率比较低的直接筛掉,然后会形成几个模板,这个模板会代表大多数的“广泛意见”,然后拿这个模板和现网的配置进行对比,从而实现审计校验的功能。

它可以用在两个场景,第一个场景就是可以在存量的配置里提取我有哪几种配置标准,这个标准拿给配置规范的同事去看是否是设想的。

第二,就是对存量的小众配置的设备,去看为什么不一样?是不是哪里配错了?这个方法在某些场景能发挥很好的作用,它能解决标准化程度比较高的架构的配置管理难题。但一些边缘接入的差异性比较大的场景则不是很好,另外对一些参数错误、或全局错误也不能发现。

对这些差异化的架构何去管呢?回到前面提到的建模的模型来看,这种参数级的错误,我们认为可以通过建模的来解决部分的问题,尽量减少人的参与。这是我们配置上面做的尝试。

通过这两个案例,我们网络AIOps方面做了初步的探索和实践,没有用很高深的算法。在这个过程当中我们也总结了一些经验,供大家在网络领域进行AIOps尝试提供一些参考。主要有三点:

第一点,就是网络要系统建模。我们认为当前的网络其实是模型的抽象程度不够,系统没有办法理解网络上的语言和行为,要把网络上的对象、事件、行为标准化的定义出来,让系统能够理解。今天上午清华的裴丹老师也提到过,这个工作是基础当中的基础。当然这个挑战性非常大,需要大量的投入;

第二点,不需要过多关注算法细节。大家谈到AIOps就想到了算法,但是网络从业人员在算法上不具备优势,在算法领域可以充分借鉴参考成熟的经验或开放资源,把重心放在场景、数据的挖掘和分析上。我们最主要是利用算法的思路,看他能解决什么问题,比如我们第二个案例,实际上并没有用到机器学习,只是用了一个数学算法,降低了问题的复杂度;只要能解决问题,我们就可以尝试进行应用,不需要太关系算法的细节;让专业的人做专业的事。

第三点,要加大在数据挖掘和DevOps上的投入。未来的运营,大部分是围绕数据的分析、提取、挖掘等工作,如何对数据进行快速的提取、分析,把分析、处理逻辑准确定义好,这是我们重点投入的方向。

以上就是我们近期在网络AIOps上的一些探索和思考,这些工作只是一个开头,相关的项目仍然在持续的推进,我们正在开展黑镜2.0的项目,打造基于事件的智能诊断平台,整体的思路还是差不多。

会对更多的运营数据进行分析,并把检测分析逻辑模型化,实时对全网进行大量的逻辑运算,提取异常事件,形成异常事件库。会持续的进行一些方法的优化和优化,引入更多的算法,提升准确性。

最终将基于完整的知识图谱,构建一个图数据库描述网络的软硬件关系,基于异常事件对网元进行着色处理,然后根据中心度的算法,进行故障定位计算。这是下一步的方向和思路,这里有很多的细节东西还没有想清楚,还在落实当中。这里也是欢迎各位一起研究和探讨。

以上是我们在智能运营这一块比较简单的尝试和思考,这里没有什么方法论和算法的东西,就是我们平时在做的事情以及思考。

这两年,除了探索网络的AIOps外,我们也在同步探索网络运营体系的演进。大家都知道以Google为代表的SRE体系。

结合这几年我们在NetDevOps方面的尝试,以及后续网络的演进趋势,大家可以看到网络领域硬件标准化和软件的开放化正在成为趋势,未来我们一定是基于一套统一的控制系统来管理海量的网络节点,高效的处理各种事情。

因此我们在内部开始推行网络领域的NRE运营体系,就是用软件工程师转型做网络运营工作,这个工作我们已经试行了将近一年的时间,现在我们招聘的毕业生都是研发出生的,对他们进行必要的网络知识的培养,由他们按照软件工程的思路去管理网络。

NRE主要有三个重要的工作内容:

  1. NetDevOps,一方面要去处理日常运营的基本工作,另一方面用软件工程的思路和方法,去优化日常运营工作中遇到的问题,提升效率;

  2. 可靠性的测试,不断的通过测试实例的设计,和例行的测试,检验网络的可靠性,发现网络中存在的一些异常。比如各种冗余架构的实际收敛影响,压力测试等等;

  3. 运营需求的设计和运营技术的演进迭代,尽可能将过往遇到的问题迭代到新的技术方案中,并对运营技术,如监控的精度、效率如何提升,可视化技术的落地等等。

我们认为传统的网工将逐步消失,NRE的新型运营模式将开启网络运营的新时代!

以上就是今天分享的主要内容,部分内容没有来得及细讲,我们的思路和方法也有一定的局限,非常欢迎大家一起群策群力,一起推动网络运营的持续发展。