将企业电话系统迁移到 Teams Phone 之后,最重要的问题不再是“能不能打电话”,而是“电话什么时候会断”。传统的 PBX 系统虽然功能单一,但在可靠性上有着几十年的积累——即使断电,备用电池也能撑几个小时。Teams Phone 依赖互联网和云端服务,一旦网络中断或 SBC 故障,整个公司的对外通信可能瘫痪。

直接路由高可用:为什么需要冗余
电话系统对可用性的要求
企业电话系统通常要求 99.999% 的可用性(即每年停机时间不超过 5 分钟)。Teams Phone 本身作为云服务,微软承诺了高可用性 SLA。但直接路由架构中还有一个关键的自建组件——会话边界控制器(SBC)。SBC 负责将 Teams 云端与运营商的 PSTN 网络连接起来。如果 SBC 出现故障(硬件损坏、软件崩溃、电源故障),所有通过该 SBC 路由的通话都会中断。
直接路由架构中的单点故障
在一个最基本的直接路由部署中,只有一个 SBC 连接到一个运营商的中继。这是典型的单点故障。当这个 SBC 宕机时,员工无法拨打外线电话,外部客户也无法打入。更隐蔽的问题是:即使 SBC 本身正常运行,如果上行链路(连接 SBC 到运营商的光纤)被切断,通话同样中断。
2026 年直接路由的核心更新
微软在 2026 年持续加强对直接路由高可用性的支持。SBC 与 Teams Phone 系统的集成不断深化,微软认证的 SBC 供应商列表也在持续更新。管理员可以通过 Teams 管理中心配置多个 SBC,并为每个用户分配主用和备用 SBC,实现自动故障转移。
SBC 冗余部署方案
主备模式(Active-Standby)
主备模式是最常见的 SBC 高可用部署方式。部署两台 SBC,一台处于活跃状态处理所有通话,另一台处于待机状态,通过心跳信号监控主 SBC 的状态。当主 SBC 故障时,备用 SBC 自动接管。主备模式的恢复时间通常在 30 秒到 2 分钟之间。实现主备模式需要在两个 SBC 之间配置 VRRP(虚拟路由冗余协议)或使用云负载均衡器。
双活模式(Active-Active)
双活模式将通话负载分布在两台或多台 SBC 上,同时提供冗余和高吞吐量。当一台 SBC 故障时,剩余 SBC 继续处理所有通话。双活模式的优势是故障切换几乎无感知(因为故障 SBC 上的通话会中断,但新的通话可以路由到健康 SBC)。配置双活模式需要在 Teams 中为同一个用户分配多个 SBC,或使用 DNS 轮询和负载均衡器。
地理冗余(跨区域部署)
对于对可用性要求极高的企业,建议将 SBC 部署在不同的地理区域(如两个不同的数据中心,或一个本地机房加一个云端)。这样即使某个区域发生大规模故障(如自然灾害、区域网络中断),另一个区域的 SBC 仍然可以提供服务。地理冗余的挑战在于:需要确保两个区域都能连接到同一个 Teams 租户,且电话号码可以在区域之间转移。
云端 SBC 作为备份
如果不想维护两台物理 SBC,可以考虑将一台 SBC 部署在云端(如 Azure 虚拟机中),作为本地 SBC 的备份。当本地 SBC 故障时,通话自动切换到云端 SBC。云端 SBC 不需要专用硬件,按使用量付费,适合中小型企业。
运营商链路冗余

双运营商接入
SBC 本身再可靠,如果上游的运营商线路断了,电话还是打不出去。建议从两个不同的运营商(如中国电信和中国联通)各购买一条 SIP trunk,连接到同一个 SBC(如果 SBC 支持多个 trunk)或分别连接到两台 SBC。当一条线路故障时,系统自动切换到另一条线路。
本地环路与 4G/5G 备份
对于高度依赖电话业务的企业,可以考虑在本地部署一个 4G/5G 网关,作为宽带线路的备份。当主宽带线路中断时,SBC 自动通过 4G/5G 网络连接到运营商。4G/5G 备份的带宽可能不足以支持大量并发通话,但对于保持关键通话畅通已经足够。
Teams Phone 对媒体绕过的支持
Teams Phone 的媒体绕过功能允许 SBC 与 Teams 客户端直接交换媒体流,而不经过 Teams 云端。这可以减少延迟,但也增加了对本地网络可靠性的依赖。在高可用部署中,建议谨慎使用媒体绕过——如果本地网络不稳定,媒体绕过反而会放大问题。
网络与电源冗余
网络设备冗余
SBC 需要连接到网络。建议为 SBC 配置双网卡,连接到两台不同的交换机。即使一台交换机故障,SBC 仍然可以通过另一台交换机通信。对于路由器和防火墙,同样建议采用双设备冗余部署。
不间断电源(UPS)
本地 SBC 需要稳定的电源供应。建议为 SBC 及相关的网络设备配置 UPS,至少提供 30 分钟的备用电力。如果企业所在的地区电力不稳定,可以考虑配置发电机或使用云端 SBC 作为备份。
监控与告警
高可用不等于“免维护”。需要建立对 SBC、运营商链路和网络设备的监控体系。关键指标包括:SBC 的 CPU 和内存使用率、SIP trunk 的注册状态、通话质量指标(延迟、丢包率)、以及故障切换事件。当检测到异常时,系统应自动发送告警到 IT 运维团队的 Teams 频道。
灾难恢复与定期测试

故障切换测试计划
高可用配置只有在实际故障发生时才能验证其有效性。建议每季度执行一次故障切换测试:模拟主 SBC 故障,观察备用 SBC 是否自动接管;模拟主运营商线路中断,观察通话是否切换到备用线路。测试应在非工作时间进行,并记录切换时间和恢复步骤。
Teams 管理中心中的故障排查工具
Teams 管理中心提供了通话质量仪表板和问题排查工具。管理员可以查看每个通话的详细媒体路径,快速定位问题出在 SBC、网络还是 Teams 云端。2026 年的更新中,这些工具得到了进一步增强,支持更精细的故障分析和建议。
灾难恢复文档
高可用架构可以处理单一组件故障,但无法应对大规模灾难(如数据中心被摧毁)。企业应制定书面的灾难恢复计划,明确:当主站点完全不可用时,备用站点如何接管;电话号码如何在站点之间转移;灾难恢复的 RTO(恢复时间目标)和 RPO(恢复点目标)分别是多少。计划应每年演练一次。
与运营商的协调
故障切换不仅涉及技术配置,还涉及运营商的配合。在与运营商签订 SLA 时,明确故障响应时间、备份线路的切换机制、以及紧急情况下的联系人。在切换运营商线路时,需要确保两个运营商的号码可以互相转接,避免客户拨打旧号码时无人接听。
Teams直接路由中的 SBC 必须使用物理设备吗?
Teams 如何验证主备 SBC 的故障切换是否正常工作?
Teams 地理冗余部署中,电话号码如何在不同区域间转移?