当NASA在本月发射猎户座飞行器时，它不得不暂停自动风向传感器，转而由人工来确定风向是否正确。实际上，SDN工程师却没有太多的空间可以尝试停止网络自动化……

我也承认这个观点，我本身也是一位空间极客。更坏的是，我偶尔还是一位飞行员、认证调度员，我的IT生涯始于一家航空公司。上世纪70年代，我在孩提时就观看了阿波罗号发射升空，和许多工程师一样，我也在追随技术发展，从非凡的Werner von Braun手工焊接热机械似的庞然大物到现代更复杂的小型电子化空间系统。

在之前新型猎户座多用途航天飞行器的首次发射计划推迟后，我最近又观看了它的首次成功发射之后，我认识到SDN与可编程网络也将遇到与NASA发射系统相同的挑战。我们都在依赖网络自动化，但是有时候我们需要人工干预。两者的最大区别是，企业IT必须提供持续在线时间，几乎不存在允许一项事务暂停的可能性。

猎户座的主要通信方式是以太网

猎户座携带的中央数据网络是以太网。再详细点说，生命支持、导航、推进器点火、通信与模块交互协调等等，所有方面都通过时间触发的千兆以太网实现互连。确实，这个网络采用了一种IEEE 802.3的私有实现，但是它具有兼容性，增加了一种可靠消息交付分类。此外，它的速度比国际空间站采用的技术快1000倍，并且还包含抗辐射的ASIC，它很像每一个核心交换机都采用的技术。

和现代企业网络类似，最有意思的是猎户座网络将多个原本分散的服务集中到一个电路上。它混合了关键指令流量、最佳文件拷贝和中级语音及视频（但是延迟和抖动要求较高）。与企业网络不同的是，猎户座的网络工程师更关注于保持大带宽，更依赖于芯片，而不是路由器的QoS策略映射。

由独立软件定义的决策过程

在猎户座发射时，瞬时风力曾经两次让发射流程自动中止，而且中止就发生在倒数期间。这迫使飞行主管焦急万分地喊出：“中止！中止！中止！”然后团队作了一个预警决定——它禁用了自动风力传感器，转而采用阿波罗时代的控制方式——由人来观测风速和风向等指数。

回到SDN和网络自动化，我们也会遇到类似的问题。我们将来能交付一些自动决策系统，但是我们也知道在一些特定环境下需要一些人工干预。

然而，IT面临着一个NASA遇不到的特殊挑战。如果NASA没有备用系统，那么它可以选择推迟发射。但是企业IT不可能这样做。我们一直在压力中保持系统能够承受所有这些问题，然后保持不间断地正常运行。可是，在压力下快速作出决策时，安全性往往会成为网络质量中被牺牲的一个方面。

在猎户座首次发射时，有一位经验丰富的飞行主管专门负责监控一个简单的发射/不发射的倒数控制项。这位飞行主管将自己多年的经验用在监控一个重要的SLA指标值。但是在SDN的高度虚拟化聚合网络中，我们不可能有足够多的飞行主管去监控每分钟可能出现的100、1000或10,000个访问策略冲突。我们必须将服务交付需求加到应用程序之中，在SDN控制器中部署安全策略访问规则，然后再退一步，让自主配置的网络自行挑选。

报告：我们遇到了一个网络管理问题

我们的挑战是，在网络运营中心(NOC)控制台发出大量的策略冲突警报时，我们当前的管理与修复方法是无效的。想象一下现在的vMotioning的应用场景，它不仅可以监控一个集群中不同的ESX，也可以监控打包为支持用Docker传输的虚拟机，它们可以每天大批量、自动地从亚马逊迁移到本地数据中心或Azure。这些实例可能会经常与定义的访问策略发生冲突，因为我们的控制器会动态寻找更高效和更划算的配置。当找到这种配置时，我们就必须知道如何教会网络使用这些配置。

这也是从NASA学到的一个经验教训。无论是一个离火星20分钟的任务，或是一个离柯伊伯带4小时的任务，探测器都必须自主运行数十年时间。在30年前，这很多时候都由计时器和猜测来完成，但是现在他们使用一些机器学习技术和大量预编程策略定义，让机器自动作出重大决策。

作为管理员，我们必须学习如何将自己深厚的网络连接知识和从各个网络获得的专业技能转化为智能规则，而非只是一些静态配置。简单的允许或阻挡决策变成了在什么条件下允许或阻挡。QoS分类也需要感知时间/阻塞环境。我们的网络性能监控系统不仅需要监控IP范围，也需要基于设备发送的流量来自动发现设备。

NASA做到的我们也能做到

NASA的官方行为给了我们希望。NASA有着全世界最聪明的工程师，但是他们的探索激情需要经过一系列繁文缛节的考验，其复杂程度远远超过我们在办公室要面对的步骤。但是，他们仍然能够成功实现毫无差错的伟大工程壮举。只有少量的经费，一点点高明的管理，再加上正确的工具，SDN就可以让管理员给原本繁杂的手工配置网络添加真正的智能。但是，我们可能还需要在各个位置部署一些抗辐射的以太网。