1. 升级迁移项目启动

网络升级迁移项目的失败，很少是因为技术方案不够先进，更多是因为项目在启动阶段就没有把"为什么做、做到哪、谁说了算、怎样算成功"这四件事说清楚。Juniper设备的升级迁移尤其如此：一台EX4300从Junos 15.1升级到21.4，或者把MX960从传统L3VPN架构迁移到EVPN-VXLAN，涉及的不只是命令行差异，还包括硬件兼容性、协议行为变化、业务中断窗口、回退路径和多方协调。启动阶段的工作质量，直接决定了后续割接窗口是"按计划完成"还是"通宵救火"。

一、业务驱动：把"要升级"翻译成可验证的诉求

业务驱动不是"厂商停止支持了"这一句话。它需要被拆解成可验证的诉求，才能支撑后续的范围和成功标准。常见的驱动可以归为四类：

• 生命周期与合规驱动：当前Junos版本已EOL（End of Life），不再获得安全补丁。例如Junos 15.1X49在2022年已进入EOS阶段，继续运行意味着CVE漏洞无法修复，等保或行业审计会直接开不符合项。
• 容量与性能驱动：现网设备CPU在忙时持续超过70%，或MAC表项、ARP表项接近规格上限。例如EX4300-48T的ARP表项规格约16000条，当接入终端增长到12000以上时，控制平面压力会显著上升。
• 业务功能驱动：新业务需要EVPN-VXLAN、Segment Routing或MACsec等特性，而当前平台或版本不支持。例如数据中心需要跨Pod二层延伸，传统VLAN+STP方案已无法满足收敛时间要求。
• 架构演进驱动：从传统园区三层架构向EVPN-VXLAN Spine-Leaf架构迁移，或从物理防火墙向vSRX/vSRX集群迁移。

把驱动写清楚的价值在于：当项目后期出现"要不要顺便把这块也改了"的争论时，可以回到驱动清单判断——不在驱动范围内的，一律进入变更流程，而不是在割接窗口里临时决定。

二、范围界定：明确"改什么、不改什么、依赖什么"

范围界定要回答三个问题：设备范围、版本范围和功能范围。设备范围要精确到具体设备名、序列号、机房位置和当前Junos版本。版本范围要明确目标版本，例如"从Junos 18.4R3升级到20.4R3-S3"，而不是笼统的"升级到最新版"。功能范围要区分"迁移中必须保持不变的"和"迁移中允许调整的"。

一个实用的做法是建立范围矩阵，把每台设备的状态标注清楚。下面是一个示例（参数为教学假设，非实测数据）：

范围界定还要明确"不做什么"。例如本次不调整IP地址规划、不改变IGP/BGP AS号、不引入新硬件。这些"不做"的边界，能有效防止范围蔓延。

三、干系人识别：谁提供信息、谁做决策、谁承担后果

升级迁移项目的干系人通常包括：网络运维团队（执行升级和回退）、业务系统负责人（确认业务影响窗口）、安全团队（确认合规要求）、机房/布线团队（配合硬件更换）、厂商TAC（提供版本兼容性确认和故障支持）、以及最终用户代表（确认业务体验）。

干系人识别的关键不是列名单，而是明确每个干系人的角色：谁提供信息（如当前配置基线）、谁做决策（如割接窗口是否批准）、谁承担后果（如业务中断的责任归属）。建议在启动阶段就确定一个RACI表，至少明确"批准割接窗口"和"决定回退"这两个关键决策的负责人。

四、成功标准定义：可观测、可判定、可回退

成功标准不能是"升级顺利完成"。它应该是可观测、可判定、可回退的。通常包括：

• 技术标准：目标版本安装成功，所有接口UP，路由协议邻居建立，关键业务网段互通，CPU/内存处于正常范围。
• 业务标准：核心业务系统在割接后30分钟内恢复正常访问，丢包率低于0.1%，时延不超过基线值的120%。
• 时间标准：单台设备升级窗口不超过45分钟，整体割接在维护窗口内完成。
• 回退标准：若升级后30分钟内关键业务未恢复，或出现无法快速定位的协议震荡，立即执行回退。

这些标准需要在启动阶段就与业务方确认，而不是在割接当晚临时判断。下面这张图展示了启动阶段四个核心要素之间的输入输出关系，以及它们如何共同支撑后续的升级执行与验证。

五、启动阶段的实操要点

在实际项目中，启动阶段通常需要产出几份关键文档：项目章程（一页纸说明驱动、范围、干系人和成功标准）、范围矩阵（设备级清单）、RACI表（关键决策角色）、以及割接窗口的初步计划。这些文档不需要很长，但必须经过业务方和运维方共同确认。

一个容易被忽略的细节是：在启动阶段就要确认当前配置基线。建议在升级前对每台设备执行 show configuration | display set 并保存，同时记录 show version、show chassis hardware 和关键接口的 show interfaces extensive 输出。这些基线数据在升级后用于对比，是判断"是否恢复正常"的重要依据。

总结来说，升级迁移项目启动的核心任务，是把一个模糊的"要升级"转化为一份可执行、可验证、可回退的项目定义。业务驱动回答"为什么"，范围界定回答"改什么"，干系人识别回答"谁参与"，成功标准回答"怎样算完成"。这四件事在启动阶段做得越扎实，后续的版本核查、配置迁移、割接执行和验证工作就越有依据。