何维兵 | 腾讯网络平台部基础架构运营负责人
本文为腾讯何维兵老师在 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主要有三个重要的工作内容：
NetDevOps,一方面要去处理日常运营的基本工作，另一方面用软件工程的思路和方法，去优化日常运营工作中遇到的问题，提升效率；
可靠性的测试，不断的通过测试实例的设计，和例行的测试，检验网络的可靠性，发现网络中存在的一些异常。比如各种冗余架构的实际收敛影响，压力测试等等；
运营需求的设计和运营技术的演进迭代，尽可能将过往遇到的问题迭代到新的技术方案中，并对运营技术，如监控的精度、效率如何提升，可视化技术的落地等等。
我们认为传统的网工将逐步消失，NRE的新型运营模式将开启网络运营的新时代！
以上就是今天分享的主要内容，部分内容没有来得及细讲，我们的思路和方法也有一定的局限，非常欢迎大家一起群策群力，一起推动网络运营的持续发展。
