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

　　近十年通信和互联网行业飞速发展，人们可以体验越来越丰富的互联网应用，从文本、图片到语音、视频，但万变不离其宗，Internet服务从根本上由两部分组成：管道+内容。最初，管道由运营商包办，内容提供商将自己的服务器接入运营商机房，甚至直接将业务部署在运营商服务器上，但是随着业务发展，这种方式逐渐无法满足需求，内容提供商内部的互联互通需求，使得初具规模的内容提供商开始自建/整租机房(IDC：Internet Data Center)和机房间的内部互d联管道(DCI：Data Center Interconnection)，这便是互联网公司的运营网络，脱胎于电信运营商网络，但又有不同，同样，互联网络网管系统也是类似。

　　一、运营商网管简介

　　运营商网管基本基于TMN(Telecommunications Management Network)模型构建，TMN相关介绍的文章很多，本文不展开详述，其总体思路为：将网络管理系统的功能分为如下四层：

　　网元管理层(Element Management Layer)：提供单个网元管理，包括网元的Fault(故障)、Configuration(配置)、Performance(性能)、Security(安全)等特性，在运营商网管体系中，网元层管理系统主要由网络设备厂家提供，从而屏蔽不同厂商之间的私有MIB以及命令行的差异，当然，从实际情况看，这种差异屏蔽做的并不好，导致上层系统集成很困难，EMS(Element Management System)面向用户主要为运营商网络运维人员及厂商代维人员。

　　网络管理层(Network Management Layer)：提供对网络层面的管理，同样也包括网络的健康状态监控、网元间的故障相关性分析、故障处理工具、网络保护及路由调度控制等，由于网络管理层和网元管理层乃至网元设备间耦合度较高，以及运营商软件开发能力欠缺，所以NMS(Network Management System)也通常由网络设备厂家提供，面向用户也主要为运营商网络运维人员及厂商代维人员。

　　业务管理层(Service Management Layer)：又叫运营支撑层(Operation Support Layer)，主要支撑运营商将网络作为一种服务提供给用户，主要包括：网络资源及资产闭环管理、用户业务实际开通及运营(计费、流统、行为分析等)、网络及业务健康状况监控、以及异常/故障处理和跟进。另外，由于EMS和NMS对厂商的差异性屏蔽不好，以及运营商基于成本考虑，引入多厂商混合组网，导致跨厂商的告警收敛以及多厂商的底层差异屏蔽，也作为OSS的重要特性。由于其复杂性以及多厂商混合组网的存在，使得单一设备厂家很难提供整套OSS，所以这个细分市场主要由传统软件服务提供商提供，海外主要是IBM、HP这些传统巨头，国内如合力金桥、中盈优创、神州泰岳等。面向的用户为运营商的网络及业务运维人员。

　　事务管理层(Business Management Layer)：主要是针对运营数据的分析和沉淀，找出规律，供高层决策或驱动ERP/CRM系统进行优化。其系统被称为BSS(Business Support System)，主要构建模式为用户定制，面向用户主要是运营商数据分析或决策人员。

　　互联网络管理系统的架构，其实也类似，都是基于TMN的模型演变而来，具备FCAPS的大部分功能，但是和传统运营商网管相比，又有些区别，其差异的根本原因，是由于现代互联网公司与传统运营商的差异造成，下面从如下几个维度来简单聊聊二者异同。

　　二、互联网时代网络特点

　　(一)海量网络高效运营

　　从行业发展看，互联网行业处于高速发展的时代，业务对于网络带宽的需求，导致网络规模快速扩大，动辄数万台设备，数百G流量;同时，基于成本考虑，对网络运营人员规模和生产效率也有更高期望，能够重复的事情系统做，复杂的事情简单做，提升效率，用更少的人做更多的事，满足海量网络高效、稳定运营的需求。

　　(二)差异化和精细化

　　从网络架构看，互联网络主要包含几部分：分布于各处的IDC、将IDC互联的DCI、和运营商互联的出口、以及和其它企业互联的ECN网络等。一方面，不同层次的网络，具备不同特质，使用不同技术，例如：DCI在跨城间互联的主要挑战是多业务承载以及差异化流量服务，所以这部分使用MPLS承载，而城域内则使用IP承载即可;另一方面，由于业务的不同要求，使得网络使用不同技术应对，例如：有的IDC使用大二层，有的IDC则是三层网络。不同的网络结构，在提供通用监控和管理的同时，也需要提供差异化和精细化管理能力。

