1.2　行业发生了变化：趋势是什么

本节分析近年来网络行业的一些趋势。分析这些趋势有助于了解为什么有些运维人员会更多地采用自动化，帮助你确定为什么所有运维人员现在都必须采用数据模型驱动的管理。

1.2.1　缩短部署时间

运维人员在进入生产环境前广泛测试路由器镜像，这显然是一个必要的程序。在不久的过去，在有效部署新的生产服务之前用三到六个月测试新的路由器软件并不罕见。这个时间包括人工配置和网络管理测试的组合。

当时路由器和交换机更加自动化已经是一个目标，但设备供应商的传统开发生命周期历来很长。以SNMP管理系统为例。在本示例中，设备缺少管理信息库（MIB）模块或MIB模块中的某些对象（有关SNMP和MIB模块的更多信息请参阅1.3.2节）。此缺失自动化部件的预期生命周期如下：向设备供应商产品管理部门报告此功能请求，与所有其他请求相竞争并“争夺”路线图中的相对位置，等待实施，验证测试镜像，一经发布即验证官方镜像，最后升级生产路由器。毋庸置疑，功能请求和新的生产服务之间隔了很长时间。

部署新的服务是运营商增加收入的唯一途径，上市时间是关键。花费数月来验证新的网元镜像和新服务已不再可行。部署新服务的速度必须不断提高。今天，运维人员希望在实际部署之前进行“冒烟测试”（初步测试，了解简单失败是否严重到会阻止该软件的发布），测试镜像、服务甚至虚拟设备上的整个存在点（PoP）。在云环境中预计新服务将在几秒内启动和运行。

自动化可以帮助减少部署时间。可编程性有助于快速验证新的功能、部署新的服务并且立即升级路由器。这要求网络设备具有一致和完整的应用编程接口（API），最终目标是使网络运维工作中所有可以自动化的工作全部自动化。据此，运营商与竞争对手相比缩短了服务部署时间，并提供了与众不同的服务。对于设备供应商来说，适配管理软件通常比等待传统的开发生命周期要快。

1.2.2　CLI不再是标准（无法自动化的功能不应存在）

初期学习和测试手动配置网络可能是令人愉快的，但是出现了无数由手动配置错误（有时称为“胖手指键入”）导致的“网络关闭”情况，所以CLI并不是生产网络中引入新功能的可扩展途径。一个典型的例子是访问列表管理：有一些（可能不是大多数）网络工程师在职业生涯中至少有一次在更新访问列表时，无意中把自己锁定在路由器配置之外。输入错误的IP地址太容易了，你现在可能在微笑，记起了过去类似的经历。

CLI是一个用于配置和监控网元的接口，专为用户设计，可以通过额外的空格或添加的逗号，甚至用子菜单满足其需求。虽然CLI不是API，但不幸的是不得不将其视为一个API，因为必须长期依赖它。然而，使用CLI进行自动化既不可靠，也不具有成本效益。

首先，许多与服务相关的配置更改会涉及一个以上的设备，以点对点L3VPN为例，它需要配置四个不同的设备，或者一个全网格L3VPN，其中可能涉及更多的设备。实际上在全网格L3VPN网络中每一项新的添加都可能需要更新所有L3VPN端点、更新访问列表、引入IP服务级别协议（SLA）类型的探针等。这些示例中仅讨论了网络设备。如今许多现代服务的覆盖范围超过了传统物理网络设备，包括虚拟机、容器、虚拟网络功能等。事实是：配置更改变得越来越复杂。

其次，聘请训练有素的网络专家（例如，CCIE）在网元上插入新命令的成本效益并不高，除非目标明显是排除故障。随着变更频率的迅速增加，我们的想法是将人力从服务配置和监控的循环中解放出来。事实上，由于网络变化频繁，在2016年MPLS + SDN + NFVVOLRD会议上进行的“规模数据驱动的运营：大型数据中心网络中的传感器、遥测和分析”谈话中，Google架构师萨姆·奥尔德林（Sam Aldrin）提到，今后不可能再与CLI打交道了。

最后，也是最重要的，虽然CLI是人性化的，但它不适合自动化。考虑以下因素：

• CLI没有标准化。虽然网络设备配置CLI是相似的，但从语法和语义的角度来看，不同厂商或特定厂商的操作系统并不一致。
• 通过CLI配置设备时存在依赖性问题。某些情况下，配置VLAN之前必须输入用于配置接口的CLI命令。如果这些步骤未按正确的顺序执行，则配置失败，或者更糟糕的是，配置仅部分完成。
• 除了上述依赖性之外，CLI只提供有限的错误报告——还不能以易于使用的脚本格式报告错误。
• CLI不产生任何结构化输出。因此，从show命令中提取信息的唯一方法是通过“屏幕抓取”（或使用正则表达式模式匹配从输出中提取数据）。最后，“show命令”经常更改以显示更多功能、更多计数器等。问题是即使对show命令进行最小的更改（例如在输出中添加空格）也可能会破坏提取特定值的Expect脚本。

