链路故障只能人工切换
主备链路和运营商状态缺少统一判断，异常发生后依赖人员登录多个设备处理。
先把广域网络的运行问题说清楚
SD-WAN 不是把交换机换一种叫法，而是把链路、应用和策略变成可运营的关系
多分支企业经常同时使用专线、互联网、5G 或其他接入方式。真正困难的是链路质量变化后，关键应用是否还能走对路径；新分支上线是否要重复大量配置；故障发生时能否区分运营商、设备、策略和应用依赖。
01 / 多分支问题
多条链路并不等于高可用，关键在于应用是否知道该走哪条路
传统广域组网容易把站点连接、链路质量、应用优先级和安全策略分散在不同设备与运营商界面里。链路是通的，不代表语音、视频、ERP、云应用和普通上网都获得了合理体验。
所有应用走同一条路径
语音、视频、ERP、云应用和普通流量没有按质量与优先级区分。
分支上线高度依赖现场
新站点需要重复配置链路、设备、路由、策略和监控，交付周期难以稳定。
02 / 覆盖与策略架构
把站点、传输、应用选路和安全检查放到同一条策略链
SD-WAN 设计要先梳理站点类型、链路资源、关键应用、云服务和安全边界，再决定覆盖网络、控制方式、选路条件和集中运维范围。它与办公室内的交换、路由和布线基础架构相互衔接，但解决的是广域运行与策略问题。
站点与链路抽象
总部、分支、数据中心、云和移动场景使用统一的站点与链路模型。
应用优先级与选路
按应用、质量、时延、丢包、带宽和业务优先级决定路径。
安全边界与日志
明确本地转发、集中检查、互联网出口、分支互访和云资源访问的策略责任。
03 / 上线与验证
从代表性站点开始，把选路、切换和安全策略验证清楚
SD-WAN 上线不能只验证控制器显示“在线”。还要验证不同链路状态下的应用体验、策略命中、故障切换、分支接入、云资源访问、日志和回退条件。
- 01
盘点站点与应用
梳理总部、分支、云、数据中心、运营商链路、关键应用和安全要求。
- 02
设计覆盖与策略
确定站点角色、链路接入、选路条件、本地转发、检查边界和监控指标。
- 03
试点与故障演练
在代表性站点验证应用访问、链路切换、策略、日志、云访问和异常回退。
- 04
分阶段推广与交接
按站点批次上线，保留配置、监控、变更、运营商协同和运维责任资料。
04 / 运行与扩展
交付后要能回答：哪条链路在工作、哪个应用受影响、下一步谁处理
SD-WAN 的长期价值在于把站点增长和链路变化变成可观察、可调整的运行工作。监控、应用体验、策略变更、运营商工单和分支上线资料要放到同一套运维基线里。
链路质量与应用体验
持续关注时延、丢包、抖动、带宽和关键应用体验，而不只看链路是否在线。
策略与变更记录
保留选路、优先级、安全检查、例外和回退的审批与配置变化。
分支标准化资料
形成新站点上线清单、设备模板、链路信息、验收项和责任人。
故障证据与协同路径
把设备、链路、运营商、策略、应用和安全日志关联起来，减少跨团队来回确认。
05 / 常见问题
项目开始前，应该先把这些问题问清楚
SD-WAN 会替代企业内部的交换机、路由器和布线吗？
不会。SD-WAN 主要处理总部、分支、云资源之间的广域连接和策略；办公室内部仍需要交换、路由、无线、布线和安全基础架构。
SD-WAN 一定要有两条专线吗？
不一定。可以根据站点业务、链路可用性、成本和安全要求组合专线、互联网、5G 等接入方式。
上线前最重要的验证是什么？
要验证关键应用在不同链路质量下的选路、切换、安全检查、日志和回退，而不是只验证设备上线。
下一步
从现有网络、用户和业务路径开始沟通。
说明现有拓扑、反复出现的问题、扩容计划或安全要求，再围绕真实运行环境确认实施范围。