第二部分：架构构建模块 on Designing Network Automation at Scale

04 - 真实数据源

Sun, 15 Feb 2026 00:00:00 +0000

4. 真实数据源#

新服务需要在本周末上线。变更内容很简单：一个新 VLAN、一个新子网、更新防火墙规则，以及边缘路由器上的一个新 BGP community。网络工程师清楚地知道该做什么。然而接下来是跨越五个系统、历时四天的协调工作：IPAM 工具用于预留子网，CMDB 用于注册服务，防火墙管理平台用于推送新策略，路由器配置系统用于 BGP community，监控平台用于添加新阈值。每个系统都有自己的界面、自己的数据模型、自己的审批流程。由于没有共享参考，工程师不得不手动携带上下文：将数值从一个系统复制到下一个系统，希望中间步骤不会出现偏差。

六个月后，服务下线。VLAN 被移除，子网被释放，但防火墙规则留了下来。没人记得它与那个服务关联。BGP community 还残留在两台边缘路由器上。监控阈值持续触发低优先级告警，NOC 学会了直接忽略。随着时间推移，网络积累了一层层孤立的配置：那些从未被完整追踪、从未被完整回滚、从未与共享意图记录相关联的变更残骸。

这就是在没有真实数据源的情况下运营网络的真实面貌。不是单一的灾难性故障，而是不一致性的缓慢累积：每次变更都需要更新多个孤立系统，却没有任何机制追踪哪些内容是相互关联的。

每个自动化系统都从一个问题开始：我究竟要做什么？ 当你部署防火墙规则、添加 IP 地址或配置 VLAN 时，你是基于某种意图表达来操作的。这个表达就是你的真实数据源（Source of Truth）：对于应该部署什么的单一、可靠版本。

我将"真实数据源"（Source of Truth）和"意图"（Intent）互换使用，它们是完全相同的概念。

没有可靠的真实数据源，网络运营就会沦为部落知识的混乱。工程师对已部署内容各执一词。电子表格与实际运行状态相矛盾。两个不同的自动化系统对同一设备做出冲突的变更。当故障发生时，你只能进行考古挖掘：“为什么这样配置？谁批准的？何时变更的？”

本章探讨如何构建一个真实数据源：无论管理几十台还是几十万台设备，它都能为所有需要数据的对象（人、自动化、其他系统）提供服务，保持数据准确可信，并处理从多个来源汇聚数据的复杂性。我们将介绍六个构建模块：建模、消费、执行、版本控制、聚合和设计驱动，它们共同为网络自动化奠定坚实基础。我还会涉及将现有网络接入该系统的实际问题，并展示现有的解决方案。

4.1. 基础概念#

真实数据源做三件事：定义你如何表达需求，意图存放在哪里，以及如何随时间保持其可信度。没有它，其他构建模块就成了没有共享参考的孤立工具；有了它，它们才能协同工作。

4.1.1. 目标#

你的真实数据源需要做六件事：

捕获一切所需内容。存储网络的完整图景：配置、资产、拓扑、服务、IP 地址、电路、设备规格、密钥、维护窗口、合规信息以及所有权归属。不仅包含今天正在运行的内容，还包括已规划的和正在退役的。当所有这些数据集中在一处而非散落在电子表格和人脑中时，你的自动化系统才真正具备做出明智决策所需的上下文。
让运营人员以业务术语思考，而非设备语法。员工应在业务层面工作（“新增一个分支机构"或"建立 MPLS 服务”），而非 Command Line Interface (CLI) 层面。在幕后，系统负责推导出实际的设备专属配置。这让人们专注于想要实现的目标，而不是底层细节。
让人员和机器轻松访问数据。系统需要 Application Programming Interface (API)（Representational State Transfer (REST)、GraphQL），以便自动化获取和修改数据；需要 Web UI 和 Command Line Interface (CLI)，以便人员浏览和编辑；所有人都需要完善的访问控制，确保只能看到应该看到的内容。系统可以同时运行数百个自动化工作流、数十名员工编辑数据、外部系统同步数据，一切保持一致且高效。

05 - 执行

Sat, 01 Nov 2025 00:00:00 +0000

5. 执行#

这个 Playbook 已经完美运行了几个月：实验室里的十台接入交换机，端到端两分钟，每次结果干净。当团队决定将其推广到全部 800 台交换机的完整清单时，没有人预料到会出问题。前 600 台设备顺利更新。然后任务变慢了，接着停滞了。RADIUS 服务器突然收到 150 个并发 SSH 认证请求，开始拒绝连接。Ansible 在 150 台设备的执行中途挂住。一名工程师强制终止了任务。

