事情是这样的,昨天下午三点四十七分，我正在后台跑一组新业务的压测数据，突然——整个控制台像被人掐住了脖子，连续三次刷新都只吐出半个HTML页面，我当时的第一反应不是“服务器挂了”，而是“我是不是又误操作了什么配置”，但紧接着，监控大屏上那个代表可用性的绿色数字，从99.97%直接跳水到82%，我后背就凉了半截。
这种故障,但凡干过运维的都知道，最怕的不是明着宕机，而是半死不活——明明能ping通，但业务就是跑不动；用户那边疯狂报错，你却连故障根因都定位不清楚。
我用的测试环境其实挺朴素,一台本地的MacBook Pro M2，带宽1000M，网线直连核心交换，压测工具是Wrk和Hping3，搭配Prometheus拉实时数据，监听节点包括阿里云上海区、腾讯云广州区、华为云北京区，外加一台自建的小机房物理机作为参照组，测试时间段分别是故障前（15:40）、故障中（16:20）、恢复后（18:10），每个点跑三次取中位数。
昨晚那场史诗级故障，让我差点把服务器从机柜里拽出来
先说最直接的指标：延迟。
故障前,阿里云上海区的ping延迟稳定在6.8ms，华为云北京9.2ms，腾讯云广州10.4ms，故障爆发后，阿里云直接飙升到208ms，注意，这不是稳定值，而是剧烈抖动——有时候能跳到600ms，有时候又突然回落到15ms，腾讯云也受影响，涨到110ms，但抖动幅度小很多，华为云反而稳住了，最高只到36ms，算是三家里最体面的，自建机房那台物理机延迟从0.3ms跳到13ms，因为是同一个交换机的网段，说明故障的冲击波并没有完全隔离干净。
然后是带宽和吞吐。
我用的是一段100MB的静态资源做下载测试,故障前，阿里云上海峰值吞吐能跑到928Mbps，几乎吃满千兆线速，故障中直接砍到34Mbps，连4K视频都播不流畅，腾讯云从910Mbps跌到217Mbps，还能凑合看1080P，华为云从895Mbps降到603Mbps，虽然降了三分之一，但日常办公完全不受影响，恢复后，阿里云花了大概20分钟才慢慢爬回850Mbps，一直没回到基线值。
最要命的是吞吐稳定性。
我拉了一张每秒吞吐的时序图,阿里云在故障期间出现了三次明显的“断崖”——吞吐在10秒内从49Mbps直接归零，然后再弹起来，归零持续了大概4到7秒，这对于实时业务来说是致命的，腾讯云有一次类似的归零，但只持续了2秒，华为云的吞吐曲线虽然也降了，但走势平滑，没有出现过零。
这种差异怎么解释？说句实话，不是技术层面的绝对优劣，而在于容灾架构的隔离粒度，阿里云那套VPC网络的核心路由节点一旦出问题，整个大区内的弹性计算实例会形成“雪崩式重连”，而华为云的那套SDN架构在故障时做了更激进的“流量熔断”，宁可丢一部分非关键探活报文，也要保住核心业务的TCP长连接不断，腾讯云介于两者之间，表现中规中矩。
好了,不吹不黑，说结论。
如果你跑的是延迟敏感型的实时在线业务,比如游戏服务器、金融交易中间件，那这次故障里华为云的“稳”确实有说服力，代价是它们的带宽峰值通常比阿里云低10%到15%，如果你更看重性价比和弹性扩容，阿里云依然是首选，但这次故障给了一个教训——不要把鸡蛋放在同一个可用区里，哪怕只是同城的两个不同地域节点，多部署一组备用实例，成本增加可能不超过15%，但故障时的体验差距是十倍甚至百倍，腾讯云就一个建议：低峰期用，夜间批处理场景完全没问题，但高峰期得预留30%的冗余。
最后再多说一句：国内云厂商从2023年下半年开始，故障频次其实是在下降的，但每一次故障的“影响半径”反而在变大，原因是大家都在推“大底座、大一统”的控制面架构，控制节点越集中，故障时的羊群效应就越猛，所以别指望谁家永不掉线，更务实的做法是：多厂商、多地域、多冗余，再加一个随时能切的手动开关。
昨晚那场故障,我花了四个小时才把业务完全恢复，凌晨三点十五分，我看着监控屏上那个绿色的99.99%重新亮起来的时候，把桌面上那杯已经凉透的咖啡一饮而尽，然后默默打开了一个本子，在上面写了一行字：“下个季度预算，再加一条专线。”
发表评论