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) 通过高速以太网互联。企业和服务提供商则在遗留基础设施、新业务、云端/本地/边缘扩张以及不断攀升的成本之间艰难周旋。

技术领域的其他方向早已转向 API 优先、自助服务模式。开发者对网络也有同样的期望。机器学习工作负载需要结构化数据，安全与合规需要自动化、可审计的流程。

问题已经不再是"我们应该自动化吗？"，而是"我们为什么还没有这样做？"

尽管收益显而易见，多重障碍仍在减缓自动化的普及，其中许多至今依然存在：

• 缺乏意图模型：网络长期以来以设备配置来描述，而非"网络实际上应该如何运行？"。缺少清晰的意图数据，自动化就会脆弱且以设备为中心。
• 设计混乱且不一致：自动化需要可预期性。充满例外、临时变通和特殊处理的网络根本无法自动化。整洁、标准化的设计才是正道。
• 多供应商扩散：供应商、平台和服务的混杂意味着持续不断的集成难题。
• 技能不匹配：很少有工程师同时具备网络和软件开发能力，这一差距使得自动化难以设计好。
• 对变更的恐惧：网络至关重要，保守的变更管理让自动化的投入难以获得认可。
• 缺乏安全的测试环境：大多数团队没有与生产环境匹配的完整实验室，安全测试自动化几乎是奢望。

这些障碍并非相互独立，而是相互强化：缺乏意图模型导致自动化脆弱；脆弱的自动化放大了对变更的恐惧；对变更的恐惧阻碍了构建技能和测试环境所需的投入，而这些正是降低脆弱性的关键。

flowchart LR
    subgraph Technical["技术层面"]
        A[缺乏意图模型]
        B[设计混乱]
        C[多供应商扩散]
        D[缺乏测试环境]
    end
    subgraph Organizational["组织层面"]
        E[技能不匹配]
    end
    A --> F[变更恐惧]
    B --> F
    C --> F
    D --> F
    E --> F
    F -->|限制投入| E
    F -->|阻碍进展| A

    style F fill:#ffcccc,stroke:#cc0000,stroke-width:2px

好消息是：到 2025 年，这些障碍大多已在消融。企业和供应商都在向前迈进。Chris Grundemann（Network Automation Forum）发布的网络自动化现状调查显示，这一转变正在发生。尽管如此，并不存在万能公式。理解这种思维方式，才是第一步。

1.2. 如何推进网络自动化#

本书涵盖成功实施网络自动化所需的基础架构概念。不要追逐单一工具：没有银弹。成功来自三个支柱的结合：人员、流程和技术（按此顺序）。

1.2.1. 成功的三个支柱#

如同马斯洛的需求层次，需要打好底层基础，才能向上构建。每个支柱都支撑着上一层。

flowchart BT
    A[人员] --> B[流程]
    B --> C[技术]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc

• 人员：自动化的成败取决于设计、构建和运营它的人。理解他们的需求，通过培训和协作赋能他们。
• 流程：组织对齐至关重要。将自动化成果与可量化的价值挂钩：降低成本、加快交付、提升可靠性。
• 技术：工具已经存在。挑战在于选择合适的工具，并将其整合到合理的架构中。

平衡好这三者，自动化就能成为组织能力，而非单纯的技术项目。变化是迭代式的，进步一步一个脚印。你会反复面对经典的自建与采购难题，本书将全程探讨这一问题。

1.3. 现实情况是什么样的#

每个组织都走着自己的路。大多数从小脚本开始，然后扩展到配置管理、合规检查和故障排查。

1.3.1. 理解自动化成熟度谱系#

自动化成熟度从手动运营演进至自治网络：

graph LR
    A[手动操作] --> B[脚本任务]
    B --> C[工作流自动化]
    C --> D[基于意图的系统]
    D --> E[自治网络]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc
    style D fill:#ccffcc
    style E fill:#ccccff

手动操作：每一个变更都是人工通过 Command Line Interface (CLI) 执行的决策。对单个工程师在熟悉的设备上来说很快，但在任何规模下都不可靠。网络的一致性取决于最后一个操作它的人，除登录记录外没有任何审计痕迹。