你可能使用过一些基于CLI的工具。回顾上一节中部署L3VPN的示例，当时参与的NMS使用Expect[3]脚本进行设备配置和监控，会受到各种已知的限制。Expect是对Tcl脚本语言的扩展[4]，是对Telnet、Secure Shell（SSH）等协议的文本接口的自动化交互。一般情况下，你会打开到网元的终端会话，输入命令，然后分析答案。例如，当登录路由器时，下一个预期的脚本代码单词是“login”，插入登录用户名字符串；然后下一个预期单词是“password”，脚本将以密码进行响应，等等。这种语言工作正常，直到设备提供一个意外的答案。一个典型的例子是自定义提示，从“login:”更改为“Welcome, please enter your credentials:”。此时，预期“login:”的脚本收到一个意外的答案，并失败。技术支持中心（TAC）的另一个典型示例是身份验证、授权和记账（AAA）配置，它将“login:”和“password:”提示更改为“username:”和“password:”。Expect脚本必须适配新的提示。定制的Expect脚本中所有不同的用例都要依赖CLI，花费大量的时间、金钱，并导致计划外的中断。

使用CLI进行管理并非不可能，但成本高昂且困难，该行业过去三十年的发展证实了这一点。事实上，这已被Stanford Clean Slate项目[5]确定为网络发展速度不如其他IT行业的主要原因之一。Stanford Clean Slate项目是SDN运动的基础（请参阅“The Future of Networking, and the Past of Protocols”[6]，斯科特·沈埃（Scott Shenker）等）。在工具方面，有大量的库和工具与CLI交互。除了Expect之外，还存在诸如Python中的Paramiko[7]、Ansible[8]、Puppet[9]、Chef[10]等工具，但在CLI中，没有机器耗材提取能够使工作更简单、更具可扩展性。这导致花费许多时间来跟踪CLI的更改，而不是专注于自动化的目标。此外，CLI管理还可能导致意料之外的运营后果。例如，一些运维人员担心升级设备会导致自动化脚本的中断，所以推迟或不去部署必要的安全补丁。另外，这种对升级的恐惧也解释了为什么采用数据模型驱动的自动化速度很缓慢：从初始状态开始对运维人员来说是不可能的，因为运维人员必须依赖现有基于CLI的自动化脚本来处理传统设备。深入思考一下新协议规范及其在网络中的部署时间，能看到网管协议的生命周期与其他类型协议的生命周期有明显的差异。从规范到部署，路由协议可能要花费数年时间，而网管协议通常需要十年。原因很实际：你需要升级设备和controller/NMS以支持新的管理协议，还要更新基于CLI的脚本作为备份计划，同时仍在管理无法升级的旧设备。

总之，现在有些运维人员曾正确地断言，无法自动化的功能不应存在。（该断言来自Google工程师演示没有可编程性的新功能的过程。）这导致了配置API来直接监控和配置网元……以及完整的自动化过程。

1.2.3　硬件商品化和解耦

业界的另一个趋势是硬件商品化（主要基于Linux），而不是使用更特殊的专用硬件，以及从硬件中分解出的软件。

在数据中心，从一家硬件公司订购服务器并独立购买最适合你特定需求的操作系统（Windows、Linux、Unix等）是公认的做法。现在甚至可以通过虚拟化轻松支持多个操作系统。

在网络领域，设备供应商历来为自己的硬件提供自己的软件，软件运行在专用的集成电路（ASIC）上，因此客户必须购买与硬件关联的“软件包”。虽然此硬件设备针对核心、边缘、数据中心的性能进行了优化，但管理整个网络的挑战越来越大。事实上，当不同的设备类型具有不同的操作系统、不同的功能集合、不同的CLI、不同的管理和不同的许可证（有时甚至来自相同的供应商）时，验证、管理和维护整个网络功能/服务的成本就会大幅增加！

从数据中心运维开始，行业越来越倾向于将软件与硬件进行分离。现成的组件与普通芯片共同构成解决方案的硬件部分。这通常称为白盒。历史上，大规模可扩展的数据中心，也称为hyperscalers，是首批大规模自动化的数据中心（例如，采用架式交换机）。对于这种自动化，需要SDK（软件开发套件）和一组相关的API，使用相同的交换机类型、相同的厂商、相同的软件版本进行大规模自动化并不是那么困难。但是，超大规模开发者希望在此领域有进一步的发展，他们希望能够订购或开发自己的网络软件，这些软件主要来自开源项目。

