企业选择 SD-WAN 服务商，需要核对哪些技术指标和服务内容？

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

摘要：本文面向正在评估 SD-WAN 服务商的企业，提供一套可直接用于供应商沟通的选型方法。文章从梳理实际业务需求出发，依次讲解如何核对网络质量（延迟、丢包率、抖动、实际吞吐量）、网络监控与故障处理机制、设备管理与部署兼容性、服务响应时间与 SLA 条款，并给出技术、服务、商务三类供应商评估检查清单，最后建议在签约前通过 POC 实际测试验证方案效果。核心观点是：选择 SD-WAN 服务商，关键不在于功能多少或报价高低，而在于各项指标能否被测量、被验证。

企业在选择 SD-WAN 服务商时，最容易遇到的问题并不是没有供应商可选，而是不同供应商提供的方案看起来都差不多。

有的强调网络速度，有的强调智能调度，有的主打设备管理，还有的重点介绍售后服务。但对于企业来说，真正需要关注的并不是供应商介绍了多少功能，而是这些功能能否满足实际业务需求，以及出现问题时能否提供可验证的技术支持。

例如，企业有多个办公地点，需要共同访问 ERP 系统、云平台和海外业务系统。如果某个办公地点访问正常，另一个办公地点却频繁出现延迟和连接中断，那么单纯比较带宽大小显然不够。

因此，企业评估 SD-WAN 服务商，应该从业务需求、网络质量、监控能力、设备管理、兼容性、服务响应和 SLA 等方面进行综合判断。

本文整理了一套可以直接用于供应商沟通的评估方法和检查清单。

一、先明确企业的实际业务需求

在联系 SD-WAN 服务商之前，企业应该先梳理自身的网络使用情况。

这是整个选型过程的基础。如果连需要解决什么问题都没有明确，后续就很难判断供应商提供的方案是否合适。

企业可以先从以下几个方面进行整理。

1. 明确需要访问的业务系统

不同业务对网络质量的要求并不相同。

例如：

• ERP、CRM：关注连接稳定性、响应时间和数据传输效率。
• 视频会议：关注延迟、抖动和丢包率。
• 云平台：关注访问速度、连接成功率和链路稳定性。
• 文件传输：关注实际吞吐量和持续传输能力。
• AI 应用：关注访问成功率、响应时间和连接稳定性。
• 社媒运营平台：关注登录环境、IP 地址稳定性和访问连续性。

企业不能只告诉供应商需要多少兆带宽，还应该说明具体使用哪些系统、主要访问哪些区域，以及业务高峰通常出现在什么时间。

2. 明确网络接入规模

企业还需要统计当前网络规模和未来扩展需求。

建议提前整理：

• 当前办公地点数量。
• 每个地点的员工数量。
• 每个地点的终端设备数量。
• 当前使用的网络出口数量。
• 是否存在远程办公需求。
• 是否需要连接云服务器或数据中心。
• 未来一年预计新增多少办公地点。

这些信息会直接影响设备选型、网络架构、带宽规划和整体成本。

3. 区分必须满足的需求和可选需求

并不是所有企业都需要复杂的网络功能。

例如，只有两个办公地点的小型企业，可能更关注部署成本、网络稳定性和日常维护；拥有几十个分支机构的企业，则可能更关注统一管理、策略下发、链路监控和故障切换。

建议将需求分成两个等级：

• 必须满足：业务访问稳定、网络质量可监测、故障有人处理。
• 优先考虑：多链路调度、统一设备管理、自动化配置、业务流量识别和弹性扩展。

先确定需求，再比较方案，能够避免为暂时用不到的功能支付额外成本。

二、核对网络质量：不要只看带宽大小

网络质量是评估 SD-WAN 服务商最重要的技术环节之一。

供应商通常会介绍带宽、延迟、丢包率等指标，但企业需要进一步了解这些指标是如何测量的、在哪些条件下测量，以及能否通过实际测试进行验证。

1. 延迟（Latency）

延迟是指数据从发送端到接收端所需要的时间，通常使用毫秒（ms）表示。

