2. Comware配置体系解析

在Comware设备上，“配置”并不是一份文件那么简单。设备内部同时存在多份配置视图：当前正在生效的运行配置、下次启动时加载的启动配置、以及被归档保存的历史配置。理解这三者的关系，是后续做配置合规检查与变更治理的前提。如果分不清“改了什么”和“下次重启后还剩什么”，变更治理就无从谈起。

一、配置文件结构与两类配置视图

Comware的配置文件是纯文本格式，以命令行形式逐行保存配置。它通常由若干段落组成：文件头部是版本与设备信息注释，随后是系统级配置（如sysname、时钟、日志主机），再往后是接口配置、路由协议、安全策略、用户线等模块化段落。每个段落以对应的配置命令开头，例如interface GigabitEthernet1/0/1之后跟随该接口下的所有子命令。这种“段落+命令”的结构，使得配置文件可读、可比较、可回滚。

设备上存在两个关键配置视图：

• 运行配置（running-config）：当前内存中生效的配置，所有即时修改都先进入这里。用display current-configuration查看。
• 启动配置（startup-config）：保存在存储介质（如flash）中的配置文件，设备重启时加载它。用display startup查看当前启动文件，用display saved-configuration查看其内容。

两者的差异是变更治理中最常见的风险点：在命令行下敲入的配置只进入运行配置，如果没有执行保存，重启后就会丢失。因此，变更流程中必须明确“改完是否保存、保存到哪个文件”。

二、配置归档机制

配置归档（archive）是Comware提供的自动备份能力。开启后，设备在指定时机（如保存配置时、定时）将当前配置复制到归档目录，并按规则保留多个历史版本。典型配置如下：

archive configuration server flash:/archive
archive configuration max 10
archive configuration interval 1440

上述示例表示：归档目录为flash:/archive，最多保留10个归档文件，每1440分钟（24小时）自动归档一次。归档文件通常带有时间戳，便于按时间点回溯。归档机制的价值在于：即使管理员忘记手动备份，也能从归档中找到变更前的配置版本，为回滚提供依据。

三、配置回滚点与版本管理基础

回滚点（rollback point）是配置版本管理的基本单位。Comware支持通过configuration replace file将当前运行配置替换为指定配置文件，从而实现回滚。回滚前，系统会自动生成一个回滚点，记录替换前的配置状态，便于反向恢复。

版本管理的基本操作包括：

1. 变更前归档或备份当前配置，形成基线版本；
2. 执行变更并验证业务；
3. 若变更失败，使用configuration replace file flash:/archive/xxx.cfg回滚到基线；
4. 回滚后再次验证，确认业务恢复。

需要强调的是，回滚不是“撤销命令”，而是“整份配置替换”。因此回滚文件必须是完整、可加载的配置文件，不能是片段。回滚操作本身也会产生新的回滚点，形成版本链。

四、变更治理中的关键检查点

把上述机制落到日常变更中，可以形成几个明确的检查点。第一，变更前确认当前运行配置与启动配置是否一致，若不一致，先判断这些差异是否是有意为之。第二，变更前手动归档或记录当前配置版本，作为回滚基线。第三，变更后先验证业务，再执行保存；保存前再次对比运行配置与启动配置的差异，确认保存内容符合预期。第四，若需要回滚，选择正确的归档文件执行替换，替换后重新验证并保存。

需要特别注意的是，归档文件本身也是配置文件，回滚时系统会加载整份文件。如果归档文件不完整或包含错误命令，回滚可能失败甚至导致配置异常。因此，归档目录应保持整洁，定期清理过期版本，避免误选。同时，回滚操作会改变运行配置，回滚后同样需要保存，否则重启后回滚结果也会丢失。

综合来看，Comware配置体系的核心逻辑是：运行配置是“现在”，启动配置是“重启后”，归档是“历史版本”，回滚点是“版本链上的锚点”。变更治理要做的，就是让这四个概念在每一次变更中都有明确的对应关系——改了什么、存了什么、能回到哪里、回到后是否验证。把这四件事固定成流程，配置合规与变更治理才有可落地的基础。