最终目标是将白盒组装成统一的硬件，以Linux为操作系统，并针对不同网络功能使用特定的应用程序——可能从一个供应商购买BGP功能，从另一个供应商购买内部网关协议（IGP），从第三个供应商购买RADIUS和管理功能。未来供应商将在应用上竞争：特性、健壮性、质量、支持、升级等。

对于遵循这一趋势的运维人员，优势显而易见：

• 由于使用联网设备上的Linux，网络和服务器工程师可以使用与各自设备相同的语言。相同的工具模糊了服务器和网络管理之间的界限，并降低了支持成本（请参阅1.2.4节）。不仅“路由器”和“交换机”都在Linux上运行，Linux环境还提供了许多工具和应用程序，包括管理操作。
• 使用Linux意味着更广泛的共识：人们直接从学校开始接受更好的培训。在硬件商品化的情况下联网不再困难，因为厂商的CLI不是唯一的。换句话说，不同的设备厂商在CLI方面不再竞争。运营商不需要雇用懂Cisco或Juniper CLI的人，而转向具有Linux和脚本技能的人选。因此，高级网络工程师应该少关注厂商的具体内容，多关注更广泛的网络架构和技术基础。在厂商方面，除了关注CCIE等认证以及部分基于CLI的知识，还应该更加关注独立于CLI之外的网络编程和操作方面的内容。
• 在网络中使用相同的硬件，而不是更特殊的专用硬件，可以降低网络的复杂性（缺点是硬件bug会影响到所有平台）。特定的软件和应用在相同的通用硬件上可能会对某些设备进行优化。事实上，网络越来越复杂，运营成本也随之增加，因此任何简化都是值得欢迎的。专门进行分类意味着供应商需要一个更加开放和模块化的平台。请注意，分类并不会阻止传统厂商竞争，使用专有ASIC及其软件来获得优势。例如，思科公司正在加入数据中心网络的软硬件解耦的趋势中。它表示，现在它允许数据中心客户在第三方交换机上运行其Nexus operating system（NX-OS），并在其Nexus switches上使用任何网络操作系统，满足了超大规模厂商和大型服务提供商的需求。网络管理员可以在通用硬件或最佳硬件上选择最佳软件（用于一些额外的性能优化）。这种方式表明解耦可能是传统设备供应商在通用平台上提供其软件的机会。
• 软件和硬件解耦意味着拥有两个独立生命周期的管理优势，一个用于软件，另一个用于硬件。在管理两个生命周期时，复杂性（传统上由供应商组装软件）略有增加，而软硬解耦提供了选择最佳同类产品的灵活性。在某些情况下这种灵活性超过了复杂性。软件升级就像升级Linux软件包一样简单。将一个供应商的软件替换为另一个供应商的软件甚至是同一供应商的不同操作系统培训也很容易，因为软件只是另一个软件包而已。以思科为例，从IOS-XE系列迁移到IOS-XR系列不需要任何硬件更改，最终目的是使硬件和软件能够各自创新发展。
• 网络和服务器工程师可以更专注于面向业务的任务，而不仅仅是网络运营和维护。网络越来越成为业务的推动者，而业务和网络之间的链接正是软件。快速调整软件以满足业务需求成为关键：例如添加用于性能探测的应用、以虚拟负载平衡器补充网络、为特定应用程序在IGP之上注入特定路由……你可以为其命名。随着自动化（在这种情况下来自解耦，而通常不仅仅来自解耦）所节约的时间，工程师将成为推动网络创新以满足业务需求的关键推动力。

总之，硬件商品化和软硬解耦允许并需要更多自动化。本书其他部分讨论的基于YANG的程序管理是管理这些新型网络的一种方法。

1.2.4　DevOps时代

网络工程师需要适应：在网络行业中唯一不变的是变化。那么，如何适应？换句话说，一个人如何持续跟上时代的发展？有趣的是，现在几乎所有网络工程师的工作描述中都需要某种脚本技能。反映在这一点上，你应该学习利用脚本作为自动化管理网络任务的方式，而不仅仅会使用shell脚本执行任务。如果询问需要学习的编程语言，答案将始终是“从Python开始”。Python是一种现代编程语言，易于读写，功能强大，可用作日常分析任务、性能管理和方便配置管理的工具。Python提供了许多SDK，有大量可用的库。可以快速创建有用的脚本。与Python命令行交互会增加学习Python的乐趣。例如，一个由Coursera[12]提供的课程“An Introduction to Interactive Programming in Python”[11]提供了所需的基本内容，包括每周视频、测验和小型项目，学习这些课程可以掌握Python的原理。通过少数专业人员讲授一些有趣的知识，世界各地的社区学习并分享其知识，你可以很容易得到一个像YouTube视频[13][Asteroids game in Python (coursera.org)]这样的最终项目。

