第一部分：用自动化重新思考网络 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 作为当前最佳实践：它由社区驱动、厂商中立、适用范围广。它凝聚了多年的集体智慧，并由一个积极活跃、不断壮大的社区持续维护。