大规模网络自动化设计 on Designing Network Automation at Scale

01 - 自动化的必要性

Mon, 10 Nov 2025 00:00:00 +0000

1. 自动化的必要性#

“自动化，还是不自动化——这是个问题。”

自从 Software-Defined Networking (SDN) 和 DevOps 兴起以来，工程师们便一直争论网络自动化究竟是必要之举、锦上添花，还是过度设计。答案是：视情况而定。超大规模企业别无选择，早在 2010 年代初便已着手布局。小型企业可能根本不需要全面自动化。大多数网络介于两者之间。文化、技能、工具成熟度、业务优先级，都决定着采用的速度。而如今，这些因素正在同步汇聚。自动化正变得不可避免。

一家区域性物流公司的网络团队花了三年时间，构建了他们所谓的自动化平台：用于 VLAN 配置、BGP 邻居配置和设备加固的 Ansible Playbook，代码托管在 Git 中，变更经过同行评审，部署从数天缩短到数分钟。从他们自己的所有衡量标准来看，自动化做得无可挑剔。

然后，公司收购了一家竞争对手，规模一夜之间翻倍。新站点、两家新供应商、与原有命名规范冲突的命名体系。第一次将配置 Playbook 运行在新环境时，它就因为边界情况而失败了。他们打了补丁，又遇到另一个失败。收购完成六周后，一位工程师花在维护自动化上的时间，已经超过了手动管理网络所需的时间。

事后复盘令人不安。工具本身没有问题，Ansible 没有任何问题。失败的东西是看不见的：没有一份统一的描述来说明网络应该是什么样子。每个 Playbook 都内嵌了自己对命名规范、IP 分配策略和供应商行为的假设。当环境发生变化时，所有假设同时崩塌。这个团队自动化的是当前的网络，而非构建一个能够适应变化的平台。

这正是每一次自动化停滞背后的核心模式：组织会走到这样一个临界点——为今天的问题而构建的自动化，变成了明天的障碍。

1.1. 完美风暴#

自动化已不再是可选项。超大规模企业面临 Artificial Intelligence (AI) 爆炸式增长带来的挑战：数十万颗 Central Processing Unit (CPU) 和 Graphics Processing Unit (GPU) 通过高速以太网互联。企业和服务提供商则在遗留基础设施、新业务、云端/本地/边缘扩张以及不断攀升的成本之间艰难周旋。

02 - 设计原则

Sun, 30 Nov 2025 00:00:00 +0000

2. 设计原则#

一支网络自动化团队花了六个月时间，构建了一个他们真正引以为傲的系统：从结构化数据模型中提取意图，通过模板引擎生成设备配置，根据策略库验证变更，并通过 NETCONF 推送配置，同时支持完整回滚。从架构角度来看，这个系统相当扎实。向领导层的演示也进展顺利。然后，他们把它交给了网络运营团队。

采用从未到来。运营人员继续使用 CLI。当被问及原因时，回答出奇地一致：“在它执行之前，我不知道它会做什么。““如果出了问题，我不知道发生了什么。““我看不懂输出内容。“自动化团队构建了一个技术上令人印象深刻、但在运营上不透明的系统。没有预演模式，没有人类可读的变更预览，没有运营人员熟悉的审计追踪。这个系统是一个黑盒，它要求信任，却没有赢得信任。六个月的工程努力就此搁置。

这种结果比大多数团队愿意承认的更为普遍。自动化的失败不仅仅因为 Bug 或糟糕的架构，更因为需要依赖它的人不信任它。我们将探索使网络自动化可靠、可扩展和安全的基础设计原则。这些不是抽象理论，而是自动化能否被采用并交付真实价值的分水岭。

这些原则中有许多也适用于其他软件项目。但网络自动化具有独特的特性，因为它支撑着关键基础设施。网络工程师几十年来依靠谨慎、精确和手动验证的模式来构建和维护这些系统。而现在，我们要求他们采用一种根本不同的模式。这需要信任。

2.1 构建信任#

在深入探讨具体原则之前，让我们先谈谈信任。它是网络自动化成功的基石。没有信任，采用几乎不可能实现。

信任为何如此重要？因为没有它，网络工程师不会采用你的自动化。他们需要相信，自动化至少能提供与其所取代的手动流程同等水平的信心（以及其他额外好处）。

更棘手的是：自动化系统通常由可能没有深厚网络经验的工程师构建。因此，自动化必须通过嵌入强大、明确的特性来弥补这一差距，使其对网络工程团队来说安全、可靠且易于定制和管理。