将来所有网络工程师都必须成为全职程序员吗？不会。自动化、SDN、云、虚拟化、一切即服务的趋势等并不意味着网络工程师将消失。当（年轻的）应用程序设计者抱怨对API的调用“get-me-a-new-service-over-the-network (bandwidth = infinite, packetloss = 0, one-way-delay = 0, jitter = 0,cost = 0)”无法如期正常工作时，仍然需要网络工程师进行故障排除。最好的（即，最高效的）网络工程师将是具有脚本能力的人，无论是配置还是服务保证，他们都可以编写与网络相关的自动化任务，并可以及时修改其脚本。你必须自动执行而不是重复手动任务！

那么，什么是DevOps？是开发与运维的结合。DevOps是一种软件工程实践，旨在统一软件开发与运维。

为什么？因为软件工程师不必了解网络，而网络工程师也不必了解软件，将力量结合起来发挥出两者的优势才有意义。

DevOps提倡在软件构建的所有步骤中实现自动化和监控，从集成、测试、发布到部署和基础设施管理。换个说法，DevOps是开发、运营和质量保障的交集，因为它强调应用（或服务）、开发和IT运维的相互依赖性，如图1-1所示。

新的DevOps思想是将开发和运维相结合，以提供更快的服务部署和迭代。作为一个实际例子，这意味着网络支持团队和应用/服务器支持团队这两个历史上不同的小组，现在作为一个团队工作，从而避免了“这是网络问题”与“这是服务器问题”的乒乓球游戏。网络nirvana能够像管理服务器一样管理网元。

1.2.5　软件定义网络

多年来，新的模式一直是软件定义网络（SDN）。虽然SDN不是一个新术语，它却是一个流行语——对于不同的人意味着不同的事物。

最初的SDN讨论引入了控制面和数据面分离的概念，重点是OpenFlow（现在是Open Networking Foundation[15]的一部分）作为配置数据平面的开放标准——转发信息库（FIB）或媒体访问控制（MAC）表。

以下是一些独立于内部网关协议（IGP）来配置控制平面的用例，例如OSPF或中间系统到中间系统（IS-IS）：

• 研究可编程数据平面：流量工程、服务插入、隧道等
• 在通用硬件（商用服务器）上运行控制软件的能力
• 集中式控制器负责整个网络的所有转发

通常OpenFlow控制器通过API、CLI或GUI在OpenFlow交换机中配置数据平面，如图1-2所示。此OpenFlow控制器管理控制平面，它需要完整的拓扑视图和端点/流。

多年来SDN的概念不断演变。OpenFlow作为一种基本的数据包转发模式，实际上是一种实现更多更轻松的网络可编程性的推动因素。例如，Open vSwitch数据库管理协议（OVSDB, RFC 7047）用于在虚拟化服务器中配置虚拟交换机。OpenDaylight[16]项目是一个开源控制器项目，它能出色地将多个配置协议关联的接口添加到OpenFlow：

• PCEP，即路径计算单元通信协议（RFC 5440），是路径计算客户端（PCC）和路径计算单元（PCE）之间或两个PCE之间的通信协议，包括路径计算请求和路径计算回复以及与在多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程中使用PCE有关的特定状态的通知。
• Forces代表转发和控制单元分离（RFC 5810），目的是确定框架和相关协议，使控制面和转发面之间的信息交换标准化。
• BGP链路状态分布（RFC 7752），即BGP-LS是从网络收集链路状态和流量工程信息，并使用BGP路由协议与外部组件共享的机制。
• NETCONF/YANG提供了一种简单、标准化的方法，可实现任何设备或服务的可编程接口（本书会详细介绍）。

因此术语SDN发展出各种含义：云中的网络虚拟化、面向服务提供商用户的动态业务链、动态流量工程、动态网络配置、网络功能虚拟化、开放和可编程接口等。可以肯定的是，SDN远不止OpenFlow，只需拆分控制面和数据面即可。

比较务实的SDN定义来自大卫·沃德（David Ward）在肯·格雷（Ken Gray）和汤姆·纳多（Tom Nadeau）撰写的SDN: Software Defined Networks一书中的前言[17]：“SDN在功能上使运维人员可以通过编程方式访问网络，从而实现自动化管理和任务编排；可以在跨多个路由器、交换机和服务器上配置应用策略；以及将执行这些操作的应用程序与网络设备的操作系统解耦。”

