1. 课程导入与EOS自动化全景

在数据中心与园区网络中，Arista EOS（Extensible Operating System）之所以被大量自动化项目选为落地平台，核心原因并不只是“支持脚本”，而是它把网络设备的可编程能力做成了系统级的一等公民。EOS 基于 Linux 内核构建，控制平面进程以独立容器化方式运行，配置、状态、事件、计数器都可以通过统一的接口被读取和驱动。这意味着自动化不是外挂在设备之外的补丁，而是设备本身对外暴露的一种稳定能力。

要理解 EOS 自动化，先要建立一张全景图：谁在驱动、驱动什么、如何验证、结果如何回流。典型工具链中，Ansible 负责声明式配置下发与批量编排，Python 与 eAPI 负责精细化的数据读写和逻辑判断，CloudVision 负责集中管理与合规审计，pytest 与 Batfish 负责变更前后的验证。它们不是互相替代的关系，而是分别覆盖“编排—执行—验证—审计”四个环节。

这张全景图揭示了 EOS 自动化的基本分层逻辑：编排层负责“表达意图”，接口层负责“传递意图”，设备层负责“执行并暴露状态”，验证层负责“确认结果”。四层之间通过明确的数据流串联，而不是靠人工在设备上反复敲命令来确认。

从“能连上”到“能验证”

很多初学者把自动化等同于“用脚本批量登录设备”。这只能算第一步。真正可交付的自动化，必须回答三个问题：变更前设备是什么状态、变更中发生了什么、变更后是否达到预期。以园区接入交换机批量修改 VLAN 为例，Ansible 负责把 VLAN 配置推送到 20 台设备，但如果没有验证环节，你无法知道其中是否有 3 台因为接口模式不匹配而静默失败。

EOS 提供的 eAPI 让这种验证变得可编程。通过 HTTP POST 发送 JSON-RPC 请求，可以一次性获取多台设备的 show vlan、show interfaces status、show running-config 等结构化输出。例如，用 Python 的 requests 库向 eAPI 发送如下请求，即可拿到 VLAN 列表：

import requests, json

url = "https://10.0.0.1/command-api"
payload = {
    "jsonrpc": "2.0",
    "method": "runCmds",
    "params": {
        "version": 1,
        "cmds": ["show vlan"],
        "format": "json"
    },
    "id": 1
}
resp = requests.post(url, data=json.dumps(payload),
                     auth=("admin", "admin"),
                     verify=False)
result = resp.json()["result"][0]
print(result["vlans"].keys())

这段代码的关键不在于语法，而在于它展示了 EOS 自动化的核心模式：用结构化数据替代人工读屏。返回的 JSON 可以直接被断言、被比对、被写入报告，从而形成可重复的验证闭环。

典型工作流与角色分工

在一个中等规模的数据中心里，EOS 自动化通常按以下节奏运转：网络工程师在 Git 仓库中维护设备清单和配置模板；CI 流水线在合并请求时触发 Batfish 做配置建模，检查是否存在路由环路或 ACL 冲突；合并后 Ansible 按批次下发配置，每批完成后 pytest 通过 eAPI 采集状态并断言；最后 CloudVision 汇总合规结果并生成审计记录。整个过程中，人只负责定义“什么是对的”，机器负责执行和证明。

需要特别注意的是，EOS 自动化不是“把 CLI 命令塞进脚本”那么简单。EOS 的配置会话机制允许你在一次提交中完成多行变更，并支持回滚到上一个快照；Sysdb 则把设备状态抽象成可订阅的路径。理解这些机制，才能在自动化中正确使用 configure session、commit、rollback 等操作，而不是用 write memory 粗暴覆盖。

本课程的能力地图

围绕“开发与验证”这一主线，课程将覆盖四类能力：第一，用 Python 和 eAPI 完成设备数据的读取、解析与判断；第二，用 Ansible 实现配置模板化与批量编排；第三，用 pytest 和 Batfish 构建变更前后的验证体系；第四，用 CloudVision 和 CI/CD 把上述能力串成可持续运行的流水线。每一类能力都对应真实网络运维中的具体痛点，而不是孤立的技术演示。

当你完成本课程后，应该能够独立完成这样一件事：拿到一份包含 50 台 EOS 交换机的设备清单，编写可复用的配置模板，通过流水线完成批量变更，并在变更后自动生成一份包含 VLAN、接口状态、路由邻居、ACL 命中计数的验证报告。这份报告不是“命令回显的堆砌”，而是带有明确通过/失败判断的结构化证据。这正是 EOS 自动化开发与验证的核心价值所在。