思科渠道微情报 思科联天下
半夜，急促的手机铃声像是一记耳光，把还昏昏沉沉的你一巴掌扇醒。“赶快回机房，新迁移的那批机器好多都不通！”你一边穿衣一边嘟囔“明明是测通了才走的，怎么也不先看看是不是应用和系统的问题，只要不通就找网络”。
这场面，作为网工的你是不是似曾相识？随着软件开发流程的自动化，各类按流水线编排的工具帮助开发团队自动完成代码的提交、测试、集成和交付，应用部署需求比以前频繁得多，每次有新产品上线或原来的产品迭代更新，整个基础架构团队就要被折腾好一阵子。这不，最近新业务的上线又要把一批老业务迁移到同城另一个数据中心，对应一批批VLAN、网关、路由等等有的要创建、有的要做参数变更、有的临时措施还要在迁完恢复回去，晚上你在变更窗口内做的就是一批VLAN的二层延展和另一批的恢复，但你可是等到应用调通才回家的，怎么半夜又不通了？
带着起床气的你赶到机房，确实有的通，有的不通，一通操作猛如虎，最终查到ARP和IP/MAC表时你猛然意识到自己可能的疏忽——一定是迁移并行期所需的VLAN参数与迁移完成恢复正常模式的VLAN参数搞混了，前者要打开ARP、未知单播等泛洪以保证能穿越大二层隧道实现跨中心通信，后者将这些特性关闭以提高通信效率和稳定性。确实，你记得昨天晚上在勾选完二十多个VLAN、每个VLAN十来个下拉菜单和复选框后，你的脑子都木了，肯定是一时糊涂有些VLAN的洪泛开关没有打开，造成一些表项在你睡梦中超时老化导致不通。找到原因的你起床气渐渐变成了对自己未来的担心——随着软件团队敏捷性的提高，将来这种短时间、大批量、混合任务的变更会越来越频繁，有什么办法保证自己不出类似的错呢？
本栏目曾经连载过三期的基于意图的主动运维，很多例子举的都是如何全时、全流、逐包记录网络状态，以便在大数据全景现场复原的基础上实现人工智能异常分析，达到快速定位根因、主动运维的目的。但真正的主动还至少应当包括“防患未然”——在故障实际发生之前就避免这样的设计或变更发生。你不由想起了你们软件团队的变化，一种称为DevOps的持续集成、持续交付/部署（CI/CD）的理念让他们的工作从代码提交到上线交付更加流程化、自动化，很多bug在持续集成的过程中就被解决，高质量的交付带来了你们企业应用功能和体验的快速提升，当然也带来了你最近大幅增加的部署压力。既然DevOps可以提升软件开发的质量和敏捷性，你的企业部署的网络可是号称“软件定义”的SDN啊，能不能把每一次变更就像软件开发的DevOps流水线一样，从变更到Build、到测试、到部署、再到验证都是自动化执行，你不再会因为“老眼昏花”点错参数，还能保证每一个哪怕微小的配置变更都要通过严格的测试才会被真正部署，这才是真正跟上了软件DevOps的质量和节奏。不错，你已经构想出了网络的DevOps——NetDevOps。
但要实现NetDevOps必须先解决两个技术难点。首先需要架构的设置和变更都能通过代码实现，即所谓架构即代码（Infrastructure as Code，IaC）。所有软件定义的基础架构产品都号称IaC，但在NetDevOps中的IaC要求更高的质量和成熟度，如果一大堆bug不是出现在你自己写的配置代码上，而是先出现在自动化部署的执行模块上，那种执行一步就抛出异常的自动化，还不如你自己来手工配置。好在你的企业用了业内最成熟稳定的Cisco ACI，与很多IaC产品的工具适配模块都需要依靠社区开源来补足软件定义时的功能不足有所不同的是，主流的IaC工具都已与Cisco深度合作，提供了全功能、高质量的官方ACI模块，避免了开源模块的兼容性和bug问题。只要你自己写的代码没问题，通过这些主流IaC工具实现ACI的配置是非常靠谱的。
第二个难点是对配置代码的自动化测试验证。很多软件开发中的测试指标和测试代码比较容易设定，但对网络变更结果的测试则是一个比较复杂的工作，很多配置不是简单的对错，而涉及到是否最优化、是否合规等对人类最终意图的确认。这就需要一种人工智能，能够读懂人类已经探索到的最佳配置实践、经验教训、需遵守的规则条文等等，再与目标系统收集到的信息相比对，从而得出诸如“哪些还需要更优化” “与当前哪些合规策略不符”等等“明智论断”（Smart Event）。是不是非常科幻？但只要我们有能力把这些信息用机器能够读懂的形式化语言描述，就能让机器“计算”出这些Smart Event。Cisco一方面是全球最早和最大的数据中心网络提供商，拥有庞大、丰富的最佳实践知识库；另一方面Cisco很早就在芯片设计验证领域使用形式化分析和建模，有业内领先的技术储备和团队，因而能够开发出业内第一个“网络确认引擎”（Network Assurance Engine，NAE）。NAE可以根据收集的SDN管理、控制和数据平面信息给出当前网络的Smart Event，也可以把当前状态叠加上配置变更，然后分析配置前后状态得出Smart Event，甚至用户可以定制知识库以外的各类规则，最终在Smart Event中给出是否合规。
搭建NetDevOps的自动化流水线非常类似搭建DevOps流水线，你可以选择GitHub或GitLab这样的软件版本管理和项目托管平台制定和运行你的流水线，使用Ansible或Terraform等流行的IaC工具实现架构变更的代码化，Cisco NAE提供代码测试和验证，Cisco Webex或微信作为通知管理员的消息平台。NetDevOps自动化流水线如下图所示：
下面看看让你睡不安寝的那次业务迁移变更在使用NetDevOps后是什么体验。
首先你需要在NAE已经非常丰富的知识库体系上增加你项目所需要的特殊配置合规规则，比如像下图那样设置要求连接数据中心DCI的VLAN（在ACI里对应着Bridge Domain，即BD）必须打开ARP Flooding这样的规则。
然后你可以在变更之前几天从容的把变更代码写好。在Ansible循环语法的加持下，配置数十个不同参数要求的VLAN轻而易举，而且将来执行流水线时会有NAE自动检查配置，你无须担心自己的误配。
窗口到来时你只需像提交一个软件开发的新代码版本那样，用git提交你的Ansible Playbook代码。
GitLab流水线就会因为代码的提交而触发，下面是GitLab显示的流水线执行状态，显示出先通过Webex通知你新配置被提交了，然后把配置向NAE推送，以征询（Query）配置是否正确，包括是否合规、是否符合最佳实践等等。
此时你可以喝杯茶，如果测试没有问题，配置会自动在ACI的SDN控制器APIC上构建（Build），完成真实的部署，随后会自动调出你平时用来监测网络连通性的脚本做部署后的测试（Test），几口茶后你可能会在手机的Webex上收到如下信息：
这是在通知你流水线执行成功，大功告成了。你不放心的话还可以看看流水线状态，现在变成了：
流水线每个节点都打了绿勾，你可以回去睡觉了。本着认真负责的态度，你还可以看一下NAE在真实部署前所做的配置检查结果：
左边的圈内数字是变更前Smart Event的数量，右边圈是模拟了变更后Smart Event的数量，重叠部分内的数字则是二者都存在的Smart Event。我们看到变更后NAE的人工智能没有发现新的Critical、Major、Minor和Warning级别的新Smart Event，只有一些新的Info级别的信息，因此配置被检验通过，得以在后续流水线的执行中被部署。
当然你喝茶时也可能收到的是如下信息：
代表了流水线执行的情况是这样的：
流水线卡在了Query，表明配置有不合规或不符合最佳实践的项目，后续的实际部署当然也不会执行。不用着急，这表示你可以马上在现场解决问题，不用等到出现生产事故时被从被窝揪出来。而且NAE会精确的指出配置问题所在，并给出详细的解决方案。
这样的变更体验是不是改善了很多？通过NetDevOps建设，除了保住你本已可怜的睡眠和头发外，更重要的是，你主动避免了变更后那些措手不及的生产事故，跟上了已经成功完成DevOps转型的“敏捷开发”团队的节奏，让你的网络团队也成为了“敏捷运维”团队。