延迟越高，业务交互等待时间通常越长。

企业在评估时，需要关注：

• 不同办公地点到目标系统的延迟。
• 正常时段和业务高峰期的延迟差异。
• 平均延迟与 P95、P99 延迟。
• 不同链路之间的延迟差异。

其中，P95 表示 95% 的测量结果不超过该数值，P99 则表示 99% 的测量结果不超过该数值。

相比单纯提供一个平均延迟，P95 和 P99 更有助于发现偶发性的高延迟问题。

2. 丢包率（Packet Loss）

丢包率是指发送的数据包中没有成功到达接收端的比例。

丢包可能造成页面加载缓慢、远程连接卡顿、视频会议质量下降，甚至业务连接中断。

建议供应商提供：

• 不同目标地址的丢包率。
• 不同时间段的丢包变化。
• 各条链路的丢包情况。
• 丢包异常时的告警和处理记录。

需要注意的是，测试结果必须明确测试目标、测试时长、数据包数量和测试方式，否则不同供应商的数据并不具备直接可比性。

3. 网络抖动（Jitter）

网络抖动是指数据包到达时间的变化程度。

对于语音、视频会议和实时交互业务，抖动往往比单纯的平均延迟更值得关注。

企业可以要求供应商提供：

• 平均抖动。
• P95 抖动。
• 高峰期抖动变化。
• 是否支持根据链路质量进行动态调度。

4. 实际吞吐量

带宽标称值不等于业务实际能够使用的吞吐量。

例如，供应商提供的网络接入带宽为 100 Mbps，并不代表企业在所有时间、所有访问目标下都能够持续获得 100 Mbps 的有效吞吐量。

企业需要核对：

• 标称带宽与实际可用带宽。
• 上行和下行吞吐量。
• 多终端同时使用时的表现。
• 高峰期吞吐量变化。
• 是否存在流量限制或公平使用策略。

建议在真实业务场景下进行下载、上传和并发访问测试，而不是只通过一次测速结果判断网络质量。

三、核对网络监控和故障处理机制

网络质量不仅要能够测量，还应该能够持续监控。

如果企业只能在网络出现问题之后，才发现某条链路已经异常，那么监控系统的实际价值就比较有限。

1. 了解监控系统能够监测什么

企业应该要求供应商明确监控范围。

至少需要关注以下对象：

• 网络设备：网关、路由器、交换设备等。
• 网络链路：链路状态、延迟、丢包率、抖动。
• 访问目标：指定 IP、域名和云端节点。
• 业务系统：ERP、CRM、办公平台等关键应用。

特别需要注意，网关正常不代表业务访问正常。

例如，企业网关可以正常响应 Ping，但访问某个云端系统时仍然可能出现 DNS 解析异常、TCP 连接失败或者应用服务响应超时。

因此，建议选择能够进行分层监控的方案，而不是只监测设备在线状态。

2. 核对告警机制

当网络出现异常时，系统是否能够及时发现并通知相关人员，同样非常重要。

建议了解：

• 是否支持延迟、丢包和抖动告警。
• 是否支持设备离线告警。
• 是否支持自定义告警阈值。
• 是否支持连续异常判定，减少误报。
• 是否支持短信、邮件或其他通知方式。
• 是否能够查看历史告警记录。

企业还可以要求供应商演示一次模拟故障，观察从异常发生到告警通知的完整过程。

3. 了解故障定位和恢复机制

网络故障并不一定发生在设备本身，也可能出现在运营商链路、DNS、路由策略、远端节点或业务服务器。

因此，企业应该了解服务商是否具备完整的故障定位能力。

重点询问：

• 是否能够定位故障发生在哪个网络环节？
• 是否支持主备链路切换？
• 故障检测周期是多少？
• 是否支持自动恢复和切换后的状态检查？
• 是否能够提供故障日志和处理报告？
• 是否有明确的故障升级机制？

尤其需要注意，链路切换成功不代表业务连接一定能够立即恢复。部分应用会受到原有会话状态、连接超时和应用重试机制的影响。

因此，建议通过真实业务测试验证切换效果。

