在《2012网络技术趋势：带外管理与DevOps(一)》介绍了VDI如何帮助企业实现IT消费化，以及企业如何满足的虚拟桌面基础架构,《2012网络技术趋势：带外管理与DevOps(二)》说明了为什么带外管理会流行，以及构建带外管理网络。最后本文将切中要点：网络工作人员不希望别人在他们的交换机或路由器中运行脚本。那么如何开放网络，允许DevOps工作人员参与进来?
对于网络架构师而言，如何选择建立带外管理网络的合适时机?
MacVittie：我喜欢积极主动的性格，但现实并非总能如我所愿，积极主动的人并不多。我认为大多数人都会在难以区分管理流量和实际业务与客户流量的时候，才选择建立带外管理网络。此时，二者的界限变得模糊，你很难在网络中找出你需要看到的;交换机端口过载导致丢包和信息丢失时有发生;你也无法获取你需要的全部数据，弄不明白为何某些功能失效;你甚至无法察觉某些配置已经失效。
F5曾经预言网络将会与诸如Chef和Puppet的脚本技术整合。为什么?
MacVittie：Chef和Puppet是DevOps运动的两个主要工具。该运动尝试将开发过程中的方法和步骤引入IT运营中。Chef和Puppet允许用户创建脚本，这些脚本可以用来自动配置虚拟机、BIG-IP、交换机或者其他网络解决方案。这正是为什么网络API和集成能力越来越重要。
DevOps工作人员的任务是什么呢?“这有一个应用程序，我需要你编译部署脚本，从而将虚拟机部署到适当的地方。务必确保配置好负载均衡器，添加防火墙规则并且将其连接到X，Y，Z。”他们接受了这一任务，编译源程序包，使用诸如Chef和Puppet的工具在不同的网络组件之间通信，并将它们打包到一个安装程序包中，以便他们仅仅通过点击鼠标就可以完成部署工作。当用户需要加载另外一个实例时，DevOps工作人员可以告知用户通过简单的点击来部署，所有组件都可以正确衔接，无需额外干预操作。
我认为不是所有网络工作人员意识到这一点。DevOps工作人员往往出身于服务器管理员和应用管理员，他们参与进来并且希望仅仅专注于运营操作。同样，网络工作人员不希望别人在他们的交换机或路由器中运行脚本。而又有谁能够责备他们呢?早在可编程路由器问世之时，这些争论就开始存在了。你疯了么?想要试图动我们的核心路由器。所以对于允许DevOps工作人员参与进来做事情，我认为有许多阻力来自于网络小组。但是，最终，DevOps工作人员的参与将会变得非常重要。
对于应用程序的实现和发布而言，网络是非常重要的一部分。如果我们不能在自动化过程中包括网络部分，协调安排网络、复制包含整个网络的可成功部署程序包的能力，那将会引发以下感触：“我们讨厌网络技术，让我们去尝试云计算，不要再去关心交换机和防火墙。”我认为如果网络小组打算继续发挥重要作用并且不断演进的动态数据中心，那种观念必须发生转变。
因此网络专家必须扮演什么角色?他们需要将其基础架构开放以便于通过脚本技术操控它们吗?
MacVittie：他们必须意识到这样做是必须的，通知其小组工作人员为其他小组操控访问提供条件。或者，如同看待刷新周期一样，他们应当开始审视那些包含基于角色访问API的网络基础架构。因此你可以说：“好吧，你是该VLAN下的开发人员，我允许你对其进行改动，但是不论发生什么，那将是你的问题，与我无关。但是你不能接触与财政相关的VLAN，因为那对业务至关重要。”他们需要变成看门人而不是牢房看守。
你如何评估个别供应商的集成能力?
MacVittie：我的职业是开发人员，我可以玩转它。但是那并不适用于大多数网络工作人员。大部分网络工作人员都对脚本语言非常精通，但是对于开发需要的API却知之甚少。所以他们需要询问供应商：“你有一个开放管理的API吗?都支持哪些语言?”而他们也可能会去询问DevOps工作人员：“你正在使用什么?”然后根据回答进行评估。“你是由于这些东西是标准化的而支持它们的吗?即便我不理解Chef、Puppet或是基于PHP的REST API意味着什么，但那正是我需要。”因此他们需要将问题罗列在一起，然后开始询问。
考察管理供应商也是很重要的。传统问题同样甚至更加有用，因为CA、IBM和VMware正在向该领域发展，而且越来越意识到管理整个基础架构不仅仅是通过SNMP协议抓取一些状态信息那么简单。那不再是一个管理信息库。我必须能够通过一个更加简洁的接口来实施控制，那意味着通过传统的基于Web和REST的API以及脚本语言实现。这些内容网络工作人员或许不太熟悉，但是对他们而言，获取问题列表和仅仅询问标准问题同等重要。
相关文章链接：
