本文转载自微信公众号“ 鹅厂网事”(ID：tencent_network)，作者：王福

　　【IT168 技术】网管系统存在的价值，在于其自动化、智能化管理大型网络的能力。随着网络规模的增长，我们经历过标准网络架构的批量自动化建设、海量状态采集和监控、海量告警收敛的时代;再后来，业务需求的多样性导致网络复杂度增加以及精细化运营需求井喷，催生了NetDevOps发展，使得网工可以快速灵活定制自己的应用;AI技术的兴起，更让NetAIOps成为新的热点。

　　然而，随着这些新技术、新方法的应用，我们可以说网络管理的自动化水平更高了，但是网络管理面临的挑战似乎并没有收敛，不断有更新更深层面的问题浮出水面。

　　比如在规划建设阶段，一个新网络架构设计出来，想要实现自动化建设，仍然需要很多人工定制化适配，例如：新架构的互联方式需要由交叉改为口字，架构师需要将所有具体连接穷举到系统上;又例如，新架构要求对所有端口开启BFD特性，架构师需要穷举出该架构的所有端口，然后对每个端口写一遍开启BFD的命令;诸如此类的人工强依赖必然限制了建设质量效率的水平。

　　又比如在网络运营阶段，越来越多的指标被采集，流量/包量/错包/队列/缓存等，甚至可以使用AI算法搞定某些单指标的自动监控，但是这些单指标的异常，并不能直观看到问题根因，例如：我们用AI搞定了流量变化的自动监控，却不清楚A到B直通流量的绕行，仅仅是因为千里之外的“无关”设备被敲错一条命令行。我们有了很多监控、有了大量运营工具，但在复杂故障出现时，仍然时常发现力有未逮。

　　问题分析

　　为什么会这样?是因为网络结构太复杂、常变化?还是因为系统还不够”聪明”?前者是客观条件，后者并不能为我们指明方向。究其根因，还是因为网管系统对网络不理解，系统只是起了连接网工与设备的通道作用，又或者针对某些固定场景，提供执行某些具体动作的能力，控制权还在人手中。在规划和建设网络时，因为系统不理解语义，需要人工将网络架构设计(HLD)转换为网络能够理解的LLD(具体的连接关系、命令行等)，然后交由系统执行，因为HLD变化而导致LLD改变的工作量，呈几何级数增长(一如前述交叉改口字、开启BFD的例子);在运营网络时，由于系统缺乏对网络全局的理解，无法从各种表象中找到问题根因，而经常变化的网络架构无疑对问题的定位和分析雪上加霜。

　　解决思路

　　如何解决这个问题?不妨设想一下两个场景：

　　◆ 规划建设阶段，架构师只需要关注抽象的网络设计(HLD)，系统能够识别这些抽象设计，并根据实际需求具象化为可落地的建设方案(LLD)，以此来应对需求的多样性;

　　◆ 网络运营阶段，系统基于网络的全量数据，能够智能分析各种状态和行为之间的联系，找出隐患或问题，并自动解决、规避，纵使架构发生变化，系统能够理解这些变化并自适应之。

　　我们继续往下看，如何才能具备这样的能力:

　　◆ 首先需要有一套方法，能够结构化的描述整个网络的组成元素及相互关系，从网络到网元、机框、槽位、端口，乃至配置、状态等，都能够结构化描述，使得系统能理解网络语义;

　　◆ 其次需要有一颗智脑，一方面可以理解架构师的意图，并将意图转换为可落地的方案，另一方面则能够从各种网络表象的变化中，分析出真正的隐患或问题;

　　◆ 最后还要有一系列的自动化工具，供系统根据分析的结论，实现具体的处理逻辑，并且最终应用到网络中。

　　这些自动化”触手”，我们称之为Robot;这套使得系统能理解网络语义的方法，我们称之为建模，建模最终生成的是系统可以理解的结构化模型(Model);能够识别用户意图，具备分析问题能力的智脑，我们称之为Brain;合在一起，就是今天要探讨的R.M.B。

　　▲ 网管整体框架图

　　1.【Model篇】

　　Model是一套可以结构化描述网络的模型，网络通常分为物理部分和逻辑部分，物理指组成网络的各种硬件(机框、单板、光模块、线缆等)，逻辑指各种软件特性的配置(路由协议、管理特性、QoS等)，所以Model可以分为硬件模型和配置模型，以及运行过程中的状态模型。

　　1.1【硬件模型】

　　硬件模型包含两部分，首先是描述如何组网，然后是组网的网元具体由哪些硬件实现。

　　1.1.1【如何组网】

　　可以用一种抽象的方式来描述如何组网：

　　◆ 有哪些架构角色，例如：一个IDC内网，是接入/核心两层，还是需要接入/汇聚/核心三层，每种架构角色的最大数量;