可信自动化的重要性受到 Damien Garros 在 Autocon3 上的演讲《构建可信网络自动化》的启发。

简而言之，我们需要四个基本特性：

Predictable：一致、确定性的结果。工程师需要在按下"执行"之前知道会发生什么，并且每次都能得到相同的行为。
Reliable：优雅地处理错误，从故障中恢复，确保操作安全完成（或回滚），即便在意外情况下和大规模场景中也如此。
Usable：让工程师能够验证、推理和控制行为的界面，无需过度复杂，并配有护栏。
Understandable：不能是黑盒。必须以能建立人类信心的方式暴露意图、步骤、结果和决策。

graph BT
 %% ===== Middle Layer =====
 subgraph L2[**特性**]
 direction LR
 B1[可预测]:::layer2
 B2[可靠]:::layer2
 B3[可用]:::layer2
 B4[可理解]:::layer2
 end

 %% ===== Top Layer =====
 subgraph L1[" "]
 direction TB
 A[信任]:::layer1
 end

 %% ===== Connections: Behavior → Outcome =====
 B1 --> A
 B2 --> A
 B3 --> A
 B4 --> A

 %% ===== Styling =====
 classDef layer1 fill:#ffcccc,stroke:#b8860b,stroke-width:2px,color:#000;
 classDef layer2 fill:#ffe6cc,stroke:#4682b4,stroke-width:1.5px,color:#000;

随着 AI/ML 技术进入网络自动化领域，可预测性（即确定性行为）变得愈发重要，因为这些技术引入了一定的随机性。

03 - 架构思维

Wed, 10 Dec 2025 00:00:00 +0000

3. 架构思维#

本章介绍本书的核心基础。它解释了为什么需要采用这种思维方式，介绍了网络自动化论坛（NAF）提出的参考框架，并展示如何在项目中加以运用。

第二部分将深入探讨这些主题。本章仅做高层概述，以便在深入细节之前建立整体认知。这一点至关重要，因为一旦我们描述各个构建模块，整体图景将帮助你将各部分串联起来。

但我坚信在了解"是什么"之前先理解"为什么"，因此让我们首先理解运用架构的原因。

3.1. 参考架构的重要性#

“只有受过教育的人才是自由的。” —— 爱比克泰德

网络自动化解决方案由多个部分组合而成，每个部分各司其职。在网络领域，我们习惯于简单或单体化的解决方案，它们试图以一体化的方式解决所有问题。这在一定程度上可能成立，但没有任何方案能独立应对所有多样化的挑战和用例。因此，如果你的用例不属于最常见的那类，就可能需要定制或扩展。

若缺乏清晰的参考架构，团队往往会面临一系列可预见的问题：

重复工作：多个团队独立构建相似工具（数据源、重复脚本、冗余监控系统），浪费资源并造成接口不一致。
集成缺口：工具之间无法干净地协作，迫使团队承担昂贵的定制集成工作。
职责不清：不清楚哪个工具应负责可观测性、编排或状态管理，导致混乱和相互推诿。
难以扩展：增加新能力或工具时需要重新思考整个系统。
知识孤岛：不同团队使用不同的心智模型，导致新人上手困难，方案难以维护。

参考架构通过提供单一清晰的心智模型来解决这些问题，明确自动化系统应如何组织。它定义了：

每个组件应做什么 -> 其职责
组件如何交互 -> 其接口和数据流
可以做出选择的地方 -> 使用哪些工具
需要保持一致的地方 -> 组件如何相互通信

参考架构对网络工程师来说并不陌生。我们都是伴随着 OSI 模型成长起来的。OSI 模型提供了一种逐层诊断和理解网络问题的方法，因为每一层都有不同的职责和关注点。网络专业人员直觉地理解，这种关注点分离使复杂系统变得可管理。

在网络自动化中，我们需要类似的东西来指导如何开发和互联协同工作的解决方案。它帮助团队做出一致的决策，在项目间复用组件，并在不每次重新发明轮子的情况下演进自动化能力。

3.2. 网络自动化架构#

因此，我们需要一个架构。但请注意本节标题中的"一个"：架构不止一种。架构只是一个参考框架，是一种组织思维、引导一致决策的方式。我参与了三项相关工作：