有人会说这实际上是DevOps的定义，而不是SDN的定义。底线是SDN作为控制平面分离模式实现了更高的网络可编程性需求，提升了速度和灵活性，将人工配置时间转变为软件时间。

最后，SDN作为控制平面分离模式（配置路由信息库[RIB]或FIB）和DevOps（有人称之为SDN）是互补的：它们使用相同的概念和工具。举一个实际的例子，网络工程师可能正在使用基于NETCONF和YANG的工具配置用于分布式的转发IGP，并在IGP的顶部注入特定的策略。

1.2.6　网络功能虚拟化

该行业的另一个趋势是网络功能虚拟化（NFV），这再次解释了为什么现在一些运维人员更多采用自动化技术。NFV在服务部署方面为客户提供了更大的灵活性，大大降低了与新服务相关的复杂性和上市时间。例如，现在通过点击按钮就能添加虚拟功能（例如防火墙、虚拟入侵检测系统、深度数据包检测等），这归功于生命周期服务编排器。以前，这些功能集成到专用硬件设备中，增加了总体成本，不仅包括安装、连接和物理空间的成本，还包括持续维护的成本。

正如白皮书Trends in NFV Management中提到的那样[18]，网络运营商有合理的业务理由支持NFV。当网元是虚拟化实例而不是物理设备时，可以更快地进行调配和更改。它们随需动态弹性伸缩，允许运维人员根据需要在几分钟甚至几秒钟内为客户增加（或减少）网络资源，而不是等待数周或数月来部署新的硬件。它们是自动化的，由机器逻辑驱动，而不是手动处理，从而降低运营成本和复杂性，并降低人为错误的风险。它们还从根本上缩短了从收到订单到服务全面正常运作创收所需的时间。NFV还允许运维人员更自由地从各种供应商中选择最佳的VNF，并且因为更好的定价或功能，运维人员可以轻松地从一个VNF迁移到另一个VNF。运维人员可以从一个供应商获取一个VNF（例如防火墙），并将其替换为另一个供应商提供的类似VNF，相比替换物理设备更快、更轻松。

当前供应商之间有关VNF管理的讨论主要集中在启动上——使VNF在其初始配置状态下启动和运行、放置在正确的位置、连接到正确的物理和虚拟网络、并确保其拥有适当的资源和许可证。所有这些“Day 1”和“Day 0”设置都很重要，运维人员应该努力使其更简单。但是，一旦VNF启动并运行起来，在一些讨论中我们发现，他们往往对“Day 1”及以后发生的事情不负责任。网络运维人员如何将虚拟化网元与业务编排器和其他运营支持系统（OSS）以及业务支持系统（BSS）相联系，以持续更改配置？他们如何在动态大规模网络中实现多供应商VNF的日常管理自动化？

有太多运维人员仍然把虚拟化当作现有的操作系统来做，在虚拟机（VM）中启动它们，却提供使用物理设备时相同的接口，仅此而已。对所有设备执行配置管理已经很长时间了，工作得很好，因此没有理由做新的尝试。但是，虚拟化环境带来了一系列新的挑战，在传统物理设备上所使用的久经考验的机制根本无法解决这些挑战。

最终，随着我们开始将虚拟化功能视为要编程的软件，是时候放弃网络应用中“配置”的概念了。本书讨论了如何使用NETCONF和YANG，将更标准化的API引入网元中，并充分解锁NFV自动化的价值。

1.2.7　弹性云：按需付费

长期以来新公司依靠网络来开展新业务，在客户首次产生订单之前就必须购买一系列网络设备并运维它。资金支出（CapEx）是用于购买、维护和改善固定资产的金钱，而运营支出（OpEx）是用于经营产品或业务的持续成本。对于新公司来说，资金支出是网络本身的成本，而运营支出是IT员工操作网络的薪水（或咨询费用）。CapEx不仅需要年轻的公司投入一些不可忽略的资金，满足第一个客户的订单之前，必须先订购、安装和运营网络。此外，正确规划网络规模可能对新公司而言也是一种挑战：规模太小会影响未来的服务和公司发展，规模太大将会浪费资金。

如今，新企业并不热衷于第1天便在网络方面投入如此巨大的资金/运营支出。相反，随着业务的增长，线性成本是理想的解决方案：客户越多，收入就越多，基础设施投资就越多。这就是弹性概念，也被称为“按需付费”，理想的资金支出线性投资以接近零的金额开始。弹性概念涉及网络时，指的是基于负载的网络动态适应性。借助于虚拟化，云以弹性方式提供某些计算、存储和网络功能，因此称为“弹性云”。