　　(三)业务灵活调度

　　从业务需求和成本看，一方面，业务希望网络提供尽可能多的冗余和备份，一旦发生问题，可以快速调度，保障用户体验，另一方面，流量不均衡导致不同链路利用率参差不齐，期望可以通过灵活调度，提升利用率，降低成本。所以，需要提供灵活调度能力。

　　(四)云服务

　　从发展趋势看，由于云服务的推广和普及，云服务提供商也需要将用户相关的网络管控能力向用户开放，所以，网管还需要提供服务封装能力。

　　三、互联网时代需要怎样的网管

　　具备如下特质

　　● 针对海量网络管理需求，提供高效、稳定的运营能力

　　● 针对不同网络架构和技术，提供差异化和精细化管理能力

　　● 基于用户体验提升和成本考虑，提供灵活调度能力

　　● 随着云时代到来，提供管控服务对外封装能力

　　(一)海量网络监管控

　　海量网络主要具备以下特点和挑战：

　　1.海量监控

　　挑战一：海量数据采集

　　◆ 从监控维度看，想要对网络进行全方位管理，需要从点线面三个维度进行全方位监控，细化到监控指标，则有数十个之多(例如：CPU/内存/流量/包量/丢包/错包等)。

　　◆ 从监控对象看，需要在固定周期内(例如：5分钟)对全网数万台设备都检测一遍。

　　◆ 从实现方式看，SNMP采集、telnet采集、主动探测等多种技术方式都需要用到。

　　◆ 如此海量情况下，单台服务器基本不可能完成全网监控任务。

　　应对：分而治之

　　采用分而治之的思路，首先需要按功能拆分成子系统，例如：SNMP采集子系统、telnet采集子系统、质量探测子系统等，对于每个子系统，都需要提供分布式架构，底层采集器/探测器按需分布，灵活扩充，采集/探测到的数据，初步处理和压缩后，提交给中央二次处理，这样可以提升采集、处理能力，也可以平滑支持网络扩展。

　　挑战二：海量告警处理

　　采集到的监控项，经中央处理后，除了直接展示(例如：流量图、质量曲线等)，更重要的是对其进行判定，匹配到异常则转换为告警，通知NOC处理。

　　运营商的架构一般分为集团公司、省分和地市，所以网络也通常是按这个模式来运维，即：一张网由多个组织分层维护，由于运营商人力较多，所以对告警最重要的需求是告警要全，不要漏告，对收敛需求较少。

　　但大型互联网企业则不一样，设备数量不亚于国内主流运营商，但是网络比较扁平，统一由NOC集中运维，人员数量相对于运营商不在一个量级，面对每天数万乃至十万量级原始告警，如果没有工具系统对其进行强有力的收敛，全手工很难运维。

　　应对：告警收敛，关注根因

　　针对每种故障场景，告警收敛的逻辑各不相同，但是万变不离其宗，一个核心的原则是：将告警进行分层，基于配置信息，不同层次之间实现纵向收敛，同层次内实现横向收敛。例如：传输告警纵向收敛链路状态告警、本端链路状态告警横向收敛对端链路状态告警。

　　要实现这样的收敛能力，有两个关键点需要关注：

　　◆ 配置准确性(如何保证参考配置管理章节)。

　　◆ 提供通用收敛框架，基于通用框架，快速开发、不断累积收敛规则。

　　目前鹅厂已经累计数十种收敛规则，可以将每天上万条告警收敛为数百条，并且还在持续精耕细作。

　　另外，从长远看，这种模式终归需要人工干预，后续也在考虑引入人工智能，由系统根据现网运营情况，自动学习规则，然后基于规则收敛。

　　2.自动化

　　网络不仅有监控，还有排障和优化，海量网络中，每天数十次trace测试，数百次VLAN切换，数千次策略开通司空见惯。一千个人眼里有一千个哈姆雷特，但是如果让你重复开一千次安全策略，估计你会疯掉。所以海量网络，没有自动化将寸步难行。

　　挑战一：配置准确性

