NetDevOps的理解与学习路线

作者：九净

原文地址：https://zhuanlan.zhihu.com/p/139417895

时代背景：

最近几年网络运维领域各种名字满天飞，SDN、SD-WAN、双态、智能运维、大数据技术、自动驾驶的网络、基于意图的网络、NAAS、数字孪生以及我们今天聊的NetDevOps。

概念本身是为了方便理解而取的名字，做什么事情我们还是要抓住本质。而不是为了热度、为了噱头去投身其中，这样的话，事情长久不了。很多公司给我们推销过很多产品，真正能吸引我眼球的，永远是那些技术过硬、产品过硬、思路清晰的产品及公司，而不是那些包装产品外面的噱头、高大上的名词。

我们在聊NetDevOps的时候，就我而言，它的定义无需那么花里胡哨，它就是

网络运维人员针对自身运维场景，利用技术与工具提高自动化运维水平，提高日常管理、运维效率，提高管理故障排除故障的效率的工作方法及过程。

它包含了三个重要部分：

开发:开源的技术与工具、已购工具的二次开发。直白一些，就是开发，不开发就不是NetDevOps，NetDevOps离不开开发，高深浅显，或多或少，你总得写脚本或者更加深入。

场景：开发深度结合自身网络运维场景，开箱即用只是在探索阶段，后期一定会将开发植根与自己的运维基因之上，走出自己的特色。

实践：这是一种方法论在自己场景中持续实践的过程。

NetDevOps是个性化具备成长属性的，它不是开箱即用的产品，不是通过简单购买可以获取的技能。NetDevOps就好比养孩子，养的永远比其他的都“亲”。这个“亲”，就是贴合实际场景。我们应当投入心血去培养ta，给ta时间，看ta逐步成长。

NetDevOps为什么会产生？

我觉得根本原因是云计算发展必然的趋势，云计算使计算资源数以万倍的增长，势必会对网络造成不断的运维压力。从底层硬件到上层架构催生出SDN，进而产生NetDevOps这个细分的领域。

我们为什么要走NetDevOps的道路？现有的产品难道不香吗？

1、运维其实是门艺术

因为它不可复制，每家都有自己的实际情况，这就导致了很多奇葩需求与奇葩的问题，这些问题必然是现有产品或者工具无法满足的。

公司产品是做通用的，多卖，我们的场景又是个性化的，最终的结果是，产品照顾绝大部分客户的需求，然后开放部分可编程能力给用户，让用户去二次开发自己的个性需求。通用与开放的结果，是我们一定会在某些部分去着手自己开发，而且比例越来越多。聪明的卖家总会让自己的产品充满可编程接口，开放能力绝对是产品的一大卖点。

2、没有人比网络人更了解网络的需求

信息传递是有损耗的，尤其是当双方的领域不同的时候，这个天然的鸿沟会让信息损失非常大。让一个开发人员理解网络很困难，这导致开发进行的总是不顺利。但是让一个网络人员了解开发，借助于现有的开源与大环境，我觉得是非常容易的。因为很多人大学至少学过C、C++等等，网络工程师中很多是计算机体系的，但是极少有人在上学的时候学习路由交换，因为条件不允许、环境不具备。这样的一个网络运维人员利用自己的领域知识，加上开源技术，便可以快捷的实现自己的需求。如果这个团队可以有序的组织利用，便可孵化出很棒的工具乃至平台（多少先进的网络开源工具框架，其实都是运维工程师写出来的，而不是软件工程师）。

（特别想插一个例子，很多金融的人都在使用python做量化交易或者处理日常大量的表格。编程能力，在未来很多领域而言，一定会像掌握一门外语一样重要，如今很多儿童教育机构也都瞄准了儿童编程教育）

3、用未来规划现在

未来的网络一定是SDN的网络，未来的网络一定是逐步脱离CLI，同时更偏向overlay。它的运维一定是在运维平台的web界面上操作。

通过可编程能力，在SDN网络之上构建各种应用，给自己给上下游。从企业，从个人，都应该向这个方向前进，这样才不会被淘汰。

NetDevOps学习路线

网上很多NetDevOps的学习路线和脑图，我个人觉得有些地方过于略，有些地方过于复杂。比如编程开源工具讲了chef，Linux列了awk，还列举了一些常用的常用工具。有些知识根本就是系统运维工程师的领域，作为NetDevOps，我觉得应该根据网络运维的特点，提取最精华的地方，毕竟学新的网络知识已经很痛苦了，咱们能省点是点。后续组织架构中应该会有分化：一部分人会逐步转向开发，且全部的人都需要了解开发了解开源。