以下是一个典型的例子：yangcatalog.org[19]网站（一个围绕YANG工具和YANG模型的元数据存储库，目的是推动作者之间的合作，并被消费者所采用）通过拥有一台虚拟计算机来运行网络服务：Amazon Web Service (AWS) EC2。以下内容来自亚马逊的文档。“亚马逊弹性计算云（简称Amazon EC2）是一种在云中提供安全、可调整的计算能力的网络服务。它旨在让开发人员更容易进行Web规模的云计算。Amazon EC2将获取和启动新服务器实例所需的时间缩短至几分钟，使你可以根据计算需求的变化快速弹性变化容量，包括增加和减少容量。亚马逊EC2改善了计算的经济性，允许你只为实际使用的容量付费。”

起初，一个免费的AWS实例对yangcatalog.org[19]网站来说，确实是个不错的选择。然而，随着更多的服务被添加到网站中，需要更多的容量（内存、CPU和存储）。基于前期网站的成功，他们制定了投资计划，并在第二期购买“活的”（active）服务器（即“弹性云”）。虽然此示例提到了AWS，但你应该注意到行业中存在多个类似的解决方案，例如Microsoft Azure、Google云平台和OVH云等。

与YANG Catalog相比，更复杂的示例包括VNF，例如虚拟防火墙、虚拟入侵检测系统、负载均衡器、WAN加速器等（如上一节所述），但弹性云的原理仍然存在。

在云管理方面，你需要区分两种不同类型：一边是系统级管理，另一边是容器或虚拟机内部的服务管理或NFV管理。

系统级管理包括以下任务：

• 通过安装Linux软件包来准备环境
• 升级操作系统和打补丁
• 设置容器或虚拟机
• 弹性垂直扩容（Scaling up），意味着升级基础设施（计算、存储和网络）以满足更多/更好的服务需求
• 弹性水平扩容（Scaling out），意味着复制基础设施

系统级管理（更多是由操作驱动的工作流）可能受益于业务流程建模语言（BPML），例如云应用拓扑编排规范（TOSCA[20]），这是一种基于模板的机制，用于描述基于云服务的拓扑、组件及其关系。

容器或虚拟机内的服务管理包括以下任务：

• 启动和停止服务。
• 更重要的是维持或更新服务。例如，更新访问列表条目时不能停止虚拟防火墙。

这种管理更多受益于类似模式的语言，如YANG，它提供API和基于语义的操作。这是模型驱动的管理方式，我们将在下一节探讨。

1.2.8　数据模型驱动的管理

脚本相对容易创建，在某种程度上写起来也很有趣。难的是可维护性。尝试在创建一年后查看一个你的故障排除脚本，除非脚本包含众所周知的约定（例如，PEP8[21]是Python代码的样式指南）、干净的结构和一些文档，否则它很可能看起来不熟悉。改进这个脚本需要相当长的时间，而且最可能的是著名的“如果它没有坏掉，不要修复它”的原则将占上风。

良好的脚本基于良好的API（能够创建访问操作系统、应用程序或其他服务的功能或数据的应用程序功能和程序集），API从根本上提供以下优势：

• 摘要：可编程API应该抽象化底层实现的复杂性。DevOps工程师不需要知道不必要的详细信息，例如网元的特定配置顺序，或者在发生故障时需要采取的具体步骤。如果上述信息对人类来说不直观，那么配置引擎的命令排序就会更加复杂。配置的功能应该更像是填写高级检查清单（这些是你需要的设置；现在系统可以确定如何正确地分组和排序）。
• 数据规格：API的关键工作（无论是软件API还是网络API）是为数据提供规格。首先，它回答了数据是什么的问题——整数、字符串或其他类型的值？接下来，它指定了该数据的组织方式。在传统编程中这被称为数据结构，在网络可编程性和数据库的世界中更常见的术语是架构，也称为数据模型。由于网络基本上被视为（分布式）数据库，有时会使用术语（数据库）模式。
• 访问数据的方法：最后，API为如何读取和操作设备数据提供了标准化框架。

数据模型驱动的管理基于在模型中指定管理对象的语义、语法、结构和约束的思想。脚本使用工具从这些模型中调用API。优点是只要以向后兼容的方式更新模型，先前的API集仍然有效。

数据模型驱动管理的一个重要优点是将模型与协议和编码分离，这意味着添加协议和编码更容易。数据模型驱动的管理最初是在NETCONF和XML上构建的，但是其他协议/编码此后逐渐崭露头角：具有JavaScript对象符号（JSON）的RESTCONF、具有protobuf的gRPC网络管理接口（gNMI）等。请注意，XML和JSON是用于存储嵌入式和Web应用的结构化数据文本格式。第2章涵盖不同的协议和编码。

