自动化时代网络工程师价值何在？

不管网络如何发展和改革，监控功能一直都存在。这就是为什么网络工程师的角色仍然至关重要的原因之一。

过去几年里，行业内一直充斥着诸如“网络将永远是相同的”，“网络工程师的角色已经不再需要”，以及“所有网络工程师都需要去学习写代码”这样的观点。

我不赞同，在这篇文章里我会告诉你为什么我认为网络工程师的角色仍旧至关重要。主要是两点：监控和故障排除。

从 18 年前我开始成为一名网络工程师到现在，网络监控功能大致维持不变。

让我们一起来看一下在现代化网络中，监控功能是如何运作的。跟踪一个生产网络的状态并不容易，以前我反复假设过很多次，认为有效监控网络的关键是对重量级的把握，这可能比创建一个网络并保持其运行更困难，尤其是运营商和服务提供商的网络架构。造成这样的结果有几个原因，其中最大的在于机构用于获取数据的简单网络管理协议（SNMP, Simple Network Management Protocol）。

在我踏进这个行业之前，简单网络管理协议（SNMP）就已经存在很久了。而且，它看起来应该还会存在更久。简单网络管理协议（SNMP）给轮询数据和推动事件都提供了基本要素。而且，其问题在于很神秘。简单网络管理协议（SNMP）让网络设备和虚弱的 CPU 捆绑在一起，不仅如此，它还经常被贫困和笨重的主机堵塞。

尽管存在这些问题，简单网络管理协议（SNMP）却没有合理的替代者

不幸的是，对于网络工程师来说，没有合理的替代来获取这样的网络性能数据作为接口计数器、错误统计、CPU 负载、三重内容可寻址存储器信息或功率信息。简单网络管理协议（SNMP）就是标准。结合简单网络管理协议（SNMP）、简单网络管理协议（SNMP）陷阱、系统日志数据、互联网控制消息协议数据、延迟信息以及吞吐量信息，网络工程师就有了合理的网络监测基础。

那么网络工程师又该如何使用这些监测基础信息呢？如何利用这些信息来促进软件定义网络、DevOps 的发展，在未来 5 到 10 年改变网络监控？

让我们通过一些示例来分析。示例中我们将数据中心和局域网的刷新周期假设为3-5 年，广域网刷新周期为5-7 年，而传输刷新周期通常为 10 年。

示例一：在一个给定的数据中心，你部署了一个典型的叶-棘式网络。你如何得知一片叶子故障了？很可能是通过一则系统日志消息或者一个简单网络管理协议（SNMP）陷阱。如果问题出现在网络边缘，也可能是通过一则 OpenFlow 消息得知故障。这个功能又如何连接到现有的网络运营中心（NOC, network operation center）工具呢？网络运营中心（NOC）可以监控到这一故障吗?当然会。因为传统的监控和报警系统会有一个链接。链接？指的是绿地吗？绿地也是一个公正的说法。然后网络运营中心（NOC）将会检查控制器拓扑界面。所以以后故障的获取和处理这一切会如何发生呢？我打赌还是要使用以上提到的方法之一。

示例二：服务提供商 MPLS Network 正在使用类似 Border Gateway Protocol Link-State，OpenFlow 1.3 或可能只是内部开发的 DevOps 工具。那么网络工程师怎么知道标签交换路径中出现了问题呢？如何得知一个暗光纤路径无法切换到冗余路径呢？网络运营中心（NOC）又如何得知这些消息？你或许已经猜中了，三种方法：简单网络管理协议（SNMP）陷阱，系统日志或拓扑图（基于简单网络管理协议（SNMP）的一种方法）。

代码技能是很有价值的，但是......

DevOps 和编写代码技能都是很有价值的。我必须要学习，许多在关键网络管理平台、整体网络管理平台、无线和软件定义控制器、厂商支持的自动化系统，以及点击式管理软件方面开始职业生涯的人们也必须学习。真正把事情解决的唯一方法就是自己写代码并运行脚本。

但是，说网络工程师功能已经“死掉”是目光短浅的错误看法。基本的网络工程师功能在至少未来十年里是必需的，甚至更久，许多基本的技能，如解决低级别的故障，会继续保持。

最有经验的网络工程师至少会熟悉几个可用的管理系统，虽然关于这些系统的技能和知识可能会随着时间褪色，但是这些工程师不会消失。往昔的知识价值可能会渐渐风化，但是至少一小部分相关从业者会需要这些技能。

如果说写代码和网络工程师的联系，那就是学习写代码的工程师只是为了巩固网络专业技能。他们需要拥有去探索网络的胆量，去钻研别人不敢触及的深奥难解的角落，而这些角落将被那些拥有不屈不饶的动力和勇气的人征服。

说了这么多，其实在 IT 行业，唯一不变的就是变化。今天软件定义网络和 DevOps 的繁荣就证明了这一点。我们都必须适应这些发展，否则最终会步渡渡鸟的后尘。而这一切的核心，就是愿意接受改变，这也是 DevOps 技术的核心。