4. 升级迁移风险登记册

升级迁移项目失败，很少是因为“命令敲错了”，更多是因为风险在变更前没有被识别、量化并绑定到具体动作。风险登记册（Risk Register）不是一张事后追责表，而是把“可能出问题的地方”提前变成“有负责人、有触发条件、有缓解动作、有回退路径”的可执行清单。对 Juniper 设备升级迁移而言，最值得优先登记的风险集中在四类：配置漂移、协议不兼容、硬件资源不足、回退窗口不足。它们分别对应“配置状态是否可信”“新旧软件能否互通”“设备能否承载新版本”“出问题后能否在业务容忍时间内恢复”。

一、配置漂移：先证明“当前配置就是你以为的配置”

配置漂移指设备实际运行配置与基线配置、设计文档或上一次归档之间出现未受控差异。常见来源包括：临时排障命令未清理、接口描述与 MTU 被手工修改、ACL 或防火墙过滤器被追加规则、路由策略被局部调整、SNMP 团体字或 TACACS+ 密钥被替换、VRRP/HSRP 优先级被改动。漂移本身不一定导致故障，但它会让升级后的行为不可预测，也会让回退失去“回到哪个状态”的基准。

识别方法不是只看 show configuration，而是做“三方比对”：当前运行配置、最近一次归档配置、设计基线。Juniper 上可先执行：

show configuration | display set | save /var/tmp/current.conf
show system rollback 1 | display set | compare /var/tmp/current.conf
show configuration | display set | match "mtu|description|priority|secret|filter"

第一条把当前配置以 set 格式落盘，第二条与回滚版本 1 做差异比对，第三条快速筛出高风险字段。若差异集中在接口 MTU、VRRP 优先级、路由策略或认证密钥，应逐条确认是“有意变更”还是“漂移”。缓解措施包括：升级前冻结配置变更窗口；对确认的漂移项先回写基线或更新基线文档；把关键配置片段纳入版本控制；升级后再次执行同一比对，确认没有新增漂移。风险登记册中应记录漂移项、影响范围、确认人、处理方式和关闭时间。

二、协议不兼容：重点看邻居、路由与认证

协议不兼容通常出现在新旧软件版本对同一协议的行为差异上，例如 OSPF 邻居建立参数、BGP 能力协商、IS-IS 度量风格、MPLS 标签分发、VRRP 版本、LACP 超时、LLDP 或 BFD 定时器。更隐蔽的是认证与加密套件变化，例如 SSH 算法、SNMPv3 认证加密、TACACS+ 报文兼容性。升级后“接口 up 但邻居 down”往往就是这类问题。

识别时不要只查版本说明，而要在实验环境或低峰期做“协议矩阵验证”：列出本设备与所有直连邻居、路由反射器、认证服务器之间的协议与参数，逐项确认新版本是否支持。示例参数表如下：

缓解措施：升级前在实验室或备用设备上完成协议互通验证；对关键邻居保留旧版本兼容配置；升级后按“先直连、再路由、后策略”的顺序逐层检查；若发现不兼容，优先调整参数而非立即回退，但必须设定观察时限。

三、硬件资源不足：看 CPU、内存、磁盘与转发表

新版本通常带来更大的内存占用、更多的进程和更复杂的转发表项。硬件资源不足的表现包括：升级后控制平面 CPU 持续高、内存剩余低于安全阈值、磁盘空间不足以保存新镜像和日志、FIB/ARP/ND 表项超限、CoS 队列或防火墙会话数达到上限。识别时应采集升级前基线：

show chassis routing-engine
show system storage
show system processes extensive | match "PID|CPU|MEM"
show route summary
show arp no-resolve | count
show ethernet-switching table summary

把 CPU、内存、磁盘、路由表、ARP 表、MAC 表、会话数记录为基线值。缓解措施：升级前清理旧镜像与日志，预留至少 20% 磁盘空间；对内存接近阈值的设备先评估是否需扩容；升级后对比基线，若 CPU 或内存持续超过阈值，应触发回退或降级部分特性。风险登记册中应写明“阈值—观察命令—超限动作”。

四、回退窗口：不是“能回退”，而是“来得及回退”

回退窗口指从发现严重问题到业务恢复可接受水平所允许的最长时间。它由业务容忍中断时长、镜像回滚耗时、配置恢复耗时、路由收敛时间和验证时间共同决定。很多团队只准备了回退镜像，却没有计算回退是否能在窗口内完成。例如业务允许中断 30 分钟，而镜像回滚加重启需 12 分钟、配置恢复 5 分钟、BGP 收敛 8 分钟、验证 5 分钟，合计 30 分钟，几乎没有余量，任何一步变慢都会超窗。

缓解措施：提前把回退镜像放入 /var/tmp 或备用分区；使用 request system software rollback 验证回退路径；保存回退配置并确认可加载；对关键业务准备“部分回退”方案，例如先回退单台设备或单个协议；在变更窗口内设置明确的时间检查点，一旦超过检查点仍未恢复，立即执行回退而不是继续排查。

五、把风险写成可执行的登记项

风险登记册的价值在于“可执行”。每条风险至少应包含：风险描述、触发条件、影响范围、可能性与影响程度、缓解动作、责任人、回退路径、关闭标准。例如“配置漂移—接口 MTU 被手工改为 9000”这条，触发条件可写“升级前比对发现 MTU 与基线不一致”，影响范围写“该接口承载的 MPLS 与 OSPF 邻居”，缓解动作写“确认业务需求后回写基线或更新文档”，关闭标准写“升级后再次比对无差异”。

实际执行时，建议把风险登记册与变更窗口绑定：升级前 24 小时完成识别与缓解准备；升级前 1 小时复核回退镜像、配置备份和检查点时间；升级中按“配置—协议—资源—回退”四条线并行观察；升级后 24 小时内完成漂移复比、协议邻居复查和资源基线对比。只有把风险从“知道有”推进到“知道何时触发、谁来做、做到什么程度算关闭”，升级迁移才真正具备可控性和可回退性。