双链路冗余到底值不值：第二链路是「救命保险」还是「长期养着的成本中心」？

背景

做了 8 年网络工程，最近一年反复遇到同一个争论：核心出口要不要上双 ISP / 双机房 / 双上联。很多团队的答案是"要"，理由很朴素——单链路就是单点，SRE 教科书里写得很明白。但真正落地时大家会撞上一组很现实的账：第二链路的带宽和专线费用、跨运营商路由策略的复杂度、BGP 邻居与策略的维护、以及最容易被低估的——切换逻辑本身（健康探测、路由收敛、客户端会话保持、DNS 或 Anycast 的联动）几乎是一个独立子系统，它自己的故障面比单链路还大。

常见分歧 / 几种做法

1. 全量双活 + ECMP / Anycast：流量按比例或按权重分摊，任何一条断了自动收敛。收益最高，但成本最高，且 ECMP 下排障复杂度上升（同一条流在不同时刻走不同路径，丢包/乱序归因困难）。
2. 主备 + BGP 优先级（local-preference / AS-path prepending）：平时 100% 走主链路，备链路只养不断电。成本低、逻辑清晰，但备链路长期零流量，等于没有真实负载验证，切换时经常暴露出 NAT 表、ACL、MTU、QoS 等隐藏问题。
3. 应用层多活 + DNS 权重 / GSLB：网络层只做兜底，主要靠应用层调度。灵活，但 DNS TTL 的切换延迟（几十秒到几分钟）对短连接不友好。
4. 干脆不上双链路，靠上层重试和超时兜底：小团队常见，省成本，但把"网络抖动"从"故障"降级成"常态噪声"，P99 永远被尾部拖累。

我的倾向

我个人的倾向是 2 + 定期演练：主备 + BGP 优先级，但每季度做一次真实的切换演练（把主链路主动 down 掉或 prepend 掉，观察收敛时间、会话存活、告警是否触发、回切是否平滑）。原因是：备链路最大的风险不是"它不工作"，而是"它工作过但没人验证过"。演练的成本远低于一次真实故障时发现的隐性问题的修复成本。

但我也承认这个倾向有前提——你的业务对网络抖动的容忍度足够低，且团队有 BGP 排障能力。如果团队里没人真正懂 BGP 属性传递，那上双链路反而比单链路更危险，因为"看起来更稳"会掩盖问题，等出问题的时候反而更难定位。

想听大家怎么选

• 你们团队现在是什么做法？主备 / 全量双活 / 单链路 + 重试？
• 有没有做过切换演练？演练中暴露过哪些"备链路平时发现不了"的问题？
• 备链路长期零流量，你们用什么手段保证它"随时可用"？（健康探测？压测？还是……没有？）
• 小团队（<10 人）有没有必要上双链路，还是应该把钱花在应用层的可观测性上？