正如你将在第7章中看到的，一旦明确指定模型且完整的工具链到位，自动化流程即被简化，OPEX就会被降低。虽然数据模型驱动的管理并不是新概念，但它是当今网络中一种可行的管理模式。因此，数据模型驱动的管理在本书中被认为是一个重要的趋势，本书致力于全面推进这个行业的转型。

将API应用于复杂环境时，关键是供应商以基于标准的方式实施API。不同设备和供应商之间定义和访问数据应该有一种通用方法，运维人员不必为网络中的每个不同设备和功能学习单独的专有接口。

图1-3说明了如何从静态CLI脚本管理转变为模型驱动的方法。一个美洲的服务提供商正将其业务从一组较旧的设备迁移到一组较新的设备。请注意，转换最初相当缓慢，按照最初的节奏需要一些时间来完成。然后，2016年9月推出了数据模型驱动的自动化工具，在本例中是思科产品，称为网络服务编排器（NSO），从根本上改变了网络的转换方式。

1.2.9　数据模型驱动的遥测

遥测是当今网络行业的一大热门话题。就像任何流行语一样，遥测对不同的人意味着不同的东西——与几年前的SDN一模一样。在与不同背景的人讨论时，遥测意味着：

• 自动测量与测量数据传输的科学技术。
• 将任何监控信息推送到收集器的机制（在此意义上，NetFlow是一种遥测机制）。因为它是关于定期传输数据的，也被称为“流式遥测”。
• 数据模型驱动的信息推送，流式传输YANG对象。
• 基于硬件的遥测，直接从ASIC推送与数据包相关的信息。
• 设备级遥测，例如推送有关硬件和软件清单、配置、启用/许可功能等信息，目的是自动化诊断、了解整体使用情况并提供客户群管理。

讨论中有必要论证一下为什么数据模型驱动的遥测是需要自动化的遥测中最重要的类型。首先，为什么遥测是必要的？你已经听过各种各样的理由：因为SNMP很无聊，因为SNMP很慢，因为SNMP在轮询时间上不准确——你可以这样说它。你甚至可能听过“因为SNMP不可靠”。好吧，SNMPv3提供了安全认证和隐私保护！总之，有以下几点更重要的原因决定了要关注数据模型驱动的遥测。

• SNMP不适用于配置，尽管它适用于监控（请参阅RFC 3535了解原因）。
• 基于YANG数据模型的网络配置具有NETCONF/XML，RESTCONF/JSON和gNMI/protobuf等协议/编码。
• 知道已应用配置并不意味着该服务正在运行；必须首先监控业务运营数据。
• 通常用于网络监视的MIB模块与用于配置的YANG模块之间没有太多相关性，除了一些索引，例如“The Interfaces Group MIB”（RFC 2863）中的ifIndex或“用于接口管理的YANG数据模型”中的接口密钥名（RFC 7223，已被RFC 8343淘汰）。
• 任何基于意图的机制都需要一个质量保障闭环，这只不过是遥测机制，正如下一节所解释的那样。
• 由于配置是“YANG数据模型驱动”，必须进行遥测。

数据模型驱动的遥测唯一的例外可能是基于硬件的遥测：直接从ASIC码（用于流量的子集，线路速率）中推送大量遥测，这可能不会为与YANG相关的编码留出空间，也不会影响遥测输出率。但是仍然可以用支持大多数编码类型的YANG数据模型来描述导出的数据。

运维工程师需要将网络作为一个整体来管理，与用例或管理协议无关。问题是：不同的协议会带来不同的数据模型以及不同的信息建模方式。在这种情况下，网络管理部门必须进行艰难又耗时的数据模型映射工作：一个来自配置，另一个来自监控。在CLI、MIB模块、YANG模型、IPFIX信息元素、syslog纯文本、TACACS+、RADIUS等方面，网络管理是一项艰巨的任务。因此，不简化这个数据模型映射问题的协议设计是令人难以接受的。理想情况下，网络应提供通过不同协议传送数据，这些协议使用相同的概念、结构和名称，以便将数据合并到一个一致的视图中。换句话说，需要一个单一的数据模型。

1.2.10　基于意图的网络

随着边缘、核心和数据中心网络功能的融合，以及云网络、计算和存储的组合，服务变得越来越复杂。如今，随着复杂性的增加以及变更频率的增加，重要的是要让人们脱离现状专注于自动化。数据模型驱动的管理简化了自动化，指定遥测必须由数据模型驱动。现在，网络表现是否符合预期？新服务是否可以运行？是否遵守SLA？你可以检查网络设备，虚拟机或容器是否可访问，并检查服务或VNF的配置是否正确。但是，验证单个组件的配置和可访问性并不意味着服务处在最佳运行状态或能够满足SLA。