　　自动化的基础其实是标准化，一方面是操作流程要标准，另一方面，基础配置数据要准确，否则会做多错多，所以第一个挑战是配置准确性(如何解决参考配置管理章节)。

　　挑战二：人机接口及厂商差异

　　由于SNMP对于设备的控制能力很弱，自动化通常基于telnet/SSH协议，使用命令行和设备交互，命令行天生是一种人机接口，现在强行用于被程序调用，在传参、调用结束判别、回显提取等方面存在很多挑战。另外，考虑到成本问题，互联网络通常是多厂商设备混合组网，由于众所周知的原因，各厂商之间，甚至同一厂商的不同型号、不同OS版本之间，也存在差异。如何使人机接口为程序所用，并适配各厂家差异，是第二个挑战。

　　应对：通用框架+差异封装

　　要解决这个问题，首先需要有一个框架，将任务封装、命令行组装、执行、结果解析、异常处理等公共部分抽象出来，各自动化任务都使用这套公共框架执行，对于各厂商命令行的差异，则采用模板的形式来屏蔽，同一个任务，不同厂商对应不同的同名模板，上层应用只关注使用哪个名称的模板，具体执行时，框架根据对应的设备型号或厂家来选择某个具体模板执行。这种插件式的模板是可配置的，新设备引入时，针对该设备型号配置对应的新模板即可，无需修改应用和框架。

　　目前这种通用框架+模板的方式，已经在鹅厂自动化工具中广泛应用，按网络生命周期划分，主要包含以下几类：

　　◆ 建设类：IDC建设流程自动化，主要包括自动生成设备拓扑和配置、自动转运营验收等。

　　◆ 运营类：服务器部署自动化、安全策略开通自动化、链路调试自动化、OS升级自动化等。

　　◆ 排障工具类：主要针对常用故障场景，如：多路径丢包排查、traceroute分析、静态路由分析等。

　　据不完全统计，鹅厂网管年执行超过150万次自动化任务，修改设备配置近千万行。

　　另外，随着精细化运营的深入，自动化工具需求越来越多，工具制造能力正逐渐成为瓶颈，我们也在尝试提供一个通用平台，封装常用原子操作，让用户以搭积木的方式，自行制作工具。

　　3.配置管理

　　挑战：配置准确性

　　如前面所述，配置管理是海量网络自动化运营的基石，告警收敛效果以及自动化工具运转的结果，很大程度上依赖于配置数据的准确性，所以最关键的挑战是如何保证配置数据的准确性。

　　应对一：自动采集

　　一方面是配置自动采集，现网数万台设备，数百万配置项，如果全部人工录入，效率和准确性都无法保证，所以，在有了固资、管理IP这些关键数据后，其它可以从设备上获取的信息，如：端口状态、速率、IP等，则由系统自动采集并入库，而无需人工处理。

　　应对二：闭环流程

　　另一方面，关键数据还是需要手工录入，另外配置数据在现网运营过程中，会发生变化，这些变化需要实时体现在配置系统中，所以需要有闭环流程，针对配置发生变化的各种场景，提供在线流程及验证，保障闭环操作，从设备准入、建设、优化、运营、排障、退役等生命周期管理全过程，提供完备的端到端流程，杜绝垃圾配置数据产生。

　　应对三：周期审计

　　最后，即使再完备的流程，再细心的人，也会有异常产生，从而导致配置数据的准确性问题，所以需要提供双保险：配置审计，用技术手段分析现网数据，和配置系统数据进行审计，从而发现异常。配置审计主要分几类：一类是设备状态审计，如设备状态是否异常、管理IP是否存活等，通过这类审计保证设备可访问以及管理IP和固资映射的准确性;另一类是资产信息审计，如：设备及部件的数量和SN等，通过这类审计保证整机、部件的状态和对应关系;还有一类是运营类审计，如：设备OS版本、是否命中已知问题、带外通道是否异常等，通过这类审计保证运营风险及时发现。

　　鹅厂数万网络设备，数十万服务器，数百万配置项，通过自动采集+流程+审计的方式，目前配置准确率稳定保持99.99%。

　　4.容量管理

　　容量管理的理想情况是，业务的逻辑和分布与基础架构的能力和规划完美匹配，如同一个完美规划的城市一般交通永不堵塞;然而理想虽丰满，有几点因素，导致现实只能是骨感的：

