每次云服务出现大面积异常，朋友圈和技术群很快就热闹起来。有人刷新控制台，有人盯着状态页，也有人直接搜“阿里云挂了”。对业务方来说，更实际的问题是系统还能不能继续跑，团队知不知道下一步该做什么。谁的责任，等故障过去再说。
云计算已经是很多企业的基础设施。弹性扩容和成本上的好处很明显，但风险也集中到了少数几家服务商身上。承认这一点，才好谈容灾。
故障通常从哪里来
大型云平台的故障，大致可以分成三类。
第一类是底层网络或机房问题，比如光纤中断、供电切换异常，影响某一个可用区。第二类是控制面故障，比如账号认证、API 网关或管理控制台出错。业务服务本身可能没坏，但扩容和发布都做不了。第三类是变更引发的连锁问题。一次配置下发，或者某个依赖服务的升级，就可能让多个产品同时受影响。
两类故障的应对思路不一样。数据面出问题，主要靠多可用区冗余。控制面出问题，就得提前准备一套不依赖控制台也能运行的预案。服务商状态页是重要参考，但团队还需要根据自己的监控判断业务受影响的范围。
几个典型场景
以下案例是行业中常见情形的示例性描述，用来说明思路，并不对应某次具体事件。
场景一：大促前夜的单可用区中断。某团队的订单服务部署在单一可用区，大促前夜该可用区出现网络抖动。数据库只做了同城主从，没有跨地域备份。故障持续约四十分钟，下单失败率明显上升。复盘时发现，团队把“机器多”当成了“高可用”，两者并不是一回事。
场景二：控制台打不开，版本却要发。某 SaaS 公司遇到区域性控制面异常，运维人员登不上控制台，也调不了扩容接口。他们没有提前准备基于基础设施即代码的部署流水线，紧急修复只能逐台登录机器操作，速度很慢。
场景三：被忽略的依赖链。某内容平台自身服务运行正常，但对象存储所在区域出了问题，图片全部加载失败。团队之前只盯着计算资源，没有梳理存储、域名解析、短信验证码这些外部依赖。故障从后台一路传到了用户侧。这类依赖在日常里不显眼，平时也不一定触发告警，所以更需要定期盘点。
提前能做的几件事
故障没法完全避免，但损失可以压住。下面几件事，做起来并不复杂。
- 列出依赖清单：计算、存储、数据库、消息队列、域名、第三方接口都写下来，标出哪些是单点。新接入的服务也要及时补进去。
- 关键数据做跨地域备份，并且演练恢复：备份文件存在，不代表能恢复。定期完整跑一次恢复流程，记录耗时和遇到的问题。
- 准备降级方案：比如静态页面兜底、只读模式、临时关闭推荐和评论等非核心功能，保住下单、登录这类主流程。降级开关要提前写好，并在演练中验证过。
- 把部署写成代码：配置和发布流程放进版本库。出问题时，才能在其他地域甚至其他云上重建环境，而不是靠记忆逐台修改。
- 定好沟通分工：谁对外发布状态，谁和服务商对接工单，用户通知模板存放在哪里。这些事如果等出了问题再想，很容易乱成一团。
如果时间有限，先做依赖清单和降级方案。前者让你知道哪里会断，后者让断掉的时候主流程还能走。两件事都不需要额外买资源，主要花的是团队的时间。
多云和混合部署怎么看
不少团队经历一次故障后，会考虑多云。这个方向有价值，但不必一步到位。多云会带来学习成本、网络成本和运维复杂度。业务规模不大时，先把同一家云的跨可用区、跨地域容灾做扎实，通常更划算。只有核心业务对可用性要求很高，团队也有足够的工程能力，才值得把第二家云当作热备或冷备来用。
故障之后怎么复盘
“阿里云挂了”这类事件过去之后，复盘比抱怨更有用。记录故障时间线、影响范围和团队的响应过程，再看哪些预案真正起了作用，哪些没起作用。把结论落成具体的改进项，每一项配上负责人和截止时间。下次故障来临时，团队就能照着已经验证过的流程走。
云服务的稳定性由服务商和使用方共同负责。使用方能直接控制的是架构设计、备份策略和应急响应。这几件事做扎实，外部波动造成的冲击会小得多。
