1. 课程导入与治理框架
在数据中心与园区网络中，Arista EOS 设备以配置简洁、自动化能力强著称，但正因为变更入口多——手工 CLI、CloudVision、Ansible、Terraform、脚本推送——配置漂移和未授权变更的风险反而更高。本课程要解决的核心问题不是"如何敲命令"，而是"如何让每一次配置变更都可预期、可追溯、可回退"。本章先建立治理框架的整体认知，后续章节再逐层展开实现细节。
一、四个关键术语的准确定义
合规基线（Compliance Baseline）：一组被正式批准、代表"期望状态"的配置集合。它不是某台设备的当前配置，而是经过评审后固化的目标配置。在 Arista 环境中，基线通常以 EOS 配置片段、CloudVision Configlet 或结构化 YANG 数据的形式存在。例如一条基线可能规定：所有 Leaf 交换机必须启用 BGP 邻居的 maximum-routes 限制、必须关闭未使用的 Ethernet 端口、必须配置 NTP 与 TACACS+。基线必须版本化，否则无法判断"偏离"是相对哪个版本发生的。
变更窗口（Change Window）：允许执行配置变更的时间区间，通常伴随审批、影响范围声明和回退预案。变更窗口的意义在于把"随时可改"变成"受控可改"。一个典型的窗口记录包含：窗口起止时间、涉及设备清单、变更类型（新增/修改/删除）、风险等级、回退命令、执行人与审批人。窗口之外发生的配置改动，无论内容是否正确，都应被标记为异常。
漂移（Drift）：设备运行配置与合规基线之间的差异。漂移分两类：一类是"人为漂移"，即有人绕过流程手工修改；另一类是"自然漂移"，如接口状态、路由表、MAC 表等运行时数据变化——后者不属于配置漂移，治理对象只针对配置层面的差异。判断漂移时必须先明确比较基准：是比对上一次批准的基线，还是比对上一份快照？两者结论可能不同。
审计追踪（Audit Trail）：对"谁、在何时、从何处、改了什么、结果如何"的完整记录。Arista 侧可用的证据源包括：EOS 的 show configuration sessions、show history、系统日志中的 CONFIG 级别消息、CloudVision 的 Change Control 记录、以及外部 AAA（TACACS+/RADIUS）的记账日志。审计追踪的价值在于事后可还原，而不是事前可阻止。
二、治理闭环的整体架构
把上述四个术语串起来，就形成治理闭环：定义基线 → 采集现状 → 比对识别漂移 → 在变更窗口内审批与执行 → 记录审计追踪 → 更新基线。这个闭环的关键在于"比对"和"记录"两个环节必须自动化，否则规模一大就退化为人工抽查。
图中实线表示正常治理路径，虚线表示异常反馈路径。可以看到，漂移一旦被识别，有两条出路：若属于未授权变更，进入告警与复盘；若属于已批准的变更，则在变更窗口内执行后更新基线。这个分支判断是治理能否落地的分水岭——很多团队只做了"比对"，却没有区分漂移的性质，导致告警泛滥后被忽略。
三、为什么需要治理而不是只做备份
配置备份只解决"丢了能恢复"，不解决"改错了能发现"。治理要回答三个问题：当前配置是否符合预期？这次变更是否被授权？出问题时能否还原到变更前？在 Arista 环境中，这三个问题分别对应基线比对、变更窗口审批、审计追踪与回退。三者缺一，治理链条就断裂。
show running-config 定期导出快照，与基线做文本 diff，人工确认漂移性质；待流程稳定后再引入 CloudVision Change Control 或 Ansible 实现自动比对与审批。关键是先建立"基线—比对—记录"的最小闭环。
四、一个可参考的基线条目示例
下面是一段示例基线片段（属于教学示例，非实测配置），用于说明基线应包含哪些可判定的条目。每条都应能被自动检查：
! 基线 v1.2 —— Leaf 交换机通用
hostname Leaf-*
!
ntp server 10.0.0.10 prefer
ntp server 10.0.0.11
!
tacacs-server host 10.0.0.20
aaa authentication login default group tacacs+ local
!
interface Ethernet1-48
no shutdown
!
interface Ethernet49-52
shutdown ! 未使用上联口必须关闭
!
router bgp 65001
maximum-paths 4
neighbor 10.1.1.1 maximum-routes 12000
判断漂移时，逐条比对即可：若某台 Leaf 的 Ethernet50 处于 no shutdown，而基线要求 shutdown，这就是一条明确的配置漂移。若某台设备的 NTP 服务器被改成 10.0.0.12，同样属于漂移。基线条目的粒度决定了漂移检测的精度——条目越具体，越容易自动判定，但也越需要维护。
五、治理闭环中的角色与职责
治理不是一个人的事。通常涉及四类角色：网络工程师负责提出变更与执行；变更审批人负责评估风险与批准窗口；合规审计员负责定期检查漂移与审计记录；自动化平台（CloudVision、Ansible、CI/CD）负责采集、比对与记录。角色可以兼任，但职责必须明确，否则"谁来看漂移告警"就会落空。