阿里云瘫痪时，企业网站和业务系统先做哪几件事

网站打不开、应用报错、后台任务停住，这些是云服务出故障时业务方最先碰到的情况，而且往往只能干等。阿里云如果出现大范围故障，受影响的不只是大平台，大量依赖它的中小企业也会跟着停摆。事故发生前搞清楚故障怎么出现、怎么扩散，才能在下一次来临时少走弯路。

用户眼中的“瘫痪”是什么样子

对业务方来说，阿里云瘫痪通常表现为几种情况：控制台登录不上，云服务器连不上，对象存储读写失败，数据库响应超时，或者域名解析异常。不同服务受影响的程度差别很大。有时只是某个可用区里一部分实例不可用，有时是一个地域里好几个产品同时出问题。

判断范围可以先看阿里云官方的服务健康状态和公告，再对照自家监控。如果只有自己的服务异常，问题多半出在应用或配置上。如果几个互不相关的业务同时异常，就该怀疑底层云服务出了问题。

以下是一个示意场景，不是某家公司的真实事件。

设想一家在线教育公司把课程视频放在对象存储上，用云服务器提供直播和作业提交，数据库用的是云数据库。某天深夜，某个地域的存储服务出现大范围读写失败，视频加载不出来，作业提交接口返回大量错误。

这家公司的系统没有降级方案。作业提交失败后，前端不停重试，重试请求占满了服务器连接数，最后连原本健康的接口也变慢了。运维花了两个小时才确认根源在存储，自己的代码没有问题。事后复盘发现，直接损失是部分学员的作业没能提交，间接损失是家长投诉，以及一周内涌入的退费咨询。

云故障很少只影响一个环节。常见的扩散路径有三条。

依赖链太长。一个用户请求可能依次经过负载均衡、对象存储、缓存、数据库和消息队列。其中任何一环失败，整条链路都会受影响。排查时可以画出每个核心接口的调用链，标出哪些环节没有替代路径。
重试放大流量。客户端和服务端的自动重试如果没有退避间隔和次数上限，一个小故障就会被放大成雪崩。检查 SDK 和网关配置时，重点看重试次数有没有上限。
控制面失效。有时数据面还在运行，但控制台、API 或自动扩容不可用。这时即便人工操作，也没办法及时调整资源。应急预案里要写明，控制台打不开时用什么方式扩容或切换。

弄清这三条路径，才能判断哪些环节必须做隔离。

云服务商保证的是基础设施的稳定性，业务能不能连续运行，还得靠企业自己设计。下面几项投入不大，效果也比较直接。

核心服务至少部署在两个可用区。数据库选择主备或高可用版本，应用服务器分布在不同可用区，再通过负载均衡自动摘除异常节点。单个可用区出问题时，流量可以自动切到另一边。注意这只对单可用区故障有效，整个地域出问题时还需要异地容灾。

关键数据除了本地快照，还要复制到其他地域的存储里。备份存在，不代表能恢复。建议每个季度至少做一次完整恢复演练，记录耗时，并检查权限、配置和软件版本是否匹配。很多团队备份做得很规范，真正恢复时却发现账号权限早已失效。

非核心功能在依赖故障时应能关闭或简化。比如视频播放失败时，页面显示缓存的封面和文字说明；作业提交失败时，把请求写入本地队列，等服务恢复后补发。降级逻辑要在平时就测试，否则故障来了大概率不生效。

每个外部调用都要设置超时时间。重试使用指数退避，并限制最大次数。依赖持续失败时，熔断器可以暂停请求，给下游留出恢复的时间。超时值可以先参考接口的 P99 耗时设定，再根据压测结果微调。

故障发生时，技术团队忙着排查，客服和业务团队需要马上知道对用户怎么说。提前准备好状态页模板、客服话术和升级流程，能省掉很多临时争论的时间。

如果业务正在经历阿里云故障，可以按下面的顺序处理。

阿里云瘫痪造成的损失，很多时候是因为企业没有给故障留出余地。跨可用区部署、备份演练、降级方案和合理的重试策略，都能在平时完成。每次故障之后的复盘，把漏洞变成具体的改进项，下一次就会少一些被动。