2、制造自动化运维工具

第一章中的组合拳打完之后，基本上不会出现“意料之外的故障”，所有的异常都应该有据可查，当SRE莫名其妙提出对网络环境的质疑时，你应该早已心中有谱。但是网络工程师的工作并非只有救火，日常运维工作中，经常需要配合业务发展做一些线上变更/ 机房扩建／业务类故障排查等。作为一名“懒惰”的网络工程师，程序可以帮忙点什么忙呢？

UserDevice Tracker

这个名词借用于Solarwinds套装中的一个组件，直译为“用户设备追踪器” ， 在中小型企业网运维中，经常会有这样的需求：

知道服务器的IP，请问连接在交换机的哪个口？知道交换机的某个端口，请问连接的服务器的IP是多少？给你一台服务器的MAC地址，怎么知道在哪个交换机的哪个口？大型互联网公司一般会有CMDB或者网络管理平台来记录这些信息， 但是如果你是一家中小型企业的网管，没有运维研发团队做支持，并且还在沿用二层的环境（服务器网关在核心设备），那就比较费劲了。以上几个问题其实归根到底是要捋清楚三个要素的对应关系： PORT<>MAC<>IP

举个例子：

一台交换机有多个物理接口，一个物理接口下可以有多个MAC，一个MAC可以对应多个IP，或者不对应任何IP。 有了这个基本的模型，只需要做两件事情即可找到全网设备这三元素的对应关系。首先去服务器直连的交换机获取MAC表（即MAC<->PORT）， 然后再去服务器的网关设备获取ARP表（即IP<->MAC），这两张表根据MAC地址作为唯一主键即可得到 PORT <->MAC<->IP 的对应关系。 信息的获取可以通过模拟登陆或者OID采集均可，Github中也有很多类似的代码可供参考，有了这个对应关系，即便没有CMDB，你依然可以快速定位想要的信息， 普通网工查找这个信息需要5分钟， 而你只需要5秒钟。

网络设备向接口的二次封装

日常网络运维工作中，经常会有一些 “简单重复劳动”，例如：为某个接口划分Vlan／给某台设备添加一条指向主机的路由等， 这些操作即没有科技含量，还占用了工程师宝贵的时间，更要命的是再简单的人肉操作，重复的次数只要足够多，总有失误的时候，正所谓“常在河边走，哪有不湿鞋”，但是在这种问题上犯错误简直是对职业生涯的抹黑，如此“鸡肋”的工作怎么才能干的漂亮？

以《自动划分交换机接口Vlan》的功能为例， 如果有一个工具只需要你提供三个参数：设备IP／端口／vlan编号， 就能自动登陆设备把特定接口划分到指定Vlan，那岂不是美哉。没错！你需要的是一个对设备封装后的接口， 现在多数网络设备厂商都会提供自己的API，无论是NETCONF还是RESTful，只要读懂了使用手册，即可通过程序轻松变更设备的配置，甚至你可以用更加”接地气”的方法，用程序“模拟登陆”设备 ，虽然这个方法在效率上比不过NETCONF和RESTful API，但是在通用性上那简直无敌，因为没有哪个厂商的设备不支持SSH或者TELNET的。

有了这个理论基础，一些简单的网络上的操作就可以通过自己封装的接口来实现变更，甚至可以把变更的权限交给业务，只要业务提交的请求是合法的，变更可立即上线生效。此时，肯定会有人大惊失色！把网络设备的权限交给业务，这样真的好么？万一改坏了怎么办…所有的疑惑都是正常的，同时也都是有解的。还以《自动划分交换机接口Vlan》举例子，你可以限制程序执行的内容，你可以规定交换机只能是TOR不能是CSW，你可以约束接口只能是Access不能是Trunk，你可以限定被操作的接口下流量必须为0bps，以避免误操作影响到业务，你可以通过动态Token保证接口的安全，你可以要求必须提供接口下现存的MAC以定位接口的位置，你还可以对调用者加白名单，另外，操作成功后还需要有短信+邮件反馈操作后的结果，等等…

所有的考量都可以固化为代码规则，只有程序是最忠实的执行者。接口可以提供7*24 小时全年无休的服务，而人的精力是有限的，用程序去应对业务那些简单有规律的需求，节省出工程师宝贵的时间来思考人生，这才是网络工程师自动化运维之路的正道。

总结

以上，是笔者结合自身工作经历总结的一些心法，写代码对于网络工程师来说确实有些难度，但是只要跨过这道坎，你会得到更多富裕的时间来扩展自己的专业道路，谨以此文，希望能抛砖引玉为自动化网络运维尽绵薄之力。