　　多种挑战

　　挑战一：基础资源不可控

　　基础架构资源如服务器、机架、电力、带宽的供给并非自己可控，受制于供应商、运营商等各种外部环境，资源按期或快速交付的压力非常大，甚至无法按需提供;

　　挑战二：业务发展难预测

　　互联网业务发展充满不可预测性，导致对资源的需求也是难以准确规划，资源的供给一旦脱节，只能在规划上做出妥协，优先保障上业务，导致业务的分布不是最优的;

　　挑战三：业务部署难规划

　　互联网企业内部各业务之间，往往因为缺乏统一规划和协调，导致业务按各自规划来部署，而业务之间其实是有交互的，尤其平台型业务和应用型业务之间，从而导致大量穿越流量产生;

　　由于前述的种种因素，网络会变得不均衡，出现局部容量热点。那么如何解决?

　　应对一：业务流量分布数据的获取能力

　　首先，需要我们具备了解业务流量分布特征数据的能力，某个业务，在各IDC的分布情况，在IDC内/城域内/跨城间产生了多少流量，分别流向哪些业务等。

　　这些数据可以从netflow和serverflow采集的会话信息中提取，会话信息中最少需要保留源/目的IP、源/目的端口、协议等信息，数十万台服务器规模的网络，每天的会话量将有百亿量级。如此大的数据量，第一个挑战是如何实时采集和处理，这里需要用到前面提到的分布式采集系统，底层分别采集，然后经过初步加工和汇聚后上报;第二个挑战是如此大量的数据如何存储和分析，传统关系型数据库很难满足高并发的读写性能要求以及高可扩展性要求，所以需要考虑使用满足极高读写性能要求的key-value数据库，甚至使用其它现有的数据仓库，利用大数据平台对其进行多维度分析。

　　应对二：局部热点控制能力(事中)

　　具备了获取业务流量分布数据的能力后，我们可以迅速救火，在热点发生时，找到导致热点的异常业务流量，并提供控制和处理能力，避免异常业务流量对其它业务的影响。

　　应对三：基于容量管理的基础资源规划和分配能力(事前)

　　另一方面，从长远看，可以建立穿越流量业务分布模型，将其纳入到业务规划流程中，使得业务部署前，可以提前考虑资源规划和业务规划的更优匹配;另外，在业务部署后，相应的审计、腾挪优化也能有序的运作。

　　(二)差异化/精细化服务能力

　　如前面第三章所述，互联网公司网络通常会包含如下几部分：分布于各处的IDC、将IDC互联的DCI、和运营商互联的出口、安全相关的网络设备，另外可能还有一些特殊用途的网络。不同网络架构，提供的服务有差别，同样，网管系统也需要对其提供差异化服务能力，从而实现精细化管控。

　　以鹅厂为例，除了DCI、IDC、出口、安全网络，还有和其它企业互联的ECN网络、以及金融网络等架构。如下是几个典型的精细化管理场景。

　　1.DCI

　　首先，由于鹅厂业务的多样性，鹅厂网络实质是一张多业务承载网，文本/语音/视频多业务混跑，不同业务，对于网络的容忍度不一样，所以需要提供差异化流量服务，使得网络拥塞或故障时，能够根据不同优先级提供不同等级的服务。这里有两个问题，一个是如何标示不同业务，另一个是对于不同优先级的流量，如何调度。

　　业务流量标示

　　针对第一个问题，在海量网络的情况下，靠人来维护显然不现实。鹅厂网管提供了一套自动打标系统，用户可以基于业务模块维度在系统中登记(业务模块信息一般不变)，系统根据服务器的业务归属以及登记的优先级，在接入层对其设置不同的DSCP值。对于服务器的新增/下架/迁移/业务归属调整，都由系统自动发现并刷新DSCP值。这样对于指定的业务模块，用户一次设置，系统后续自动打标。另外，从长远看，这种模式解决了服务器变化的问题，对于业务模块变化的问题，还需要人工处理，我们也在探讨基于流的特征来分析其业务归属，从而自动打标的可能性。

　　业务流量调度

　　针对第二个问题，我们使用QoS技术来区分不同流的优先级，同时辅以SDN调度技术，对符合条件的业务流进行调度，从而实现业务流量的差异化管理。