接下来的问题才是更难解决的：没有人知道哪 600 台设备已经更新，哪 150 台还没有。没有记录任何执行状态。他们重新运行 Playbook，寄希望于幂等性能够救他们，这次确实救了。但这个事件揭示了一件重要的事：执行层是为实验室设计的，而不是为网络设计的。速度、并行性、错误边界、状态追踪，这些都没有被考虑进去。自动化本身是有效的；但执行架构不是。

大多数人认为网络自动化就是：“获取相同的数据，不以人类身份连接 CLI，在网络上做些事情。” 我敢打赌大多数开始网络自动化的人都是从这里起步的。是的，这就是执行模块所做的事。但正如你在本书中所看到的，网络自动化比这第一步要宏大得多，执行只是架构中的一个组件。

执行模块直接与网络交互以进行最危险的操作（例如配置变更或重启）。所以不要跳过本章；把它做对至关重要。

在本章中，我们将介绍这个模块提供的目标和支柱，以及实现它们所需的内部能力。

5.1. 基础概念#

5.1.1. 背景#

执行定义了如何执行操作。做什么来自意图模块，何时来自编排。

在早期的网络自动化项目中，一个为给定设备和接口名弹跳接口的脚本可以是第一个胜利。这段旅程可以成长为更复杂的系统。

5.1.2. 目标#

执行系统实际上需要做什么？五件事至关重要：

获取正确的数据。 在执行任何操作之前，你需要知道执行什么（意图）、在哪里执行（哪些设备）以及如何访问它们（凭证、连接详情）。这意味着从真实数据源（更多内容见第 4 章）拉取清单和获取预期状态，有时还需要查询可观测性数据以了解当前状况。没有这种集成，你的执行引擎只是在盲目地运行命令。为了你的心理健康，避免这种情况。
在需要时启动，无论现在还是之后。 有时你需要立即执行：工程师点击"部署"并期望立即发生。其他时候，执行应该等待，在维护窗口期间部署，等待设备上线，或响应来自可观测性的事件。系统需要同时支持同步和异步触发。
随时间追踪状态。 全网操作不是即时的。你可能在数小时内向数百台设备部署。哪些设备成功了？哪些失败了？哪些还在等待？状态管理还支持幂等性（运行相同任务两次，得到相同结果）、回滚（撤销刚才做的事）和恢复（在失败后从中断处继续）。没有状态追踪，每次执行都是一次孤注一掷的赌博。
在规模下可靠执行。 适用于 5 台设备的脚本在 500 台时往往会崩溃（或降级）。你需要并行执行、错误处理、重试、速率限制和预演能力。系统应该优雅地处理部分失败，提供清晰的错误反馈，绝不让网络处于未定义状态。不同操作需要不同策略。有些快速并行，有些缓慢串行。
与任何网络设备或平台协作。 你的网络可能有 Cisco、Arista、Juniper、云 Application Programming Interface (API)、Linux 主机、防火墙、负载均衡器。每种设备说不同的协议，有不同的操作模式。你的执行层需要为所有这些提供适配器，提供统一接口，使上层自动化不必关心差异。

06 - 可观测性

Mon, 12 Jan 2026 00:00:00 +0000

6. 可观测性#

某服务提供商的核心路由器一个风扇模块在夜间悄无声息地发生了故障。没有任何告警。线卡上的热管理子系统检测到温度升高，开始对转发 ASIC 进行降频以保护硬件。一条生产中转链路的吞吐量下降了 40%。监控系统什么都没发现：它轮询的温度传感器位于机箱主控板上，而不是单块线卡上。SNMP 轮询每五分钟运行一次，报告设备状态正常。接口计数器显示吞吐量下降，但没有为这种模式配置任何阈值，因为该链路的利用率历来远低于容量上限。

三小时后，一次客户 SLA 违规触发了一张工单。值班工程师 SSH 进入路由器，在本地告警日志中发现了风扇故障，对风扇模块进行了重新上电。风扇控制器重启，几分钟内热降频解除，流量恢复。SLA 违规已记录在案，客户已通知，事件已关闭。