Network to Code 参考架构，由 NTC 架构团队（我在其中工作了四年）主导的集体努力，旨在支持跨多种用例的高效、可理解的网络自动化。
O’Reilly《网络可编程性与自动化》第二版，与 Matt Oswalt、Scott S. Lowe 和 Jason Edelman 合著，将全书内容串联成整体。
NAF 框架，由 NAF 发起的社区项目，与 Wim Henderickx、Dinesh Dutt、Claudia de Luna、Ryan Shaw 和 Damien Garros 共同主导，目标是帮助新手和有经验的从业者以结构化、可重复的方式构建自动化解决方案。

在这些迭代过程中，我专注于保持一致性并从每次演进中汲取经验。三种方法各有价值。但我建议使用 NAF Framework 作为当前最佳实践：它由社区驱动、厂商中立、适用范围广。它凝聚了多年的集体智慧，并由一个积极活跃、不断壮大的社区持续维护。

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 章解决两个问题：我们需要从网络获得什么才能使自动化可靠，以及我们如何在接触生产之前安全地验证自动化逻辑？

10 - 平台工程与 CI/CD

Mon, 01 Jan 0001 00:00:00 +0000

10. 平台工程与 CI/CD#

（本章内容即将发布。）

💬 Found something to improve? Send feedback for this chapter

11 - 规模化与可靠性

Mon, 01 Jan 0001 00:00:00 +0000

11. 规模化与可靠性#

（本章内容即将发布。）

💬 Found something to improve? Send feedback for this chapter

12 - 安全、治理与合规

Mon, 01 Jan 0001 00:00:00 +0000

12. 安全、治理与合规#

（本章内容即将发布。）

💬 Found something to improve? Send feedback for this chapter

13 - 文化转型

Sun, 19 Apr 2026 00:00:00 +0000

13. 文化转型#

会议邀请在周四发出，主题是"网络团队架构调整"。Jordi 做了十五年网络工程师，拿到了 CCIE 认证，经历了三次收购、两次 NOC 整合，以及一次严重到成为内部案例的 BGP 路由故障。他以为这只是一次人事通知。

他错了。

他的经理解释说，网络团队将被重组并入平台工程部门，团队名称改为"网络自动化平台"。工作内容也将随之演进：减少手动配置，更多精力投入构建和运营处理配置任务的自动化系统。新的岗位描述已经写好，职位名称是"网络平台工程师"。

Jordi 当天晚上回家搜索了这个职位名称，大多数结果指向云计算招聘和容器编排基础设施，他读了一个小时，大约能理解一半的内容。他没有写过 Python 脚本，也不清楚 Git 究竟是什么，更不确定自己应该感到兴奋还是恐惧。

到年底，Jordi 已经向生产环境交付了两个自动化工作流，审查了来自从未配置过路由器的软件工程师的数百行代码，并撰写了团队的第一份架构决策记录。他不是软件开发者，他是一种更难界定、也更有价值的工程师：既理解网络，又理解操作网络的系统。

本章讲述的正是这场转型。不只是 Jordi 一个人的转型，而是整个组织的转型。第 1 章至第 12 章所介绍的技术无法自行运转，它需要具备不同技能、不同角色、与网络工程传统培养模式截然不同协作方式的人来驱动。把技术做对已经很难，把组织转型做对更难，而这也是自动化项目最常失败的地方。

13.1 身份认同危机#

文化转型中最难的部分，不是学会使用 Git，而是放下多年深耕 Command Line Interface (CLI) 所积累的专业身份认同。

网络工程的职业文化建立在一种直到近期才难以获取、且无法造假的专业技能之上：理解 BGP 在故障条件下的收敛行为；在凌晨 2 点调试生成树拓扑变化（是的，生成树至今仍广泛运行在生产环境）；读懂数据包抓取，在应用团队还没来得及提交工单之前便识别出细微的 MTU 不匹配。这些都是经年累月磨练出来的硬核技能，也由此构建了强烈的职业身份认同。

自动化打破了这种专业技能的表层。当一个设计良好的自动化平台能够处理 VLAN 配置、配置加固和设备零接触入网时，那些多年来通过手工 CLI 操作精通这些任务的工程师将面临一个看似矛盾的选择：使用自动化替代自己擅长的事，还是抵制自动化来保护定义自我的技能？

这就是工匠的困境：你在某门手艺上越是精通，任何将其抽象屏蔽的工具就越像威胁而非助力。熟悉每家厂商 CLI 细节的网络工程师抵制抽象层，并非出于非理性，而是来自一个完全理性的判断：他们被要求以熟悉换陌生。

