凌晨三点，用户投诉APP打不开，监控显示某核心API响应时间飙升到8秒——运维刚切走流量，SRE同事已经登录跳板机，在5分钟内定位到是BGP路由震荡引发的跨机房链路抖动。这不是电影桥段，而是真实发生的高可用保卫战。
高可用不是靠堆机器，是靠“可观察+可干预”
很多团队以为加个负载均衡、配个双活就叫高可用。实际在路由层面，一次错误的静态路由通告、一个没收敛的OSPF区域、甚至一条被误删的ECMP路径，都可能让99.99%的SLA瞬间归零。SRE不只写脚本，更得懂BGP的local-preference怎么调，明白eBGP邻居为什么突然断连。
把路由当服务来治理
在我们调优过的电商后台中，SRE推动将BGP策略从“网络组手工配置”改为“GitOps驱动”。所有路由策略变更必须提交PR，自动触发Calico或FRR的配置校验与灰度发布。比如这条策略：
route-map OUTBOUND-TO-ISP1 permit 10\n match as-path 100\n set local-preference 200\n set community 65001:100每次合并前，CI会模拟路由反射器行为，验证是否会导致某条关键路径被意外屏蔽。上线后，Prometheus拉取FRR的bgpPeerState指标，一旦neighborState != 6（Established），立刻触发告警并回滚。
用真实延迟代替理论带宽
别再只看“链路带宽利用率＜40%”就放心。我们在CDN边缘节点上部署了轻量级探针，每10秒向源站发起ICMP+TCP SYN探测，把结果打标为region=sh,provider=ct,rtt_ms=32。SRE用这些数据动态调整BGP的MED值：上海电信线路RTT连续3次＞50ms，就自动抬高MED，让流量绕行江苏联通节点。这比死守“主备路由”的老办法，故障恢复快了6倍。
故障时，先保通，再查因
去年双十一前压测，发现某IDC出口路由器CPU突增至98%，BGP路由表同步卡住。SRE没等厂商补丁，直接启用预埋的“逃生路由”：通过Linux内核的ip rule + ip route，在应用层快速注入/32主机路由，把异常IP段流量强制导向备用出口。整个过程37秒，用户无感知。事后复盘，真正救命的不是多牛的分析能力，而是那条早就写好、测试过、权限放开的ip route add 10.23.45.67/32 via 192.168.10.1 dev eth1。