　　2.IDC

　　IDC网络的最大特点是数量多，建设量大，所以重点聚焦规划、建设、验收的自动化。

　　规划线上化

　　规划线上化是基础，将当前鹅厂主流IDC网络架构的相关规划数据(架构版本、网络层级、适用设备型号、端口及连接关系、IP分配规则、配置特性等)纳入系统，进行结构化管理，所有建设项目以规划规格为准，避免线下操作，导致规划和建设不一致的情况发生。

　　建设自动化

　　基于结构化的规划数据，建设自动化也就水到渠成，网络PE只需指定建设的架构版本、规模等信息，系统自动生成网络连接关系，用于指导施工布线;根据导入的参数，以及IP裂解规则，自动生成配置文件，进行上架初始化;在完成调试后，自动进行多维度验收(如：3A、ADS等)，从而保证建设正确性和转运营质量。

　　3.金融/安全网络

　　安全网络主要聚焦安全漏洞发现、防火墙策略自动实施、垃圾策略审计等;

　　金融网络则因为其重要程度，需要提供更严格的操作审计能力、更快速的异常检测/处理能力、并和业务指标联动，实现更快速的响应。

　　(三)调度能力

　　互联网业务，好的用户体验是关键，如何提供好的用户体验，一方面依赖于业务应用的交互设计，另一方面，则依赖网络提供永不掉线的稳定服务。为了达成这个目标，网络不仅需要提供冗余能力，还需要在故障发生后，能够自动、实时的调度。另外，基于成本考虑，网络建成后，也希望尽量提高利用率，在流量不均衡的情况下，灵活的调度需求成为必须。其实传统运营商也是类似的要求，但是相对来说，互联网企业今天面临的竞争更激烈，对网络可靠性要求更高，对成本控制更严，所以要求调度能力更强、更实时、更灵活。

　　每个互联网企业主营业务、网络架构、以及资源分布都不太一样，所以面临的调度需求和场景也不尽相同，还是以鹅厂为例，从应用场景看，鹅厂主要在DCI网络上存在调度需求。

　　当前长途光纤资源的租用成本很高，由于流量不均衡，一方面，整体带宽利用率低，成本压力大;另一方面，局部容量预警多，业务压力大;更窘迫的是节假日突发流量，使得局部热点雪上加霜。此时更好的方案应该是合理调度，而不是扩容。其实传统网络也有调度方法，如：MPLS TE autobandwith技术，但这些方法类似于每个路口的交警，根据路口情况独立做出判断指挥交通，但缺乏全局视图，无法得出全局优秀的解决方案。所以需要提供一个控制器，整合全网路径信息，集中算路，得到全局优秀的解决方案，使得流量以更合理的方式调度。这其实就是SDN的思路。

　　(四)服务对外封装

　　通常互联网网管的使用对象是公司内部网络运维人员，所以对于管控数据很少进行封装和抽象，但是随着云时代的到来，互联网公司的网络正在成为开放平台，越来越多的企业在之上部署业务，所以将通用网络监控能力封装为一种服务提供给内外部企业用户，成为一种必须。

　　所以在传统的采集层、数据层、应用层之上，需要提供一个面向业务的服务抽象层，该层主要实现如下功能：

　　(1)根据网管管控能力，抽象出服务场景。

　　(2)按服务场景，将管控数据或工具增加对应的业务信息，从网络视角转换为业务视角。

　　(3)统一封装接口服务，供用户调用。

　　四、总结

　　总之，互联网时代的网管，需要关注以下几个关键问题：

　　(1)海量网络运营所带来的种种挑战及应对，如：数据规模问题、告警如何收敛、自动化处理问题、配置准确性、容量管理问题等。

　　(2)不同网络架构所衍生的差异化和精细化管理能力。

　　(3)基于成本和用户体验考虑，提供灵活调度能力。

　　(4)开放平台的管控服务封装，将网络管控封装为服务提供给用户。

　　鹅厂网管正是基于此思路，结合TMN模型，打造出一个覆盖网络规划、建设、优化、运营、退役全生命周期的统一管理平台。本文试图管中窥豹，对其总结一二，希望可以对大家有所帮助，更希望可以抛砖引玉，了解各位业界同仁的真知灼见。