根本原因始终未能确认。等到有人开始调查时，路由器已经正常运行了数小时。线卡的温度数据不存在，降频事件没有记录，也无法在任何监控系统中将吞吐量下降与风扇故障关联起来。事件报告总结为：“疑似硬件问题，通过硬件重置解决。“六个月后，这件事在另一台路由器上再次发生。

失败之处不在于缺少阈值。团队拥有数以千计的阈值。失败在于覆盖不完整：监控系统从那些一直被轮询的来源采集数据，而不是从每一个可能影响设备行为的来源采集。所有三种机箱型号的线卡温度数据都可以通过 gNMI 获取。没有人配置采集路径，因为没有人为风扇故障编写过操作手册。

传统网络监控关注的是已经出故障的东西：接口是否正常？CPU 是否超过 90%？服务是否有响应？这些都有用，但都是被动的：你在等待故障发生。

可观测性不同。它关注的是为什么会出故障，或者即将出故障。不只是"那台设备宕机了”，而是"为什么宕机，它的宕机影响了什么，业务影响是什么。“在网络自动化中，可观测性成为反馈回路：你观测到某件事，系统检测到它，决定如何响应，采取行动，并验证修复是否生效。这种循环就是"闭环自动化”。

本章涵盖你所需要的一切，以了解网络中正在发生什么：收集哪些数据、如何收集、如何存储、如何告警，以及如何以真正帮助人们做出决策的方式展示出来。

我们在这里介绍两个构建块：Collector 和 Observability，因为它们紧密相连。

无论你使用传统的一体化平台（SolarWinds、LibreNMS）、云服务（Datadog、New Relic），还是用开源组件自建（Prometheus、Grafana 等），底层架构都是相同的。理解这些模式有助于你根据自己的规模和团队选择合适的方案。

07 - 编排

Fri, 20 Mar 2026 00:00:00 +0000

7. 编排#

网络团队做了一切正确的事情。他们有坚实的真实数据源、经过充分测试的各类操作 Playbook，以及执行它们的清晰操作手册。在纸面上，部署一个新的 VLAN 服务是完全自动化的。在实践中，这需要半天时间和一名特定的工程师。

那位工程师熟知这个顺序。首先验证 SoT 数据是否完整。然后运行预检 Playbook。然后审查输出，查找失败的设备，决定是否继续。然后触发部署 Playbook。然后等待。然后运行验证 Playbook。然后手动更新 ServiceNow 工单。如果任何设备在中途失败，在其他设备注意到之前先回滚它。她将所有步骤都写在一份共享文档的操作手册中，但没有其他人完全内化了这些内容。

当她请假时，部署停了下来。当一名初级工程师尝试这个顺序并搞错了顺序时，网络在六个小时内处于部分状态。自动化存在着，但协调仍然是手动的。

这就是本章要解决的问题。编排是将一系列自动化工具转变为一个整体系统的构建块。它协调其他模块，决定它们何时运行，优雅地处理故障，追踪每一个决策，并且所有这些都不需要工程师站在中间手动管理流程。

7.1. 基础概念#

7.1.1. 背景#

到目前为止，我们所介绍的每个构建块都做一件事做得很好。真实数据源保存意图。执行器应用意图。采集器检索状态。可观测性使这些状态变得有意义。每个都是专家，而专家需要一个连接器：某个决定每个专家何时应该行动、如何处理结果、以及在出错时如何恢复的组件。

这个连接器就是 Orchestrator。

在第 3 章中，我们将其置于 NAF 框架的中心，作为协调所有其他模块的构建块。第 5 章展示了执行器如何应用配置变更；第 6 章展示了可观测性如何验证结果。本章展示编排器如何排序这两者，并处理它们之间可能出错的一切。

没有编排，你运行的不是自动化。你运行的是脚本，需要有人以正确的顺序、在正确的时间调用它们，并以正确的方式解读结果。这只是名义上的自动化。

7.1.2. 目标#

编排器需要实现五个目标：

