SD-WAN 怎么部署？从线路准备、组网设计到上线验收
很多企业知道 SD-WAN 可以统一管理多条线路，但真正准备部署时，问题往往变成了：现有宽带、专线和 4G/5G 能不能直接接入？分支地址怎么规划？切换会不会影响收银、ERP 和视频会议？上线后如何证明方案真的有效？
SD-WAN 部署不是把设备接上、隧道亮起来就结束。一个可交付的项目，至少要完成线路盘点、网络设计、业务策略、灰度上线、故障演练和验收留档。本文按中小企业和多分支项目的实际实施顺序，拆解一套可以执行的部署方法。
先给结论：部署顺序比设备参数更重要
| 阶段 | 要完成的事情 | 必须留下的结果 | 常见遗漏 |
|---|---|---|---|
| 现状盘点 | 线路、地址、业务、设备和故障基线 | 站点清单、链路表、业务清单 | 只统计带宽，不记录真实质量 |
| 方案设计 | 拓扑、地址、路由、出口和策略设计 | 组网图、地址规划、策略表 | 没有定义管理面和数据面的故障边界 |
| 实施准备 | 设备、账号、线路、割接窗口和回退方案 | 实施检查表、回退预案 | 现场才发现公网地址、NAT 或权限不满足 |
| 灰度上线 | 选择代表性站点先验证 | 试点记录、问题清单、调整项 | 一开始就全量变更 |
| 验收交付 | 故障演练、性能对比和文档交付 | 验收报告、配置备份、运维手册 | 只截图“在线”，没有业务证据 |
一、部署前先盘点：不要从“买设备”开始
部署前最重要的工作，是把当前网络和业务事实记录下来。否则上线后出现问题，很难判断是 SD-WAN 引入了新故障，还是原有网络问题被暴露出来。
1. 线路盘点
- 每个站点有哪些 WAN 线路，分别是哪家运营商、什么接入方式和带宽。
- 线路是否有固定公网地址，是否经过运营商级 NAT 或企业防火墙。
- 默认网关、DNS、MTU、拨号方式和 VLAN 信息是否完整。
- 高峰时段的延迟、丢包、抖动、可用带宽和历史故障情况。
- 线路合同、维修联系人、SLA 和故障报修路径。
“100M 专线”和“100M 宽带”不能只按标称带宽判断。实际设计还要看上行、到目标区域的路径质量、地址条件和故障恢复能力。
2. 业务盘点
至少列出收银、ERP、财务系统、视频会议、远程桌面、SaaS、备份和大文件传输等业务，并记录它们的访问方向、端口或域名、可接受中断时间和优先级。
二、组网设计：先决定流量怎么走
SD-WAN 组网设计的核心不是画一张漂亮的拓扑图，而是明确每一类业务的源、目的、路径、出口和故障后的备用动作。
常见的三种拓扑
| 拓扑 | 适合场景 | 优点 | 需要注意 |
|---|---|---|---|
| 分支到总部 | 核心系统集中在总部或数据中心 | 结构直观，便于统一安全控制 | 总部出口和链路可能成为瓶颈 |
| 分支直接访问云 | SaaS、公有云和互联网业务较多 | 减少绕行，改善访问路径 | 要明确本地出口、安全和审计责任 |
| 混合组网 | 既有总部系统，也有云和本地互联网 | 按业务选择路径，灵活性高 | 策略、DNS、地址和安全边界更复杂 |
地址规划至少要考虑 5 个边界
- 各分支 LAN 网段不能重复，否则路由无法准确区分站点。
- 总部、数据中心、云 VPC、运维网和访客网要明确是否互通。
- Overlay 地址、隧道地址和 Underlay 地址不能混用。
- 需要与现有防火墙、交换机、MPLS 或第三方网络互联时，提前确认路由协议和汇总方式。
- 未来新增分支时要有可扩展的地址段，避免上线后重新改全网路由。
三、实施前检查：把最容易卡住项目的条件提前确认
| 检查项 | 确认内容 | 不满足时的影响 |
|---|---|---|
| 线路接入 | 接口、VLAN、拨号、网关、公网地址和 MTU | 设备无法上线或隧道不稳定 |
| NAT 与防火墙 | 出站访问、必要端口、对端可达性和会话保持 | 控制连接、隧道或部分业务失败 |
| 管理权限 | 云平台账号、设备权限、DNS、证书和时间同步 | 激活、策略下发或审计异常 |
| 局域网协同 | VLAN、网关归属、交换机端口和 DHCP 规划 | 设备在线但终端业务不通 |
| 割接窗口 | 业务低峰、现场人员、联系人和回退时间 | 问题出现时无法快速恢复 |
| 备份与替换 | 旧设备配置、SD-WAN 配置、备用设备和恢复方式 | 故障后恢复时间不可控 |
如果项目采用零接触部署，也不能省略现场准备。零接触只减少设备初始化工作，并不会自动解决线路、VLAN、地址冲突和终端网关问题。
四、业务策略：先做少量关键规则
第一版策略不宜一上来就做几十条。中小企业通常可以先覆盖 3–5 类真正影响经营的业务：
- 收银和 ERP：优先保障可达性和稳定性，设置明确备用路径。
- 视频会议和语音：重点关注丢包、抖动和交互延迟。
- 远程桌面：优先低延迟和低突发丢包路径。
- 云应用和 SaaS：根据访问位置决定本地出口还是回总部。
- 备份和大文件：限速或降低优先级，避免占满关键线路。
每条策略都应写清楚：匹配对象、正常路径、触发阈值、备用动作、回切条件和验证方法。没有验证方法的策略，实际上只是配置愿望。
五、灰度上线：选择“有代表性”的站点
试点站点不要只选择网络最简单的分支。更合理的选择是：一条站点规模中等、业务较多、线路类型具有代表性，同时现场有人配合的分支。
推荐的灰度步骤
- 记录改造前的链路质量、关键应用时延和用户体验。
- 完成设备上架、WAN 接入和管理平台激活。
- 先建立基础隧道和路由，不要同时修改所有业务策略。
- 验证总部、数据中心、云应用和互联网访问。
- 逐条启用关键业务策略，观察命中情况。
- 在低峰期断开主链路，确认备用路径和告警。
- 制造一定的背景流量，验证关键业务是否仍被优先保障。
- 记录问题、调整参数，再决定是否复制到其他站点。
六、上线验收：必须用业务结果证明
| 验收场景 | 操作 | 合格证据 |
|---|---|---|
| 主链路中断 | 断开主 WAN 或模拟接口故障 | 关键业务恢复、告警产生、切换记录完整 |
| 质量劣化 | 模拟延迟、丢包或抖动升高 | 符合策略的业务改变路径或触发降级 |
| 链路拥塞 | 制造备份或大文件流量 | 会议、ERP、远程桌面体验不被明显拖慢 |
| 管理面异常 | 临时阻断编排平台访问 | 明确现有业务是否继续，恢复后状态可同步 |
| 设备替换 | 使用备用设备恢复站点 | 激活、配置恢复和业务恢复时间有记录 |
| 主链路恢复 | 恢复原线路 | 回切稳定，无频繁来回切换和会话异常 |
验收报告至少应包含测试时间、站点、线路、业务、操作动作、测试结果、截图或日志证据，以及未解决问题和责任边界。只有这样，后续出现故障时才有可对照的基线。
七、部署中最常见的 7 个错误
- 没有盘点现有地址，导致分支网段重复。
- 只看带宽，不看高峰期丢包、抖动和实际访问路径。
- 把所有业务都设计成回总部，云应用反而增加绕行。
- 把“设备在线”当成“终端业务正常”。
- 没有先试点，就直接批量推送全网配置。
- 只测试线路断开，不测试质量劣化、拥塞和管理面故障。
- 没有回退方案，出现问题时只能临时拆设备和改交换机。
结论：一套能交付的 SD-WAN，要经得起故障演练
SD-WAN 部署可以归纳为一条清晰的闭环：先盘点线路和业务，再设计地址与路径；先完成实施条件检查，再选择代表性站点灰度上线；最后用故障演练和业务证据完成验收。
对中小企业而言，不需要一开始就追求最复杂的架构。先把关键业务、线路质量、备用路径、配置回退和运维责任说清楚，往往比堆叠更多功能更重要。真正合格的方案，应当在发生线路故障或质量下降时，能够快速判断影响范围、执行预定动作，并留下可复核的证据。