4. 变更治理流程设计
网络变更治理的核心不是“把变更做完”，而是让每一次变更都处于可申请、可评估、可审批、可实施、可验证、可回退、可关闭的闭环之中。对于运行 Comware 的交换机、路由器等设备而言，变更往往涉及接口配置、路由协议、ACL、VLAN、堆叠、IRF、QoS 等关键能力，一旦缺少流程约束，单条命令就可能引发业务中断。因此，本节把变更治理流程拆成七个阶段，并结合 Comware 场景说明每个阶段应产出什么、如何判断是否通过。
一、变更申请：把“想改什么”变成可审阅的工单
变更申请是流程的入口。申请人不能只写“调整一下核心交换机”，而应提交结构化信息：变更标题、涉及设备（如 SW-Core-01、SW-Core-02）、当前软件版本（display version）、变更类型（紧急/常规/标准）、计划窗口、影响范围、变更前配置基线、拟变更命令、验证方法、回退方案。Comware 场景中，建议在申请单中附上 display current-configuration 的关键片段和 display interface brief 的现状，作为变更前基线。
例如，某园区网需要为新增服务器区放通 VLAN 120，申请单应写明：目标设备为接入交换机 SW-Access-03，当前 uplink 为 GE1/0/24，允许 VLAN 列表为 10、20、30，计划新增 VLAN 120 并放通对应端口。申请阶段不追求技术方案完美，但必须让审批人看懂“改什么、为什么改、影响谁”。
二、风险评估：识别技术风险与业务风险
风险评估不是泛泛而谈，而要落到具体对象和参数。技术风险包括：配置冲突、协议震荡、ACL 误拦截、路由环路、堆叠分裂、版本兼容性；业务风险包括：影响用户数、影响时段、是否涉及生产核心、是否有冗余路径。Comware 场景中，可借助 display diagnostic-information、display logbuffer、display cpu-usage 等命令评估设备当前健康度。
风险等级可按“影响范围 × 发生概率”划分。例如，核心交换机上修改 OSPF cost 属于高影响、中概率，应定为高风险；接入交换机新增 VLAN 属于低影响、低概率，可定为低风险。高风险变更必须安排冗余路径验证和回退演练，低风险变更可简化审批但不可省略验证。
三、审批：分级授权与窗口确认
审批阶段要解决“谁有权批、批什么、什么时候批”。建议按风险等级分级：低风险由网络运维组长审批；中风险由网络主管审批；高风险由变更委员会审批，并同步通知业务方。审批人重点确认：变更窗口是否避开业务高峰、回退方案是否可执行、验证方法是否可观测、是否已通知相关方。
Comware 场景中，审批单应明确变更窗口，例如“周六 00:30—02:00”，并要求申请人在窗口前完成配置备份。若涉及 IRF 堆叠，还需确认主备角色和 MAD 检测状态，避免变更中触发分裂。
四、实施：按脚本执行，保留操作痕迹
实施阶段最忌“边想边敲”。应把拟变更命令整理成可复制的脚本，并在实施前再次备份。Comware 常用操作包括：进入系统视图、创建 VLAN、配置接口、保存配置。示例脚本如下：
system-view
vlan 120
description Server_Zone
interface GigabitEthernet1/0/24
port link-type trunk
port trunk permit vlan 10 20 30 120
quit
save force
实施过程中应逐条执行并观察回显，遇到报错立即停止。建议开启 terminal logging 和 terminal trapping，保留操作日志。若变更涉及多台设备，应按“先边缘后核心、先备后主”的顺序推进，避免同时操作导致故障定位困难。
五、验证：用可观测指标判断是否达成目标
验证不是“看一眼没报错”，而是用命令和业务指标确认结果。Comware 场景中，可执行 display vlan 120 确认 VLAN 已创建，display interface GigabitEthernet1/0/24 确认 trunk 允许列表包含 120，display mac-address vlan 120 确认服务器 MAC 已学习，ping 或 tracert 验证业务连通性。若涉及路由变更，还应检查 display ospf peer、display ip routing-table 是否收敛正常。
验证结果应记录在工单中：通过、部分通过或不通过。部分通过时，要判断是变更未生效还是业务本身另有问题，避免误判后继续操作。
六、回退：回退方案必须可执行、可验证
回退不是“再改回去”这么简单，而是要有明确的触发条件、回退步骤和回退后验证。触发条件包括：业务中断超过 5 分钟、关键路由丢失、CPU 异常升高、堆叠分裂等。回退步骤应优先使用配置回滚或备份恢复。Comware 支持 configuration replace file 进行配置回滚，也可手动执行反向命令。
例如，若 VLAN 120 放通后导致广播异常，可执行：
system-view
interface GigabitEthernet1/0/24
undo port trunk permit vlan 120
quit
save force
回退后必须重新验证原业务是否恢复，并记录回退原因和耗时，作为后续改进依据。
七、关闭：归档证据，形成改进项
关闭阶段要确认变更目标达成、验证通过、回退未触发或已恢复、相关方已通知。工单中应归档：变更前基线、实施脚本、验证输出、回退记录、审批意见。若变更过程中出现异常，应转为问题单跟踪，避免“变更关闭即遗忘”。
下面用一张流程图展示七个阶段之间的流转关系，以及每个阶段的关键产出和判断点。
把上述流程落到 Comware 日常运维中，还需要注意三点：第一，变更窗口与业务低峰匹配，避免在流量高峰执行高风险命令；第二，所有命令必须经过预演或实验环境验证，尤其是 ACL、路由策略和 IRF 相关操作；第三，变更记录要可追溯，建议在工单中保留 display current-configuration 变更前后差异，便于审计和复盘。
变更治理流程的价值，最终体现在“变更可控、风险可识、结果可验、失败可退”。在 Comware 场景中，把命令、参数、验证命令和回退命令写清楚，比任何口号都更能保障网络稳定。