本文章整理自SDNLAB一期一会第10期直播分享
分享嘉宾:王旭涛,毕业于北京邮电大学网络技术研究院,现就职于中国银行信息科技运营中心。
当我刚开始学习NetDevOps的时候,发现国内这些资源很少,很多东西都取自于国外的博主、厂商,或者社区资源,因此我萌生了一个想法,希望可以把我对于NetDevOps理解与学习路线分享给大家。首先声明,本次分享仅代表我个人的观点,不代表SDNLAB和我所在单位的立场。
一、云时代我理解的网络运维之痛
在云计算的时代,我从一个底层运维工程师的角度,通过我做自动化运维的亲身经历,看到它正在面临非常多的挑战。
面对如此多的挑战,运维工程师可以说是太“难了”,那么新时代的运维究竟有哪些难点呢?我们又该如何应对?
运维难点:
解决方法:
二、云时代的网络需要NetDevOps
现代化运维难点的解决方案,就是自动化。目前大多数人都清楚,将来网络一定是无人值守的运维,因此我们需要NetDevOps。
新时代在效能上对网络工程师的要求越来越高,但是运维工具成本和人力成本上反而是压缩的,这也就要求广大网工们做到敏捷运维、自动运维。所以现在做NetDevOps是一个比较好的时机,我们通过NetDevOps能够做到什么?
运维领域其实有很多不同的领域,我们在运维过程中,可以通过自己编写的脚本,去把我们的人力消耗极大的那部分重复性的动作覆盖,其覆盖的范围比一个工具广泛很多。NetDevOp带给我们的东西,本质上就是自动化水平的提高。
三、我的NetDevOps学习路线分享
对NetDevOps的理解:网络运维人员针对自身运维场景,利用技术与工具提高自动化运维水平,进而提高日常管理、运维效率的工作方法及过程。
开发:基于开源的技术与工具、已购工具的开发与使用
场景:开发深度结合自身网络运维场景
实践:这是一种方法论在自己场景中持续实践的过程
下面从我个人这几年做自动化的经验来分析下,个人以及团队NetDevOps转型的路线,以及一些需要注意的点。然后给大家分享一下我的技术堆栈和学习路线。
1、个人的NetDevOps转型
思想的转变:网络运维将来一定不会是现在这种人肉运维的方式,一定是高度自动化的运维。
思路的转变:重复性、有规律的工作内容能否用自动化的工具去解决
持续的学习:NetDevOps是需要持续学习、不断吸取营养的一个领域,没有一劳永逸。
选取最合适的工具:合适的工具(包括开发语言)可以帮我们节省大量的时间。
不断的实践:一方面实践能看到成果,品尝收获,另一方面只有不断实践反馈才能进步。
清楚自己的定位:学习哪些知识,学习到什么程度要因人因岗位而异。并不是每个人真的都要去开发,但是每个人最好都了解NetDevOps,了解其思想和当下的趋势、技术。
2、团队的NetDevOps转型
思想观念的转变:网络运维将来一定是软件层面驱动更多的网络,需要更多具备NetDevOps技能的运维人员。
培养一支自己的NetDevOps队伍:网络专业领域知识强,拥有一支自己的NetDevOps作战部队可以最小损耗最快速度的实现你的想法。
勇于尝试,小步快跑:勇于投入一点人和一点时间去尝试,敏捷的方式看看值不值得。
路线要明确,注重性价比:要注重性价比高的运维场景,能最大减少人力或者提高网络的稳定性、应急能力等。
队伍逐步的转型,由点到面:人员的转型、场景的实现都是由点到面,逐步实现。
我的学习路线分享:
我推荐的技术堆栈-基础篇
开发语言:Python
前期:需要掌握的内容:基本数据类型、控制(判断、循环)、文本操作
后期:面向对象的编程能力,归纳总结抽象自己的工具类、装备库
IDE:Jupyter Notebook、Pycharm、 VSCode
我推荐的技术堆栈-运维必备
网络层面新协议新技术:
运维工程师必备新技能
我推荐的技术堆栈-网络自动化框架
我推荐的技术堆栈-网络服务化
我推荐的技术堆栈-系统知识提高
我推荐的技术堆栈-一些优秀的资源
除了网络自动化框架、软件的官方文档外:
四、抛砖引玉
我认为未来网络运维会越来越脱离CLI ,更加聚焦数据,也就是你的参数。从系统运维就可以看出来,他们可能很多东西都不是基于CLI的,而且基于脚本封装的一些东西。NetDevOps应该是开发、架构、产品等各种技术及思想在网络运维领域的实现。
我们一定要用未来去规划现在走正确的道路。希望今天的分享能够把自己对NetDevOps的理解,以及所掌握的技术,分享给每一个愿意投身其中的网络运维工程师。如果大家对内容有任何疑问,欢迎大家关注我的公众号“NetDevOps加油站”,与我进行交流。
【转载须知】
若转载文章为原创文章,可在相应文章下或公众号后台留言;其他非转载类文章须在文首以不小于14号字体标明转载自SDNLAB。