第一部分，我希望大家都掌握，剩下的希望大家都了解。

根据我的一些理解和实践，我会倾向于以下一个学习路线。本来也想画个脑图，但是画了也不是很满意，我们上干货吧。

1、基本编程能力

python，网工必备，如果你是从零开始，不用考虑别的。开发语言也是围绕python展开。

python掌握核心的：

a) 基本数据类型，定义变量

b) 判断、循环

c) 函数

d) 文件操作

e) 表格操作（请用pandas，跳过xlrd xlwt）

f) ssh设备交互首选netmiko，也可以选paramiko和pexpect

g) Netconf设备交互只有ncclient一条路，或者是一些基于之上的封装，比如Nornir的一些包

h) RESTful API 设备交互，学会用requests

i) snmp 说实话，我只是极偶尔用，可以忽略。

j) 解析文本 Textfsm，ntc-templates，后者内置很多的解析模板，覆盖很多设备。二者可以与netmiko有机结合，很强大。

k) 模板管理，jinja2，基于参数生成配置，很棒，我们就是应该聚焦参数，以及得出参数的过程中。

l) 多线程多进程，大家量力而行，尤其如果是下发配置，建议老老实实for循环。如果深入想做多线程，我推荐基于celery框架。

自己习惯的操作系统即可

掌握以上，我觉得自己写很多脚本工具就可以极大的提高工作效率，脚本之后可以构建web应用，好处很多，不赘述。以下的知识大家按需学即可。

2、 web应用

a) python的web框架：django、flask、FastAPI。各有千秋，网上很多比对的文章，我个人比较推荐django，高大全。

b) drf，django的一个rest API框架，其他python web框架也有对应的rest框架

c) 往远了走，一定要做API，前后端分离。以后你的每个运维动作或者服务背后都是一个个API，你将来提供的是基于网络服务，一定是基于API的。

d) 前端，浅了就是html js css，深入点推荐vue 及element。

2、系统知识

Linux知识，你懂也行，不懂也没事，现在很多语言都跨平台。往深了走，建议了解。

先是基本的操作、安装软件、操作文件。

后续可以看看docker。

3、版本管理

可以自己搭建gitlab，借助docker比较方便。

国外希望借助于git 、ansible做网络变更，大型数据中心不是很推荐，安全、审计、流程上问题太多。简单做脚本、工程的管理即可。

4、数据库

借助于django这些框架的ORM，可以屏蔽sql语句，底层使用postgres、Mariadb、MySQL、sqlite我觉得都可以，看数据量。

一些特殊情况可能借助于内存数据库或者文档型数据库时序数据库。其实常用的就是redis、MongoDB、ES、Prometheus、influxdb。我会尽量让技术栈单一一些，不会过多选择，毕竟我们还是网工，应该聚焦场景及实现。

5、开源技术

a) ansible 网工必备，在一些环境不复杂的网络中，它是神器。大型数据中心中，新老交替，我始终觉得水土不服。原生就是给系统的，硬生生安上网络的一些功能，是可以简化，但是在复杂网络、流程审批、安全审计方面，我觉得问题挺多的。

b) Nornir 比ansible更贴近网络运维，但是还是基于脚本和命令行的，我始终觉得未来的运维肯定是基于web界面多一些基于、参数多一些。二次开发比较适合。或者同上，不复杂的网络中可用，也推荐使用，国外很多网络运维的人都推崇这个，而不是ansible。

以下部分不负责任：

c) Elastic Stack技术栈，俗称ELK，ES可以很好的处理文档类数据、日志，分布式可扩展。Kibana可以自由定制可视化界面

d) 日志较多的时候可能需要kafka等中间件。

e) 监控的话，我了解不多，zabbix、Prometheus（同时也是时序数据库）、grafana也可以实现告警（同时也可以定制可视化），实际各家都有自己的监控，按需二次开发应该是重点，如果是小型公司可以在其中进行选型。

f) 网络的AIOps，这真是个大坑，我觉得时序数据方面的可能比较成熟一些（自然语言处理咱们基本用不到，chatops 我真觉得就是忽悠人的），当然运维中的很多问题都可以将数据巧妙的转换，从而将解决A问题变成了解决B问题的简单过程。日志方面也有很多成熟的一些算法，但别指望机器可以像人一样看待日志，完全视角不同。