脚本任务：重复性工作被封装进脚本。脚本从电子表格生成配置，循环将同一变更应用到五十台设备。在边界情况下十分脆弱：设备状态、供应商行为或命名规范的每一处差异都需要新脚本或新例外处理。这是大多数团队的起点，也是许多团队停留的阶段。

工作流自动化：脚本被结构化的 Playbook 和流水线取代。变更可重现、可审计，并可通过自助服务界面触发。自动化仍在描述如何配置设备，而非网络应该是什么样子。状态对账依然是手动活动。处于这一阶段的团队通常认为自动化运行良好，直到环境发生变化。

基于意图的系统：网络以意图（你想要什么）而非配置（如何实现）来描述。真相之源将意图保存为结构化数据，自动化引擎将意图转化为设备状态并验证结果。当环境变化时，意图保持稳定，执行层自适应。本书的大部分内容都围绕如何构建好这一层展开：第二部分中的真相之源、执行、可观测性、编排和呈现模块，正是基于意图系统的各个组成部分。

自治网络：系统观察自身状态，检测与意图的偏差，并在无需人工干预的情况下闭合循环。这要求基于意图的层次可靠、被充分理解，并以严格的纪律运营。第四部分和第五部分探索实现这一目标的模式：闭环自动化、自愈网络，以及使自治运营值得信赖的组织条件。

本书第一至三部分构建基于意图系统的架构基础。第四和第五部分探讨迈向自治运营所需的条件。当今大多数组织介于脚本任务和工作流自动化之间。目标不是跳跃前进，而是在坚实基础上逐层构建，使下一层不需要重建已有的成果。

在规模扩展时，真正改变的不是目标，而是架构。为 50 台设备设计的自动化，在 500 台时会暴露其缺陷。嵌入了隐式命名假设的 Playbook，当网络规模超出单个团队的工作认知范围时就会失败。第三部分将深入分析当自动化平台从数十台设备扩展到数千台时会出现哪些问题，以及如何从一开始就为此进行设计。

网络自动化有一个隐藏的好处：它会促使你尽可能地简化网络架构，以便于自动化。手动管理时可以容忍的复杂性，在自动化需要处理每一个例外情况时，就变成了实实在在的障碍。

全面自动化是一个长期目标。自动化不会取代人，而是放大专业能力，让工程师专注于设计和解决问题。真正的收益在于一致性、可靠性和速度。自动化还能实现手动操作在规模化下根本无法完成的事情：实时验证、即时合规检查、跨数百个站点的协调变更。

以下是不同环境中自动化的一些实例：

超大规模企业

• 获取设计并将其展开为网络意图所需的全部数据：机架、设备、线缆、Internet Protocol (IP) 地址、Overlay、网络。用这些数据生成 Bill of Materials (BOM)，并在设备接入时通过 Zero Touch Provisioning (ZTP) 下发引导配置。
• 将可观测性数据（指标、日志、流量）关联为富含上下文的实时事件，触发工作流缓解用户问题：在保持容量在 SLA 范围内的同时排空连接。

服务提供商

• 对穿越各 Transit 提供商的互联网链路进行全网状测试，将丢包和延迟控制在容忍范围内。检测问题，从可疑链路排出流量，修复后重新引入。
• 监听来自提供商的电路维护通知（邮件、Webhook），转化为结构化数据，静默告警或主动响应以降低影响。

企业

• 自助服务门户，用户定义安全策略，按执行策略转化为防火墙规则，并支持规则生命周期管理，清理未使用的规则。
• 设备更新和生命周期管理：检测 End of Life (EOL) 设备，标记软件漏洞，自动升级，协助平台迁移。

关键在于：识别哪些流程最耗时、最容易出错或最为关键，理解它们如何支撑业务，然后将其演进为更高效的自动化版本。

这些解决方案可以简单也可以复杂，但它们拥有共同的模式。本书分析这些模式，并在第五部分——模式与用例中以复杂的真实用例作为收尾。

即使出发点很好，事情也可能出错。以下是一些需要警惕的常见陷阱。

1.3.2. 应避免的常见陷阱#

本书将揭示许多陷阱，因为我亲身经历过它们。以下是几个需要时刻牢记的：

