SD-WAN策略变更如何回滚

SD-WAN策略变更如何回滚，回滚是在变更之前就把上一份能用的配置存下来，并约定什么情况下用它。等业务已经中断再去找昨天的文件，通常会发现文件没导出，或者导出了却和现在的设备对不上。

每次变更只做一件事。改会议走哪条线，就不要同一天改探测指标和云的网段。一件事失败，回滚就是撤回这一件。三件一起改，撤回时不知道该回到哪一个早上。变更单上写这一件的目的、影响的分支、计划的开始和结束时间。

导出放在变更开始前，不要放在「看起来成功」之后。导出的人把文件名写成日期加上分支范围，存到中心的目录，不存在个人电脑桌面。另一位同事要能在你不在时找到它。找不到，这次变更就不开始。

回滚的触发写死，不要写成「视情况」。例如会议试验失败、超过约定分钟数仍有分支失联、云的业务端口打不开。出现其中一条，就执行回滚，不在故障里继续改新策略。继续改会把回滚点也弄丢。谁有权宣布回滚，写名字或写值班角色。在场的人都觉得再试一下，结果没有人执行。

回滚之后用和变更前相同的试验再做一遍。会议还走原来的线，命中计数恢复，失联的分支重新在线。只把配置传回去、不做试验，可能只是文件传了，设备没生效。试验通过，再通知使用的人可以继续。通知里说明已经回到变更前，不要让对方以为新策略还在。

设备若在回滚过程中重启，先确认它起来之后拿到的是旧策略还是半份新策略。半份最麻烦，路由在、识别不在。试点里做一次演练：传一份新策略，再传回旧的，看业务是否回到原样。演练没做过，真故障时才第一次用回滚，步骤会卡在权限和文件路径上。

多分支不要一次全改。先改试点的两个，试验通过再放其余。试点失败就只回滚这两个，其余分支还在旧策略上，影响面停在试点。一次下发到所有国家，回滚也要所有国家一起回，时间更长。

记录留下。变更单写实际开始时间、是否回滚、回滚后的试验是否通过。下次有人想做同样的修改，能看到上次为什么撤回。没有记录，同样的改动会在下个月再失败一次。

举一个完整的回滚。变更前导出，试点两个分支，会议试验失败，值班按约定传回旧配置，再测一次会议走回原线路，然后停掉这次变更。

举一个做不成的回滚。没人导出，三件改动叠在一起，失败后只能在线上继续猜。这时已经没有回滚，只剩排错。

SD-WAN策略变更如何回滚，关键在变更前的文件、只改一件事、以及什么情况必须停。文件不存在，回滚就只是一句打算。