端到端协调多模块工作流。 部署不是单一操作；它是一个序列：验证 SoT 中的意图、运行预检、执行配置、验证结果、通知相关人员。编排器将整个序列串联在一起。
自动响应事件，无论是否有人工发起。 ServiceNow 审批、可观测性告警、计划的合规扫描：所有这些都应该能够在没有人工手动启动的情况下触发工作流。
弹性且可扩展的执行。 并行触及 800 台交换机的工作流必须可靠地完成。它必须能够在重启后继续。它必须在不丢失成功设备已完成工作的情况下处理部分失败。
提供防篡改的可见性。 操作员需要看到当前正在运行什么。审计员需要看到上个月运行了什么、谁触发了它、运行的是哪个版本的工作流，以及每个步骤产生了什么。这两个需求必须从同一个系统中得到满足。
将工作流定义作为生产软件来管理。 一个部署到 800 台生产交换机的工作流不能随意修改。逻辑本身需要被持久化、版本控制、测试，并以与生产环境中运行的任何代码相同的纪律升级到生产环境。

08 - 呈现

Sat, 28 Mar 2026 00:00:00 +0000

8. 呈现层#

VLAN 自动化已经运行了六周。网络团队为此感到自豪。每天早上，来自应用团队的三四个新服务请求到来，编排器在没有任何人敲键盘的情况下处理了它们。部署正常工作，交换机被配置好了，网络运行健康。

升级事件在周四到来。应用团队负责人在询问，当门户显示"已提交"时，为什么 VLAN 请求需要三到五个工作日。网络团队检查了他们的队列：零条待处理请求，所有部署成功。自动化在收到每个请求后二十分钟内就处理了。但 ServiceNow 工单仍然显示"进行中"，因为没有人编写过会更新它们的集成。

自动化完成了它的工作，但结果是不可见的。

一周后，团队部署了一个快速的自助服务门户，让应用团队可以直接提交请求并查看状态。到中午他们在一小时内收到了四十七个 VLAN 请求，全部有效，格式正确。问题是：门户没有授权模型。它接受任何拥有 URL 的人的提交。所有请求都在一个拥有平台级管理员权限的单一 API 令牌下运行。没有速率限制、没有审批门、没有谁提交了什么的审计跟踪。

自动化运行了，但访问模型没有。

这两个失败都是呈现层的失败。一个是缺少反馈循环；另一个是缺少护栏。本章填补这一空白。

8.1. 基础概念#

8.1.1. 背景#

到目前为止涵盖的每个构建块都面向内部：面向其他模块或面向理解平台的工程师。Source of Truth (SoT) 为自动化系统保存网络意图。执行器将变更应用到设备。Observability 验证结果。Orchestrator 协调它们所有。每个模块都有一个 UI、一个 API 或两者兼有，设计给构建和运营平台的人，而不是所有需要与之交互的人。

09 - 网络

Sun, 29 Mar 2026 00:00:00 +0000

9. 网络#

VLAN 自动化已经在实验室运行了三周。三台交换机，每个厂商各一台，所有工作流都能通过。团队信心满满。在第一次生产运行中，800 台园区交换机中有 23 台失败了，全部是 HPE 的，全部运行着没有人记录在案的固件版本。

Playbook 在推送 VLAN 配置后检查每台设备的错误响应。在现代 HPE 固件上，一个已存在的 VLAN 返回错误代码 duplicate-vlan。在这个旧固件版本上，同样的情况返回 vlan-exists。Playbook 被写成将 duplicate-vlan 视为幂等信号，意思是"这已经存在，没问题。“但它没有被写成能处理 vlan-exists，所以它将该响应视为失败。三分之一的 HPE 机队报告失败。回滚干净地运行了。应用团队的工单在网络团队手动审查哪些交换机实际上已配置、哪些没有配置时，又等了三个小时。

自动化没有错，是网络有自己的意见，但没有人将其记录下来。

六个月后，同一个团队有了一个镜像 B 楼的 containerlab 拓扑：24 台交换机，匹配厂商镜像，HPE 节点锁定到 Source of Truth (SoT) 中记录的生产固件版本。在对该拓扑首次测试运行 VLAN 工作流时，8 个 HPE 节点恰好以那个错误代码失败了。团队将 vlan-exists 添加到 HPE 适配器中的幂等响应列表。重新运行：全部 24 个节点通过。生产部署：800 台交换机，零失败。

区别不在于更好的代码，而在于代表现实的测试环境。

本章解决在第 2 部分中一直隐含的模块：网络本身。到目前为止构建的每个构建块都是由自动化团队设计的，按照其有文档记录的接口运行。网络是继承来的。它有各种怪癖、多样化的接口、固件不一致性以及因厂商、平台和软件代次不同而变化的能力。第 9 章解决两个问题：我们需要从网络获得什么才能使自动化可靠，以及我们如何在接触生产之前安全地验证自动化逻辑？