　　◆ 各架构角色之间应该如何互联，例如：和哪些架构角色互联，互联单端口带宽，最大链路数，连接方式用口字还是交叉，链路数需要满足2的n次方还是等分带宽，对底层传输的容灾依赖等;

　　1.1.2【硬件实现】

　　通过设计组网的步骤，得到了对每台设备的端口数量和带宽需求，根据这些需求，需要找到对应的硬件实现，主要包括：

　　◆ 有哪些硬件物料(机框、板卡、光模块等);

　　◆ 各物料之间的配套关系;

　　◆ 端口功能区的规划，即：哪些端口用于连接哪些架构角色，例如：接入设备的45~48号端口组成“To 内网核心”功能区。图3展示了功能区的设计，每种颜色对应一种功能区。

　　▲ 硬件物料及配套关系定义

　　▲ 端口功能区规划

　　至此，一款架构角色的硬件模型构建完成。

　　1.2【配置模型】

　　配置模型主要描述三个内容：

　　◆ 一台设备要完成设计的网络功能，需要配置哪些特性;

　　◆ 这些特性需要在哪些对象上开启，对象可以是物理的(例如：某块板卡/某个端口)，也可以是逻辑的(例如：某个BGP邻居/某个捆绑口);

　　◆ 这些特性具体的值，例如：IP地址是多少，MTU配多少等;

　　网络发展到今天，各厂商的特性其实大同小异，使得一套统一的配置模型成为可能，一如OpenConfig组织提出的 OpenConfig YANG Model，这套Model描述了一个网络设备应该有哪些对象，有哪些特性，这些对象/特性应该叫什么名称，是怎样的数据类型，以及对象和对象，对象和特性之间的关系。

　　配置建模的构建，分为如下几步：

　　◆ 架构师基于全量的Model(例如 OpenConfig YANG Model)，结合实际需求，选择该架构需要使用哪些特性;

　　◆ 然后是架构师定义这些特性需要在哪些对象上开启，和定义硬件模型类似，使用枚举并不是一种好的方法，需要对这些对象进行抽象定义，物理对象的抽象定义可以复用硬件模型中的抽象，例如：类似 “To MAN的所有端口”这种定义，逻辑对象其实也可以用类似的方法定义，例如：“所有互联IP”，“所有BGP邻居”，需要有一个专门的模块来管理这些逻辑对象，例如：IP管理、BGP邻居管理等。

　　◆ 第三步，架构师定义这些特性的值，可以支持直接赋值，但更多的场景是定义赋值的方法，因为很多值在具体的建设方案确定以后才能生成，例如：某台设备的管理IP、某个端口的描述(通常是对端设备名+端口名的组合)等。

　　▲ BGP配置模型

　　1.3【状态模型】

　　状态模型主要描述不同的网络对象，能提供哪些状态监控的能力，由于OpenConfig YANG Model中描述了网络对象之间的关系，所以基于这套模型，将状态监控项作为一种特性挂载其上，也是水到渠成的事情，实际上OpenConfig正是如此做的。

　　状态模型的构建和配置模型基本一样，不再赘述。

　　2.【Robot篇】

　　建模是网络自动化的基础，硬件/配置/状态模型结构化描述了网络中各种对象以及对象之间的关系，将网络转换为一套抽象的模型，使得系统可以全局的理解网络语义。一款Model Driven的Robot，其实质是理解这套模型，基于这套模型开发应用逻辑，通过对模型的增删改查，从而实现对网络的管理。

　　2.1【如何快速构建Robot应用】

　　这里有两个关键点：

　　◆ 传统的开发模式，针对每个具体的场景，从业务逻辑到数据结构以及底层的交互，全部自己实现，这种垂直式的开发，不仅重复造轮子，而且对网络的整体变化缺乏把握，基于一套统一的模型来开发应用，使得系统更容易理解网络整体的状态，便于快速发现根因问题，另外基于一套数据模型进行开发，也使开发效率更快;

　　◆ 另外一个关键点是：基于模型开发的应用，输出的是对模型实例的增删改查操作，这些操作如何能转换为实际设备可识别的指令?当前网管与设备交互协议繁多，SNMP/CLI/Netconf/rest API等，即使协议一样，各厂商的具体指令也不尽相同，甚至某些时候，网管需要交互的对象是控制器而不是设备，适配的工作占用大量的开发时间，这就需要系统能够提供一个平台，根据设备的实际能力，自动将应用生成的模型实例转换为设备/控制器可以识别的指令，从而屏蔽底层差异，应用开发者只需关注业务逻辑，快速实现各种自动化应用。

　　2.2【Robot应用场景】

　　从场景看，Robot可以应用于网络规划建设和运营的全生命周期。

　　◆ 规划建设阶段：提供自动化建设系统，基于架构师设计的抽象模型，结合实际建设需求，系统能够自动生成具体的建设方案。

　　◆ 基于硬件模型生成物料清单、安装方案、连接关系等，用于指导采购、安装、布线;

