之前写了一些技术的，今天扯扯闲篇。
最近几年网络运维领域各种名字满天飞，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、版本管理
git
可以自己搭建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问题的简单过程。日志方面也有很多成熟的一些算法，但别指望机器可以像人一样看待日志，完全视角不同。
以上，是我个人对NetDevOps的一点认识和学习的过程，简单分享一下，有问题大家可以私信多交流，后续会根据以上路线展开一些讲解。
本公众号（NetDevOps加油站）的分享的内容以后会分为两种，一种是个人见解（欢迎拍砖），一种是干货（欢迎分享，我会着重引入国外圈子里的一些内容，从视频或者博客中摘取翻译理解的）。