作者:九净
原文地址: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问题的简单过程。日志方面也有很多成熟的一些算法,但别指望机器可以像人一样看待日志,完全视角不同。