最后更新: 2025-12-16, 作者: 官方小编
近几年，随着移动互联网，企业数字化转型等浪潮发展，IT 基础设施资源呈现规模化，集中化特点。全球云市场前三名占据超过60%的份额，这种格局源于成本效益和规模经济，但也意味着任何一家云厂商的软件错误或配置失误均能波及数百万企业和用户。此外，提供互联网服务的科技公司，一次故障对社会影响同样不能小觑。在全球化，企业出海背景下，IT 基础设施的稳定性愈发重要。
全球性故障案例
| 故障名称 | 原因 | 影响 | 改进措施 | 网页链接 |
|---|---|---|---|---|
| 2025-12-05 Cloudflare 解析逻辑故障 | 为修复React 漏洞进行主体解析逻辑变更引发 Lua 异常 | 25分钟中断，影响28% HTTP 流量，导致HTTP 500错误 | 增强 rollout 验证，fail-open 处理 | 参考链接 |
| 2025-11-18 Cloudflare 数据库权限故障 | ClickHouse 数据库权限变更导致文件超大 | 中断超6小时。全球网站大面积故障，影响 X、OpenAI、Spotify、Shopify、Canva、Zoom 等。 | 配置文件验证强化 | 参考链接 |
| 2025-10-20 AWS DynamoDB DNS 故障 | DynamoDB DNS 管理竞争条件 | 中断超15小时。AWS 142 项服务受影响，例如 DynamoDB、EC2、Lambda 等。全球超1000家企业受影响，例如 Snapchat、Venmo、Canva、Fortnite、Roblox、Reddit、Disney+等。 | 多阶段恢复。避免循环依赖。避免中心化单点故障。 | 参考链接 |
| 2025-06-12 Google Cloud | 异常配置导致的全球性服务宕机。 | 中断超6小时。故障最初影响了 Google Cloud Platform 多个产品，Gmail、Google Search、Google Drive 等核心服务。影响企业 Spotify、Discord、OpenAI、Twitch、GitHub等。 | 无效数据预防。重启熔断。全局传播故障隔离。 | 参考链接 |
| 2024-04-08 腾讯云 API 故障 | API 升级接口不兼容导致的配置数据错误，并扩展全网。 | 所有地区控制平面中断，影响COS等核心服务 | 前向兼容性，渐进式 灰度，增强系统韧性。 | 参考链接 |
| 2023-11-27 滴滴机房故障 | K8S 版本升级导致机房容器重建。 | 中断超12小时，影响滴滴核心出行业务。 | 上线规范化管理。 | 参考链接 |
| 2023-10-04 Cloudflare DNSSEC 故障 | DNSSEC 签名过期 | 4小时中断，影响1.1.1.1 DNS解析器、WARP、Zero Trust | 测试自动化，失效安全机制 | 参考链接 |
| 2022-12-20 阿里云 香港故障 | 制冷机组故障 | 24小时中断，影响服务 ECS、云数据库、存储产品、云网络产品（全球加速、NAT网关、VPN网关等）等云产品使用。300+企业，损失数亿美元。 | 服务架构冗余设计。 | 参考链接 |
| 2022-08 Google 数据中心火灾 | 电气事件引发火灾 | 影响地图和搜索服务，Council Bluffs数据中心，三名员工受伤 | 电气系统隔离，火灾抑制自动化 | 参考链接 |
| 2022-07 Google 数据中心热相关故障 | 极端高温导致冷却系统失败 | 伦敦中断，影响Google和Oracle数据中心，网站下线 | 冷却系统冗余，热阈值监控 | 参考链接 |
我们学到了什么
架构模式将大规模分布式系统（云计算、容器编排）分为控制面和数据面。控制面主要负责系统的管理和决策，例如配置、调度、监控、策略和状态管理等。数据面则负责执行实际的负载任务。从历年的故障可以看出往往是控制面的变更导致了数据面的规模性故障。最直观的经验如下：
- 至少70%的故障由变更引起。《SRE Workbook: Google’s Infrastructure》
- 控制面变更，尤其无灰度策略的快速全局传播的配置变更，会导致不可控的全局性故障。
总结哪些经验：
- 变更原则：所有线上变更都需要提供灰度、回滚方案。所有变更要在沙箱环境验证并引入自动熔断机制。
- 监控告警：要针对灰度功能配置告警策略及时感知故障。
- 快速止损：故障发生时，要先止损（回滚/降级/限流/扩容），再排查潜在风险，给出短期方案（SOP，故障自愈等），最后根据根因给出长期解决方案。
- 紧急访问：分布式系统控制平面要在高负载状态下提供优先访问机制，确保高优资源先恢复。
- 快速恢复：故障必然会引起大量的重试请求。面对请求洪峰，除了限流措施，要引入缓存/冷备资源，确保峰值负载下扩容（想想那些在恢复过程中被打爆的组件）。
- 故障注入与演练：定期模拟故障，注入错误配置、过载或依赖失效。
- 风险梳理与防腐化：随着系统迭代，预案/监控易熵增，定期排查潜在风险，验证预案有效性。
- 复盘机制：每起故障必复盘，分析根因、影响、预防。稳定性周会/月会，拉齐认知。
我们应该怎么做
- 业务：虽然云厂商承诺了很多SLA，但多云，多区域用云依然是最优选择。
- 研发：要构建稳健的系统：https://mp.weixin.qq.com/s/wAuGjIYNl0c3sY57yq0GBw
- SRE：监控，灰度，响应，止损，恢复。故障可以减少但无法避免，快速发现，快速隔离，快速恢复才是必杀技。
- 用 HUATUO（华佗）发现，解决潜在的可能性系统风险：https://github.com/ccfos/huatuo
篇尾：
- 关注微信公众号【HUATUO 开源技术】留言，或扫码添加工作人员微信，邀请您加入用户群（请备注姓名+单位）：
- 代码仓库：https://github.com/ccfos/huatuo
- 官方网站：https://huatuo.tech/