破解困境的关键在于重新定位：自动化并不取代深厚的网络知识，恰恰相反，它需要这种知识。区别在于这种知识在哪里、如何发挥作用。深刻理解 BGP 收敛机制的工程师，在自动化时代并没有变得不那么重要，反而是唯一有资格设计可靠闭环 BGP 自动化的人。技能的应用场景从执行移向了设计，从亲手运行命令变成了定义应运行哪些命令、在哪些条件下运行。

14 - 将自动化作为产品

Tue, 05 May 2026 00:00:00 +0000

14. 将自动化作为产品#

在那次改变了团队工作思维方式的谈话发生六个月前，网络平台团队已经交付了一个真正令人印象深刻的成果。两年来持续不懈的努力，打造出了一个端到端处理分支机构上线的配置平台：一个用于站点请求的自助服务界面、一个在部署前捕获错误配置的闭环验证工作流，以及一个跨三百个站点追踪服务健康状态的运营仪表盘。团队将变更窗口从二十四小时压缩到了四十分钟的自动化部署。他们为此感到骄傲，而且理所应当。

然后，业务发展团队敲定了一项零售连锁并购。一百二十家新门店需要在六个月内接入网络。基础设施负责人发来一封简短的邮件：“我们指望自动化平台来完成这件事。我们该怎么开始？”

网络平台团队的第一反应是自信的：他们可以实现自动化。工作流已经有了，模板也有了，工具链也经过了验证。

然而，当他们尝试回复这封邮件时，第二反应就没那么自信了。基础设施负责人问的并不是自动化技术上是否可行。他们问的是另一套问题：门店上线的 SLA 是什么——具体而言，提交站点信息后，门店获得网络连接的承诺时间是多少？当部署在中途失败时，升级路径是什么？是否有一个状态页面或仪表盘，可以让基础设施负责人的团队在不直接询问网络团队的情况下自行监控？平台的容量是多少——它能同时处理二十个并发部署吗，还是需要将请求分批处理？最令人不安的问题：在平台故障期间上线的门店，会被自动修复，还是需要有人逐一审计？

网络团队拥有自动化能力，但他们没有（用业务和产品语言表达的）答案。

这道鸿沟——介于"我们构建了可以运行的自动化"与"我们提供了其他团队可以依赖并据此规划的服务"之间——正是本章的主题。

这是我充满热情的话题。我在 Autocon3 上发表的演讲从设计驱动的自动化视角涵盖了这一主题，是本章的参考资料。

14.1 从能力到产品#

第 13 章描述了团队如何转变其人员、角色和工作方式，以将自动化构建为一种组织能力。这种转变是必要的，但还不够充分。

能力是团队能做到的事情。产品是其他团队（或最终是第三方实体）可以依赖的东西。这种区别与技术质量无关：零售连锁上线平台在技术上是卓越的。区别在于提供方与使用方之间的关系。能力为其创造者而存在。产品为其用户而存在。

网络团队的输出物已经发生了转变。在自动化之前，输出物是设备配置：一台路由器完成配置，一个 VLAN 扩展，一条 ACL 应用。该输出物的使用者是设备本身，成功的证据是 ping 通或应用正常运行。有了自动化，输出物发生了变化：网络团队的产品是由其他团队使用的网络服务。每一次与网络的交互——配置一个分支站点、为新应用扩展一个网段、执行安全策略、临时授予会议 VLAN 访问权限、在互联网交换节点添加互联连接——都变成了服务请求，而不是变更工单。设备配置是实现细节，服务才是制品。

这就是将网络服务作为产品 (Network Service as Product) 模式：服务是主要制品，底层网络是实现手段。这在软件工程中并不新鲜：API 对基础设施进行抽象，调用方不知道也不关心哪台服务器处理了请求。然而，对于历史上围绕设备、厂商和协议来组织工作的网络团队来说，这是一个重大转变。那些将自身身份认同建立在路由器配置技能上的工程师，现在被要求将其身份认同建立在服务交付能力上。这种重新定位与第 13 章第 13.1 节中的"工匠困境"直接相关：旧技艺的专家是最迫切需要进行这种重新定位的人，而那些完全完成这一转变的工程师将变得更有价值，而不是更少。

该产品的技术载体是第 8 章所描述的展示层模块。自助服务界面、API 接口、Webhook 集成、基于角色的访问模型——这些都是服务契约对使用方可见的地方。第 14 章将视角从技术界面拉远，聚焦于其周围的组织和业务模型。界面附带哪些承诺？当它出现故障时谁来负责？服务如何演进？谁来决定它下一步做什么？