• 试图一次自动化所有事情：从小处着手。选择高影响、低风险的用例，建立信心和专业积累。
• 将意图内嵌于工具之中：当命名规范、IP 分配策略和供应商行为假设存在于 Playbook 和脚本内部，而非共享参考中，就没有任何一份统一描述来说明网络应该是什么样子。环境一旦改变，所有内嵌假设同时崩塌。意图应该存放在一个地方，被所有自动化组件共享。
• 低估数据质量：自动化的质量取决于数据的质量。尽早投入数据准确性和一致性建设。
• 不经测试就构建：部署到生产环境之前，务必进行测试和验证。
• 自动化当前网络而非为变化而设计：围绕当前拓扑、供应商和命名规范构建的自动化，在某些事情改变之前都能运作。在构建任何自动化组件之前，要问的不是"现在能用吗？"，而是"当环境改变时，它还能用吗？“将现有网络固化在自动化中，会产生技术债，且随着业务每一次演进而不断积累。
• 为构建它的工程师而建，而非为使用它的人而建：只为构建团队自身设计的自动化平台，是单点故障。提交服务请求的应用团队、审批变更门控的运营人员、审阅合规报告的审计员，每个人都有不同的需求、不同的词汇、不同的期望。从一开始就将这些用户纳入考量，会影响每一个架构决策：API 如何设计、错误如何呈现、状态如何传达。工程师理解但用户无法使用的自动化，终将被悄悄绕开。

最后：让成果自己说话。怎么做？定义并追踪能够客观展示网络自动化价值及其业务影响的衡量指标。

1.3.3. 衡量自动化成效#

聚焦两类指标：技术指标和业务指标。两者对领导层都至关重要。

技术指标：

• 平均恢复时间（MTTR）：检测、诊断和解决网络问题的速度有多快？
• 变更成功率：在不引发故障的情况下，成功部署的网络变更占比是多少？
• Configuration Drift：各设备配置在整个网络中的一致性如何？
• 部署速度：实施新服务或配置变更的速度有多快？

业务指标：

• 服务可用性：自动化管理的服务是否比手动管理的更可靠？
• 工程生产力：团队是否将更多时间用于战略性工作，而非运维任务？
• 合规态势：验证和修复合规违规的速度有多快？
• 资源利用率：是否更好地利用了网络容量和性能？

定期追踪这些指标。它们能为持续投入提供依据，并指明改进方向。第 6 章将介绍可观测性模块如何采集和呈现这些指标；第 14 章将其与业务价值和平台产品思维相连接。

1.4. 小结#

那家物流公司的自动化平台在技术上是称职的。失败是架构层面的：没有统一的意图描述，没有将网络应有状态与实现路径分离，没有办法在环境变化时对系统进行推理。这种失败模式并不罕见，而是在将自动化视为脚本集合而非有原则设计的平台时，自然而然产生的结果。

驱动自动化的力量是结构性的，而非可选的：现代基础设施的规模、对开发者速度自助服务的期望，以及手动运营网络的持续攀升的成本。将自动化视为工具问题的组织，会发现每一个新环境都需要从头再来。将其视为架构问题的组织，则能构建出不断复利增值的平台。

三个支柱（人员、流程、技术）是一条依赖链，而非清单。能够规模化的技术选择，是在清晰流程的服务下，由理解问题的人做出的选择。把这个顺序搞对，才是区分能够持续成长的自动化与每隔几年就需要重建的自动化的关键所在。

自动化成熟度谱系从手动操作，经由脚本任务、工作流自动化、基于意图的系统，延伸至自治网络。当今大多数组织处于中间某处。本书构建基于意图层的架构基础：第一和第二部分阐述为什么和怎么做，第三部分审视规模化时的变化，第四和第五部分探索迈向自治运营的模式。

物流故事中的具体架构失败并非偶然，而是在没有明确原则的情况下设计自动化时的默认结果：没有共享意图，没有将网络应有状态与实现路径分离，没有办法在环境变化时对系统进行推理。第 2 章将命名这些原则，并将每个原则映射到它所预防的那类失败。

💬 Found something to improve? Send feedback for this chapter