用几行代码管理几十种网络设备

本文主要是介绍用几行代码管理几十种网络设备，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

引言：在运营商背景环境下，运维是阻挡不了各路大佬的规则的，当面对一个庞大组网架构，而其中包含了14种品牌厂商、30多种设备型号的网络设备时，我们一开始是拒绝的….但是最后算是艰难成功了。这篇文章给大家分享一下我们是怎样实现统一自动化管理的。

王喆，来自“码蚁”团队（南方基地移动云运维团队），目前任职于Ecloud运维研发团队，负责运维平台产品设计以及研发，同时负责火炉山蚁群公众号的运营工作。

本篇文章的目的：

本篇文章适合人群：

我先放两张图让大家感受一下：

可以看到，无论设备数量和种类如何疯长，负责网络运维的一直只有四个人，老板一直无视我们的加人请求，老板一直非常相信我们的能力。

正常来说单纯地增加设备数量并不会带来多少压力，而设备厂商的增多就是另一回事儿了，不同于X86服务器挂载相同的操作系统，网络设备系统往往是封闭独立的，有着截然不同的指令手册，以及各种特殊的功能。总而言之，它们很难统一。

我再放两张图，是日常运维中很常见的场景：

故障定位，从出口路由器一直沿路查到用户虚拟机是一件很常见的事情，这个过程中可能会经历路由器、防火墙、三层交换机、二层交换机、负载均衡器等等设备（它们来自不同的厂商）

策略管理，刨去复杂的流程之外，不同的策略要定位到不同的网络域中，要在不同的防火墙上做操作（也是不同的厂商）。

如果一开始就拿这些场景去做自动化，会无从下手，或者会写出一大堆复杂重复的脚本来，效率不高；看过前面拥抱开源系列文章的同学可能会想到用现成的工具，例如Ansible，很可惜它不能管到这么多种设备。

看来只能自己动手了，接下来为了便于理解，我们不去想上面的复杂场景，用一个简单但又耗时的小场景来思考：

先看一下手工要怎么操作：

紧接着第一个想到的肯定是写脚本来实现：

不错，我们已经把工作量压缩到三个脚本中了，但是这样的程度人人都可以，而且是不够的（后面会讲为什么这样是不够的），我们需要更高效，利用率更高的方法。

在做这件事之前，让我们站在高处分析一下：

（1）我们的大团队中包含网络运维（简称运维）、平台研发（简称开发）、一线运维（简称一线）以及更多的团队。

（2）经过早期团队标准化和自动化工作的推进，运维已经具备了全员写脚本的能力，如果可以，他们更愿意自己写脚本，而非到开发那里提需求、排期，因为这样太慢了。

（3）经过早期人工运维的时期，运维已经掌握了大量的运维经验，沉淀出很多的大大小小的运维场景，每种场景需要的自动化能力是不一样的，所以如果能自己实现，运维仍然是不愿意去交给开发实现的，因为这样不仅慢，而且还可能要沟通很久。

（4）在全员实现脚本能力之前，开发是会经常收到各种各样奇怪的需求的，并且不得不排期，一个一个实现并集成到大平台中，时间久了这个平台也变得臃肿不堪，丧失功能定位。

（5）运维有一部分工作是可以前移给一线的，这样一线可以直接解决掉客户的问题，避免后续麻烦且费时的工单流转。当然，不是“免费”前移的，一线并不会深入学习这些复杂的组网架构，运维需要把场景浓缩成为简易执行的脚本或工具，才适合前移。

综上，我们应该做一个工具或者模块（我们使用python），它可以：

称呼这个模块叫做Forward，它的目的是使团队的分工模式变成这样：

完美！

开发专注于丰富底层原子操作，不再身陷各种奇怪需求中；运维可以用它自己动手、快速实现目标。

制定好目标了，然后需要决定从哪里下手，我模拟了网络运维的场景，所有场景都可以归纳为这样的步骤：

这张图也解释了为什么直接写脚本是不够的，当设备种类和维护场景都很多的时候，会浪费大量时间在脚本的重复功能上。

仔细检查上图后可以很容易分析出哪些环节适合自动化，哪些环节适合留给运维去“装配”的：

经过这样的处理后再去写脚本，就舒服多了，运维也可以在第三个、第四个环节转化自己的运维经验了。可以说：这样既体现了开发的价值，又保留了运维的发挥空间。

为了实现Forward的目标状态，我们构思了一个简易的代码层级架构，如下图：

根据功能的特性：

把重复性最高的原子类操作放到最底层，例如底层连接协议的实现等；
中间层是类库封装，经过了这一层后所有设备对编程者来说就都是统一格式的类库了，屏蔽掉了异构系统差异，这一层是整个模块里比较核心的部分，下面将会用一个章节来详细介绍；
上层就是模块主程序层了，主要做一些流程初始化、多线程的事情（例如类库批量初始化和登录，这种密集网络IO场景非常适合PYTHON多线程），负责和编程者脚本对接。

换到宏观角度来看实现，如图：