　　◆ 基于配置和状态模型则生成相应的配置和状态实例，并最终转换为设备可以识别的信息;架构师只需聚焦于网络的抽象设计(HLD)，具体的建设方案(LLD)由系统自动生成，以此来面对网络架构频繁变化的挑战。

　　▲ 自动生成的连接方案

　　◆ 网络运营阶段：规划和建设阶段，网络的复杂性主要体现在方案的差异上，设计、生成方案的方法是通用的，但是运营阶段则不尽然，不同架构、不同设备、不同故障场景，业务恢复和故障处理的方式都不尽相同，网络的差异性在运营阶段体现的淋漓尽致，这也是运营工具需求井喷的原因，这种工具相对独立，相互间耦合不多，一个工具解决一个问题，并且会随着网络情况的变化经常调整，在网管智能化能力未全面覆盖之前，大量的运营工具需求将长期存在。这也是我们推行NetDevOps的原因之一，基于Model的开发，无需自己定义数据结构，无需关注底层设备差异，使得应用可以快速上线;使用Devops模式，减少了运营人员/产品经理/开发之间的沟通，使得Robot应用开发更敏捷。

　　总之，Robot主要聚焦各种自动化应用的实现，考虑到运营场景的多样和变化，提供一套基于Model的NetDevOps平台，让运营人员快速DIY自己的Robot应用，是个不错的思路。

　　3.【Brain篇】

　　Model提供了一套数据模型，Robot负责基于这套模型做事情，相当于手和眼，还缺一个大脑(Brain)来控制这些Robot，以前的大脑是人，人来控制工具的执行，要真正实现自动化闭环，还需要一颗智脑。

　　3.1【Big Data】

　　讨论智脑之前，先说说数据，不论是人工智能，还是大数据分析，都离不开海量的有效数据。传统网络不论是数据实时性(SNMP/CLI只能支持分钟级的采集)，还是数据完整性(当前主要是CPU/内存/流量/包量/丢错包/光功率等指标， 缺乏对设备底层例如芯片层面的监控)，都很难满足大数据分析和AI对数据的需求。

　　所幸近年来通过业界的努力，秒级上报的telemetry技术已开始商用，可编程芯片+ P4语言的组合，使得更多芯片级的状态可以被监控起来，而状态建模则建立了这些状态项之间的联系，使得大数据分析和AI具备了数据基础。

　　3.2【Brain】

　　有了数据基础，再来谈谈智脑，这颗智脑应该具备两方面的能力：

　　◆ 一是面向网络的，能够理解网络中的变化，并将各种错综复杂的变化，归纳收敛为具体的根因事件，这种能力常应用于故障定位、故障预防等场景中，通过智脑分析出网络的具体变化或变化趋势，然后驱动Robot进行处理。

　　举个例子：通过对状态模型的分析，可以得到当前设备状态是否异常，将状态异常的设备找出来，然后根据拓扑、IP连接、协议邻居等关系，通过一套计算聚合度的方法，可以找到这些异常设备的中心点，这个中心点即为根因设备，然后在根因设备内继续深挖，根据硬件模型、配置模型可以得到机框/板卡/端口/捆绑口/IP/路由协议这些对象之间的映射关系，将状态异常的对象标示出来，则很容易找到本次异常的根因。

　　◆ 另一种能力是面向人的，智脑能够理解人想干预网络的意图，并将其转换为可以落地的方案并实施，这种能力常应用于网络变更场景中。

　　但这种对于人意图的理解，还不同于前面提到的基于Model的架构设计和自动化建设，前者要求架构师还是要将HLD设计出来，例如设备架构角色定义、互联规范选择、功能区定义等，这些事情还是需要很高的专业度才能做，然后系统将HLD转换为LLD;基于意图的网络则更加抽象，人更多关注的是需求，是要做什么，如何做由系统来考虑。

　　还是举个例子：业务需要在某个园区部署一批机器，人主要关注这个部署需求是否合理，系统能够根据业务的历史流量模型，分析出流量的带宽需求，然后结合对现有网络的智能学习或者人工内置的各种规则，自动生成扩容方案。

　　以上两个场景，都依赖智脑的规则，这种规则可以是人工指定，也可以是基于AI自动生成，不论哪种方法，都需要实时、完整的网络大数据支撑。

　　总结

　　Robot是各种自动化应用，相当于网络管理的眼睛和手;Model提供了一套结构化描述网络硬件、配置、状态的方法，使得系统能够理解网络语义，快速开发Robot成为可能，同时也为Brain提供实时、完整的数据;Brain是大脑，基于大数据，用各种人工指定或者机器学习生成的规则，驱动各种Robot工作。下一代基于Robot.Model.Brain(R.M.B)的网管，将网络结构化、抽象化、智能化，大大降低网络设计、建设、运营过程中人的参与，使得全自动网络管理成为可能。