4. 初始基线采集与文档化

变更治理的第一道防线不是审批流程，而是"知道变更前设备长什么样"。如果连初始基线都没有，任何变更后的差异比对都无从谈起，回滚也失去参照。本节聚焦于如何用最基础的 show 命令把一台 Cisco Catalyst 交换机的初始状态完整"冻结"下来，并把它整理成可长期维护的基线文档与设备清单。

为什么基线必须"采集"而不是"凭记忆"

很多工程师认为"这台交换机是我配的，我记得住"。但真实网络里，一台接入交换机的运行配置往往包含数百行：VLAN 定义、Trunk 允许列表、STP 参数、端口安全、DHCP Snooping、QoS 信任边界、SNMP 团体字、AAA、NTP、日志主机、ACL……其中相当一部分是历史遗留或他人临时添加的。凭记忆做变更，等于在未知地基上盖楼。基线采集的本质，是把"当前真实状态"变成"可存档、可比对、可回滚"的客观记录。

需要强调的是：基线不是一次性的。设备上线时采集的是"初始基线"，每次经审批的变更后应更新为"新基线"，两者之间的差异就是这次变更的全部影响面。因此基线文档必须带版本与时间戳，否则无法判断某条配置是"原本就有"还是"后来加的"。

三条核心命令各自回答什么问题

采集初始状态最常用的三条命令，职责边界非常清晰，不能互相替代：

• show running-config：当前内存中正在生效的配置，是设备"此刻的行为定义"。它包含所有已下发但可能尚未保存的改动，是差异比对和回滚的主要依据。
• show startup-config：NVRAM 中保存的配置，是设备"重启后会变成的样子"。它与 running-config 的差异，直接暴露了"改了但没保存"的风险。
• show version：硬件型号、序列号、IOS 版本与镜像文件、系统运行时间、配置寄存器值、内存与 Flash 容量。它回答的是"这台设备是什么、跑什么软件、能不能支撑目标特性"。

此外，show inventory 提供板卡与光模块的序列号，show interfaces status 提供端口速率与连接状态，show vlan brief 提供 VLAN 与端口归属，show cdp neighbors detail 或 show lldp neighbors detail 提供拓扑邻接关系。这些命令共同构成一份"设备身份 + 运行状态 + 邻接关系"的完整快照。

采集顺序与一致性要求

采集不是随便敲几条命令。为了让快照内部自洽，建议固定顺序：先 show version 与 show inventory 确认设备身份，再 show running-config 与 show startup-config 抓取配置，最后抓接口、VLAN、邻居等运行状态。原因是运行状态会随时间变化（如 STP 收敛、端口 up/down），而配置相对稳定；先固定身份与配置，再记录瞬时状态，能减少快照内部的矛盾。

采集时还应记录元数据：采集时间（建议用设备 show clock 的本地时间并注明时区）、采集人、设备管理 IP、登录方式（Console/SSH/Telnet）、连接的具体设备。这些信息在半年后回看时，价值不亚于配置本身。

从原始输出到基线文档

把命令输出直接贴进 Word 是最省事也最危险的做法：没有版本、没有差异、无法检索。更实用的做法是建立"设备清单 + 基线文档"两层结构。设备清单是索引，一行一台设备，记录身份与基线指针；基线文档是正文，按设备存放配置与状态快照。

下面给出一份可直接使用的设备清单模板（字段按 Catalyst 接入/汇聚场景设计，示例数据为合理假设，非实测）：

基线文档本身建议按固定小节组织：设备身份（version/inventory）、运行配置、启动配置、接口状态、VLAN、邻居、采集元数据。每份文档头部写清设备名、基线编号、采集时间、采集人、命令清单，便于他人复核。

采集与文档化的整体关系

下图把"命令采集 → 原始快照 → 结构化基线文档 → 设备清单索引"这条链路，以及 running-config 与 startup-config 的差异风险点放在一起，帮助理解各环节的输入输出关系。

采集过程中的常见坑

第一，只抓 running-config 不抓 startup-config。这会让"已改未存"的隐患被掩盖，一旦设备重启，实际行为与基线不符。第二，忽略 show version 中的配置寄存器值。若寄存器被设为 0x2142（忽略启动配置），设备重启后会进入空配置状态，这是重大风险点，必须在基线中显式记录。第三，采集时未记录时间与时区，导致后续无法判断基线新旧。第四，把不同设备的输出混在一个文件里，失去可追溯性。

一个可执行的采集命令清单

把采集动作固化成命令清单，可以避免遗漏。以下清单可直接在特权模式下按序执行，输出重定向到本地终端日志或 TFTP/SCP：

terminal length 0
show clock
show version
show inventory
show running-config
show startup-config
show interfaces status
show vlan brief
show spanning-tree summary
show cdp neighbors detail
show logging | include Log Buffer

采集完成后，用 show running-config | include hostname 与 show startup-config | include hostname 快速确认两份配置的首行设备名一致，再核对文件行数是否与终端输出末尾提示相符。若使用 SCP 导出，可用 copy running-config scp://user@10.20.3.11//baseline/SW-ACC-03F-01-running.cfg 直接落盘，避免手工复制引入截断。

基线文档的版本管理

基线文档一旦建立，就要纳入版本管理。推荐命名规则：设备名_基线编号_类型_日期.cfg，例如 SW-ACC-03F-01_BL-2024-03-01_running_20240301.cfg。每次经审批的变更后，生成新的基线编号并保留旧版本，形成可回溯的链条。设备清单中的"基线版本"字段随之更新，指向最新基线。这样，当某台设备出现异常时，可以快速定位"上一次已知良好状态"是哪一版，并据此回滚或比对。