NetDevOps闲谈

近几年来，随着Cisco Aci在我们数据中心的成功落地，使我从传统网络进入了一个更广阔的网络领域--SDN。集中化的管理，分布式的控制，可编程的网络无疑都让我感觉在网络运维中开了外挂，不仅可以轻松驾驭一个数据中心，还能把更多的精力投入到网络创新中。随着SDN的快速迭代，又衍生出了SDN-WAN, SD-Branch,基于意图的网络，NAAS等各种概念，而今天我要聊的是NetDevOps，与各种软件定义网络的概念密切相关。

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

就我而言，NetDevOps的定义无需那么花里胡哨，它就是：网络运维人员针对自身运维场景，利用技术与工具提高自动化运维水平，提高日常管理、运维效率，提高管理故障排除故障的效率的工作方法及过程。

它包含了三个重要部分:

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

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

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

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

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

为何要从传统网工过渡到NetDevOpt开发工程师
1、运维其实是门艺术，因为它不可复制，每家都有自己的实际情况，这就导致了很多奇葩需求与奇葩的问题，这些问题必然是现有产品或者工具无法满足的。公司产品是做通用的，多卖，我们的场景又是个性化的，最终的结果是，产品照顾绝大部分客户的需求，然后开放部分可编程能力给用户，让用户去二次开发自己的个性需求。通用与开放的结果，使我们一定会在某些部分去着手自己开发，而且比例越来越多。聪明的卖家总会让自己的产品充满可编程接口，开放能力绝对是产品的一大卖点。

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

3、用未来规划现在，未来的网络一定是SDN的网络，未来的网络一定是逐步脱离CLI，同时更偏向overlay。它的运维一定是在运维平台的web界面上操作。通过可编程能力，在SDN网络之上构建各种应用，给自己给上下游。从企业，从个人，都应该向这个方向前进，这样才不会被淘汰。