14.2 定义产品#

当团队尝试将网络自动化转变为服务时，始终会出现两种失败模式。

第一种是过度暴露：界面暴露了实现细节，使用方必须了解网络内部机制才能使用它。一个要求输入 VLAN ID、子网掩码和 OSPF 区域编号的分支配置服务，不是一个服务——它只是一个带有 Web 表单的 CLI。使用方是零售连锁的设施协调员，他们不知道什么是 OSPF 区域，也不应该需要知道。

第二种是过度限制：界面约束如此之严，以至于只能处理网络团队预先设想的精确场景。任何偏离模板的请求都需要走例外流程。需要为临时快闪门店配置与常规零售门店不同连接需求的设施协调员，无法自助完成。他们只能提交工单，工单流转到网络团队，自动化带来的收益并未惠及那位使用方。

服务契约模式 (Service Contract Pattern) 通过明确、版本化且经过刻意界定的界面定义，解决了这两种失败模式。服务契约包含三个组成部分：

输入接口：使用方提供的内容，以业务术语而非网络术语表达（抱歉坚持这一点，但这是关键所在）。一个分支站点请求接收位置名称、实际地址、站点层级（标准、小型、快闪）和激活日期，而不接收 VLAN ID。契约在内部将业务意图转译为网络实现，而这种转译是自动化平台的责任。层级定义并非永久不变：为临时零售亭定义的快闪层级，不一定适用于连接需求不同的快闪活动场所。输入接口必须与使用团队以相同的路线图节奏进行评审，以确保层级反映实际的使用场景，而非网络团队在最初编写契约时所预想的场景。

15 - 闭环自动化

Mon, 01 Jan 0001 00:00:00 +0000

15. 闭环自动化#

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

16 - 自愈网络

Mon, 01 Jan 0001 00:00:00 +0000

16. 自愈网络#

17 - 自主网络

Mon, 01 Jan 0001 00:00:00 +0000

17. 自主网络#

关于作者

Sun, 10 May 2026 00:00:00 +0000

关于 Christian Adell#

CoreWeave 高级网络开发工程师 | 西班牙巴塞罗那

Christian Adell 的职业生涯围绕应用于网络自动化的软件开发展开。他是该领域公认的专家，在大规模网络自动化解决方案的设计与实施方面拥有丰富经验。

联系方式#

GitHub: chadell
LinkedIn: christianadell
Twitter: @chadell0

出版书籍#

Christian 是多本网络自动化权威书籍的作者和合著者：

Network Programmability and Automation, 2nd Edition

Network Automation with Nautobot

Modern Network Observability

Network Automation Cookbook, 2nd Edition

会议与社区参与#

Christian 活跃于各大网络技术会议：

法律声明

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

法律声明#

版权声明#

本网站内容，包括文字、图表和示例，均为作者的知识产权，依据知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议（CC BY-NC-ND 4.0）进行授权。

您可以自由地：

共享 — 在适当署名的前提下，以任何媒介或格式复制和传播本材料

须遵守以下条件：

署名 — 您必须注明 Christian Adell Querol 的著作权，提供许可协议链接，并说明是否进行了修改。
非商业性使用 — 您不得将本材料用于商业目的。
禁止演绎 — 您不得对本材料进行再混合、转换或基于本材料进行创作后加以传播。

重要说明

翻译需要版权持有人事先书面许可
商业使用需要另行签订许可协议
演绎作品未经明确许可不得创作

如需本许可协议范围以外的授权，请通过 chadellgmailcom 联系作者。

致谢#

本书的完成得益于众多慷慨分享时间与专业知识的人士的贡献。

审阅

（待定）

翻译

本书提供多种语言版本。所有翻译均先由 AI 辅助工具完成初稿，再由具有网络工程背景的母语人士进行审校。他们的工作确保了技术内容的准确性以及语言表达的自然流畅。

语言	审校人员
Español	Christian Adell
Русский	Artem Kovalchuk, Mikhail Garin
Català	Christian Adell
Français
中文	Yujia Gao, Lancheng
Deutsch
Português
Italiano
日本語
한국어
العربية
हिंदी
Ελληνικά

如果您希望对某个翻译进行审校或纠正，请通过 chadellgmailcom 联系作者。

术语表

Mon, 01 Jan 0001 00:00:00 +0000

内容即将上线。