自研交换机全自动化运营之路
前言
“如何让网络运营自动化”是每一个拥有超大型数据中心的公司都面临的问题，然而在迈向高度自动化的道路上，或难以实现，或难以传承。究其根因，在于网络数据多元化，在于新特性生产周期无法自控。
2020年，是腾讯网络自动化应用井喷的一年，在短短5个月的时间内，我们基于网络特性建模以及自研交换机打造了全新的自动化运营体系，实现了配置自动审计、变更自动化以及秒级故障自愈。相比过往，自动化途中的重重困难被逐一攻破，这不禁让人联想到 “打通任督二脉”之势。本文从内到外，剖析腾讯自研交换机全自动运营之路。
01
打通“任脉”：网络建模系统
做好“自动化”的前提，在于数据要亲“机器”而非亲“人”，莫要让底层的数据形态制约上层的设计思想。网络建模系统将离散，多元化的网络数据（各设备商的CLI）抽象成标准、格式化的数据，为自动化体系打造坚实的地基，上层应用越复杂（例如IBN），”地基”的作用越明显，使得消费网络数据的用户，无论是网络工程师还是周边系统，面对的都是一个个易编程的对象或结构化的数据，让网络不光可编程，而且易编程。
1.1 Tencent YANG Model：为各类应用提供面向对象的、易编程的结构化数据
回想过去，当我们想基于命令行实现一个自动化工具时，配置与状态是分离的，甚至有些状态数据需要繁琐而沉重的文本解析工作。而基于易编程的模型，“一个A设备的端口B出现错包，就关闭这个端口“可以简单实现为：
if A.interfaces.interface(name = B).state.error>0:
A.interfaces.interface(name = B).config.enable = false
我们通过易编程的模型将每一个container的状态与配置很容易的闭环在了一起，开发者不必关心每一个厂商的命令行该如何操作，只需知道操作的是一个个对象。就像针对我自己这个对象，感觉冷了（状态模型），穿上厚衣服（配置模型）。这对开发者而言，底层适配工作被透明化，加速了各类复杂应用的实现与管理。
1.2 鲁班：模型与设备之间的桥梁
YANG Model实现了网络特性的抽象，造福了开发者，但是配置最终还是要下发到设备上，对于“黑盒”设备来讲，无法识别基于YANG生成的JSON数据。在这里，我们通过鲁班系统完成JSON到CLI的互转，实现了“普通话（YANG Model）”到“方言（CLI）”的翻译。保证了整体流程的连贯性。
然而，翻译层系统的存在只是将繁琐的适配工作下沉，对上友好，但工作量并没有减少。尤其是配置的反向读取翻译（文本到json的映射）极其耗费人力，灵活度低。若去掉翻译层，由设备侧OS支持YANG Model，这就带来了新的问题，即商业设备的新特性开发周期难以应对模型的经常性变动，且传统的OS升级手段无法保证快速与平滑，最终阻塞模型的更新。
这个时候，自研交换机的出现，与建模系统珠联璧合，让整个底层通道顺畅而坚实。
02
打通“督脉”：自研交换机OS
腾讯自研交换机（TCS）基于SONiC，深度自研了Tencent NOS，打造高性能、高可靠、智能化的自主可控网络业务系统。快速适配腾讯网络的架构&运营需求，集中体现在：
2.1 统一化的管理平台
TCS天然支持Tencent YANG Model，通过JSON（Tencent YANG）到JSON（Sonic YANG）的映射，将翻译层下沉至OS侧，快速支持配置与状态模型的更新，解决了建模系统中“翻译难”的问题。同时用gRPC框架替代传统CLI下发通道，提高配置下发与提取性能。
2.2 功能容器化部署&无损升级
用户进程部署在docker中，使得APP化的网络应用可以在Tencent NOS上快速验证和部署。结合进程热补丁，docker级别的warm-restart和系统级warm-reboot技术，可以在不停机的情况下完成应用的部署或升级，实现快速迭代。
03
网络自动化运营应用
有了机器易读的结构化数据以及快速迭代的自研交换机系统，网络自动化应用变得顺其自然。
3.1 配置自动审计
在海量的设备与配置交错中，当前网络的配置是否变化？变化的内容是什么？跟架构的标准是否有出入？以上三省是配置巡检过程中最常见的诉求。在过去，没有对数据进行建模的时候，配置比对因复杂的文本解析难以实现。
如今基于建模系统，我们设计了一套完整的审计流程，首先介绍下两种实例的概念，从架构设计开始，结合建设单对YANG模型进行赋值，得到了规划实例，即架构的标准配置。根据规划实例建设后，运营过程中，任何的配置修改会通过每日的配置采集或动态上报进行记录，形成现网实例。两个实例的json进行比对，便输出了与架构标准的差异，反馈到运营人员，直接给出优化的目标。这个过程也就完成了网络的每日三省。
一省（是否变化）：结合高速gRPC通道，TCS支持主动采集以及自动上报配置变化，使得网络数据库与现网同步，第一时间感知配置变化。
二省（变化的内容）：配置的变化全部采用json的格式反馈，结合抽象的YANG model，配置变化在何处，一目了然。
三省（变化的是否正确）：将现网实例的json与规划实例的json进行比对，快速实现差异校验，输出标准差。
3.2 变更自动化
变更自动化可以抽象为配置修改类以及软件升级类，但这里自动化的覆盖面绝非只有“变更”流程这么简单。从方案的制定到具体的实施，实现一站式全自动化。
3.2.1 配置修改自动化
结合上文介绍的模型易编程模型，我们可以把网络配置修改以及实施到现网的过程，也看做是软件发布的CICD流程。
当网络架构的标准配置用YANG模型来设计时，可以利用层次化可复用的代码化思想来加速设计效率，比如多个架构的3A配置标准相同，可以先开发一个通用特性的程序包，多个架构同时import即可。当标准更新时，架构师只用将目光集中在特性本身，修改后自动触发线上设备的规划实例更新。
之后结合配置审计功能，得出当前不符合架构规范的设备名称以及具体需要改动的“配置”内容，而后推送到变更需求平台中“待发布”。此时运营人员只需审核需求单以及制定操作时间，结合现有的变更系统，进行批量按档速变更（包含各类监控接入，止损流程）。整个架构配置更新流程与软件发布异曲同工。
除了架构标准的更新外，配置修改最多的场景在于日常运营操作，例如端口调试，流统等。这类场景通过易编程的模型被快速实现，结合轻量化流程，供变更系统调用。
3.2.2 软件升级自动化
相对于传统厂商，自研交换机的OS、补丁以及Docker自主可控，版本的发布通过正式的CICD流程自动推送至镜像仓库以及更新状态至网络数据库，而从镜像仓库中拉取镜像以及升级的两个操作实现APP化，由变更系统的软件升级模板自动调用，结合无损技术，实现快速批量升级。
3.3 快速故障自愈
故障自愈中的“愈”并非难点，在腾讯的大型网络中，各层级多平面已是常态化。且故障恢复可通过 “优雅隔离与灰度”等手段，通过运营程序包开放调用。真正的难点在于如何快速发现&定位。
当前FullMesh-Ping机制很好的解决了网络故障中的“定界”问题，并具备一定的定位能力，为了更快更准的定位故障，我们利用自研交换机快速迭代的优势，从四个维度填充了当前的监控盲区，建立了立体化监控体系。
操作系统异常发现：通过Prometheus实现Docker的状态监控。
芯片异常故障发现：实现了秒级网元监控技术——Telemetry，涵盖缓存，芯片异常计数等多元化内容，并将相关状态模型化，纳入Tencent YANG Model，彻底替代SNMP。
网元级故障发现：借助腾讯自研的NetSense功能，实现不依赖于服务器的接入层交换机故障快速发现。
特定流&链路级故障发现：通过INT/MOD/TCP状态流监控，实现基于特定流的丢包与延时监控，将定位精度提升到链路级。
结语
在积累多年的建模系统、自研OS、变更系统等基础平台能力的助力下，TCS运营自动化体系得以快速建立，使腾讯网络正式迈向高度自动化运营阶段。展望未来，基于该体系框架，上层应用将持续整合架构仿真、故障预测以及动态验收等能力，实现从“不做错”到“不想错”的升华，最终构建“无人驾驶”的IBN网络。