四、评估设备管理、部署方式和兼容性

SD-WAN 不只是网络链路，还涉及设备、控制平台、配置管理和日常运维。

企业在选型时，需要了解供应商的整体技术架构。

1. 设备管理能力

如果企业拥有多个办公地点，逐个登录设备进行配置和维护，会增加运维工作量。

因此，可以重点核对：

• 是否支持统一管理平台。
• 是否支持设备集中监控。
• 是否支持远程配置和策略下发。
• 是否支持设备运行状态查看。
• 是否支持配置备份和恢复。
• 是否支持设备日志查询。
• 是否支持权限分级管理。

对于规模较大的企业，还需要了解是否支持按照区域、部门或业务类型进行设备分组管理。

2. 部署方式

不同企业的网络基础设施并不相同，SD-WAN 的部署方式也需要结合现有环境进行评估。

常见部署方式包括：

• 硬件设备部署：通过专用网络设备实现接入和管理。
• 软件部署：通过虚拟化或软件形式部署相关网络功能。
• 云端管理：由云端平台统一管理网络设备和策略。
• 混合部署：结合本地设备与云端管理平台。

企业需要向供应商确认：

• 是否需要更换现有路由器或网关。
• 是否需要调整现有网络拓扑。
• 是否支持分阶段部署。
• 是否支持远程安装和配置。
• 是否需要现场工程师配合。
• 部署过程中是否会影响现有业务。

3. 兼容性和扩展能力

企业网络通常不是一次性建设完成的，后续可能增加办公地点、云平台、网络设备和业务系统。

因此，需要提前核对：

• 是否支持现有运营商网络接入。
• 是否支持常见网络协议。
• 是否支持 VLAN、DHCP、静态路由等基础网络功能。
• 是否支持与现有防火墙协同工作。
• 是否支持 IPv4 和 IPv6，具体以实际方案为准。
• 是否支持不同品牌和型号的网络设备。
• 是否支持新增分支机构快速接入。
• 是否支持未来带宽和设备规模扩展。

这里需要特别关注兼容性的实际边界。

供应商说支持某种设备，并不代表所有型号、所有固件版本都能够正常协同工作。最好要求对方提供兼容性列表，并在正式部署前进行验证。

五、核对服务响应时间和 SLA 条款

技术指标决定网络方案是否适用，服务条款则决定出现问题之后，企业能获得什么样的支持。

很多企业在选型时容易忽略这一部分，等到网络出现故障，才发现双方对于响应时间、处理责任和服务范围的理解并不一致。

1. 服务响应时间

企业应该要求供应商明确不同级别故障的响应时间。

例如：

• 一般故障：多长时间内响应？
• 重要业务故障：多长时间内安排技术人员处理？
• 核心业务中断：是否提供紧急升级通道？
• 非工作时间：是否有人值守？
• 节假日期间：是否提供技术支持？

需要区分两个概念：

响应时间：服务商收到故障通知后，开始受理并联系客户的时间。

解决时间：从故障受理到业务恢复或问题解决所需要的时间。

两者不能混为一谈。

供应商承诺 15 分钟响应，并不代表 15 分钟内就能修复故障。

2. 服务范围

企业还应该确认供应商究竟负责哪些工作。

建议重点了解：

• 前期网络需求分析。
• 网络方案设计。
• 设备安装和调试。
• 日常网络监控。
• 故障排查与处理。
• 网络策略调整。
• 设备升级和维护。
• 网络扩容和新增节点。
• 定期运行报告。

如果涉及第三方运营商、云平台或企业自有设备，还需要明确不同问题的责任边界。

例如，网络访问异常究竟由服务商负责排查，还是需要企业自行联系运营商？这类问题最好在合同签订之前明确。

3. SLA 服务等级协议

SLA（Service Level Agreement）是服务等级协议，用于约定服务质量、可用性、响应机制和责任范围。

企业不能只看 SLA 中的可用性百分比，还应该关注具体计算方式。

例如：

以上为理论换算值，并不代表供应商实际能够达到这些指标。

签约前还需要确认：

