阿里云网站打不开

2024年3月14日下午两点半左右，阿里我正准备登录阿里云控制台续费一台ECS实例，云网浏览器却一直转圈，站打最后弹出“无法访问此网站”。不开刷新了五次，阿里换了Chrome和Edge，云网结果一样。站打第一反应是不开本地网络问题，但微信里已经有同行在群里发截图——阿里云官网、阿里控制台、云网甚至部分API接口全都挂了。站打这不是不开我一个人的事。

紧接着我试了阿里云APP，阿里同样卡在启动页。云网用手机4G流量访问，站打依然打不开。这说明问题不在用户端，而是阿里云自身的服务出了故障。大概过了十分钟，微博上“阿里云崩了”的话题已经冲上热搜。有人贴出ping阿里云官网域名的结果，延迟正常，但HTTP请求返回502。这种“能通但打不开”的状态，通常指向负载均衡或网关层故障。

我手头有几个客户的小程序后端跑在阿里云函数计算上。故障期间，他们的用户端开始报错，订单提交失败。一个做电商的客户直接打电话过来，语气很急。我让他先切到备用服务器——幸好之前建议他做了多云部署。这不是什么高深策略，就是被逼出来的习惯。2022年那会儿阿里云香港节点出过一次事故，之后我就再不敢把鸡蛋全放一个篮子里。

大约下午三点十分，阿里云官方状态页更新了一条公告，说“部分地域控制台及API服务异常”，正在紧急处理。措辞很克制，没提具体原因。但圈内人都在猜，有人说是华东1可用区的核心交换机挂了，也有人说是内部运维变更导致配置错误。官方后来发布的复盘报告证实了第二种说法：一次自动化运维操作触发了未预期的连锁反应，把多个核心服务的路由配置冲掉了。说白了，就是自己人把自己人干翻了。

这次故障持续了将近两个小时。恢复过程也不是一键重启那么简单。先是控制台能登录了，但创建资源仍然报错；然后API逐渐恢复；最后是部分地域的OSS和CDN回源异常。这种“逐步恢复”比彻底宕机更折磨人——你永远不知道下一个操作会不会又踩到雷。我那个电商客户在四点左右终于能正常下单了，但已经丢了大概四十多单。他后来问我能不能索赔，我查了阿里云的SLA条款，赔付上限是月度服务费的10%，算下来不到两百块。他苦笑了一声，没再说话。

事后我翻了一些技术论坛的讨论。有个观点挺有意思：阿里云这几年疯狂推“云原生”“Serverless”，底层架构越来越复杂，但运维工具链的健壮性没跟上。这次出问题的自动化运维系统，据说就是内部用来批量管理网络设备的。一个操作失误能穿透多层防护，说明“爆炸半径”控制得并不好。这不是阿里云一家的问题，但作为国内市场份额最大的云厂商，它的故障影响面太广了。那天下午，半个互联网圈都在等它恢复。

我自己的教训是：别迷信“高可用”这个词。再大的云厂商，也可能因为一行配置错误让你业务停摆。多云备份、本地降级方案、关键业务的手动切换流程——这些东西平时看着冗余，出事时就是救命稻草。那天晚上我把所有客户的架构图重新过了一遍，又加了两条监控规则。不是不信任阿里云，是不信任任何单一依赖。

现在再打开阿里云官网，一切正常。但那个下午的502页面，我截了图存在手机里。偶尔翻到，提醒自己：云上的日子，也得留把伞。