近来服务失败的成本显著上升。想象一下一个小时的停机时间对Facebook服务的收入影响，它的商业模式完全依赖于广告。想象一下一个小时的停机时间对AWS的收入影响，AWS的商业模式依赖于Web服务的利用率。

这就是基于意图的网络概念开始发挥作用的地方，网络不断地学习和调整。过去通常通过专注于详细描述必要的网络配置步骤，并以规定性的模式进行管理。与规定性的方法相反，基于意图的方法侧重于识别更高级别的业务策略和对网络预期。换句话说，规定性的方法侧重于“如何”（how），而基于意图的方法则侧重于“是什么”（what）。例如，配置L3VPN服务的说明性方法涉及以下一系列任务，说明“如何”是什么。必须在接口“eth0”下的提供商边缘路由器1上配置名为“customer1”的VRF，指向客户边缘路由器上的router1的默认网关，供应商边缘路由器router1和router2之间的MPLS-VPN连接，等等。

相反，基于意图的方法侧重于网络的需求（例如，为客户提供伦敦和巴黎站点之间的VPN服务）。

基于意图的网络创造的最大价值是基于反馈循环机制的持续学习、调整和优化，如下列步骤所示：

步骤1　将业务意图（是什么）分解为网络配置（如何）。这就是魔术发生的地方。对于诸如“客户C在伦敦和巴黎站点之间的VPN服务”之类的单个任务，你需要了解巴黎和伦敦的相应设备、运营商拓扑结构的映射、客户设备的当前配置、运营商核心网络配置、拓扑类型（例如hub和星形或完全网状）、所需的服务质量（QoS）、IP流量（IPv4和/或IPv6）类型、客户和运营商之间的IGP配置等。基于YANG数据模型的规范检查L3VPN服务交付的所有可能的参数（RFC 8299）。

步骤2　自动化。一旦确定了是什么，这部分便很容易。基于数据模型驱动的管理和一套良好的YANG模型，控制器或编排器将YANG服务模型（RFC 8299）转换为一系列网络设备配置。受益于NETCONF和两阶段提交（稍后将详细介绍），你现在可以确定所有设备都已正确配置。

步骤3　使用数据模型驱动的遥测进行监控，可实时查看网络状态。任何故障、配置更改、甚至行为的变化都直接报告给控制器和编排器（请参阅上一节）。

步骤4　数据分析可以关联和分析新网络状态的影响，以实现服务保障的目的，有时甚至在降级发生之前就可以隔离问题根源。从那里几乎可以实时地推断出下一个网络优化点，然后再返回到步骤1以展开新的优化。

这个不断反馈的环路（由四个步骤组成）是不断学习和适应网络的基础。它支持由网络故障（或更糟糕的客户致电）触发排除故障的被动反应式网络管理，转变为专注于SLA的持续监视。预测分析和人工智能的结合以及持续学习和适应是主要推动力。从这开始，下一个合乎逻辑的步骤就会是：网络自愈。

即使本书不包括“意图”本身，它也包括步骤2和3，以实现基于意图的网络。

1.2.11　软件正在吞噬世界

正如马克·安德森（Marc Andreessen）在2011年华尔街日报的一篇文章Why Software Is Eating The World[23]中所预测的：“软件编程工具和基于互联网的服务，在许多行业让新的全球软件驱动型初创企业更容易开启他们的事业，因为无须投资新的基础设施和培训新员工。”

这是业内的一个趋势，消费者可以获得所有可能的机会：在线银行、在线预订酒店和航班、虚拟大堂助理、通过应用程序预订出租车、从PC拨打电话、在平板电脑上看电视或看书、在移动电话上收听音乐以及连接汽车。虽然为终端用户提供了更大的灵活性，但服务提供商希望通过使用软件来减少运营支出，从而减少人为交互，降低成本。

回到网络世界，你可以立即注册域名、创建多个电子邮件地址以及托管一个网站。只要单击几下，几乎在瞬间就可以启用IPv6、向网站添加数据库、启用防火墙保护以及创建SSL证书。按需供应的云计算平台提供了存储资源、计算资源和一些基本的网络资源，可以添加虚拟网络，包括防火墙、虚拟入侵检测系统或计费等虚拟网络功能。

重点是所有这些新服务几乎都即时可得，这归功于软件。软件的后台是由自动化引擎和定制化数据分析功能组成。