• 可用性的计算对象是什么？
• 统计周期是按月还是按年？
• 故障时间如何计算？
• 计划维护是否计入不可用时间？
• 第三方网络故障是否纳入统计？
• 是否有明确的赔付或服务补偿机制？
• 如何申请 SLA 补偿？
• 是否提供可供核验的运行记录？

尤其要注意，设备在线率、链路可用率和业务系统可用率是不同概念，不能简单地用设备在线率代替业务可用性。

六、企业选择 SD-WAN 服务商的供应商评估清单

前面介绍了需要重点关注的技术指标和服务内容。为了方便企业实际沟通，下面整理了一份可以直接用于供应商询价、技术交流和方案评审的检查清单。

建议企业要求每家供应商按照相同的标准填写，避免不同方案使用不同口径，导致后续无法比较。

1. 技术能力检查表

2. 服务能力检查表

3. 商务和合同检查表

除了技术和服务，还需要了解实际采购成本。

建议核对：

• 设备采购费用。
• 网络接入费用。
• 平台使用费用。
• 部署和调试费用。
• 后续运维费用。
• 带宽升级费用。
• 新增节点费用。
• 合同期限和续费规则。
• 提前终止合同的条件。
• 设备归属及合同结束后的数据处理方式。

不要只比较首次报价，还应该计算整体使用成本（TCO）。

有些方案前期价格较低，但后期设备维护、节点增加和功能升级都需要额外付费，长期成本未必更低。

七、正式签约之前，建议进行一次实际测试

供应商提供的技术参数和方案文档，可以作为初步筛选依据，但不能完全代替实际测试。

对于企业而言，建议在正式采购之前安排一次 POC（Proof of Concept，概念验证）测试。

测试周期可以根据业务复杂度确定，例如安排 7～14 天的试运行。

1. 测试真实业务访问情况

选择企业日常使用频率较高的系统进行测试。

例如：

• ERP 系统。
• CRM 系统。
• 云端办公平台。
• 文件传输平台。
• 视频会议系统。
• 其他关键业务应用。

观察不同办公地点、不同时间段的访问表现，记录延迟、丢包、连接成功率和实际吞吐量。

2. 测试高峰期网络表现

不能只在网络空闲时测试。

建议选择正常工作时间和业务高峰时段分别测试，观察网络质量是否出现明显波动。

如果条件允许，可以模拟多个终端同时访问业务系统，评估并发使用时的实际表现。

3. 测试故障切换

可以在得到供应商和企业运维人员许可的情况下，模拟主链路中断。

重点记录：

• 故障检测时间。
• 切换决策时间。
• 网络恢复时间。
• 业务连接恢复时间。
• 是否需要人工干预。
• 是否产生明显丢包或会话中断。

注意，测试应在可控环境中进行，避免直接对生产业务造成影响。

4. 测试管理和售后服务

除了网络性能，还可以在测试期间验证供应商的服务能力。

例如，提交一次常规技术咨询，观察响应速度；安排一次设备配置调整，了解操作流程；模拟一次告警，检查通知是否及时。

通过这些测试，企业能够更直观地判断供应商的技术能力和服务水平。

八、总结：选择 SD-WAN 服务商，核心是看能否验证

企业选择 SD-WAN 服务商，不能只看宣传资料中的带宽、延迟和功能数量，更不能仅凭报价高低决定。

一套适合企业的方案，至少应该满足几个基本条件：

• 能够根据企业实际业务需求设计网络方案。
• 网络延迟、丢包、抖动和吞吐量等指标可以测量。
• 具备完善的网络监控和故障告警能力。
• 支持设备统一管理和后续扩展。
• 服务响应时间、处理流程和责任边界明确。
• SLA 条款具有明确的计算口径和执行标准。
• 能够通过真实业务测试验证方案效果。

对于企业来说，真正值得选择的服务商，不一定是功能最多或者报价最低的，而是能够把技术指标说清楚、把服务范围写明白，并且愿意通过实际测试证明方案能力的供应商。

选型时多问一句指标怎么测量，多做一次真实业务测试，往往比单纯比较十几页产品介绍更有价值。