摘要
2026-06-10，Google 生成式 AI 服务 Gemini 发生约 7 小时全球大范围不可用。自美国太平洋时间 03:26 起，网页版、移动 App 与 Chrome 插件版用户提交 prompt 全部失败，持续报错 1076 / 1099。影响从美英扩散至欧洲、亚洲至少 9 国，Gemini Flash / Pro 受影响最重，峰值 prompt 失败率约 50%。Google 事后将根本原因归于后端数据库性能问题；第三方事故复盘进一步定位为数据库热点（hotspotting）与过短缓存 TTL 的叠加放大。
时间线
03:26 PT - Gemini 全球开始报错，用户提交 prompt 失败，Error 1076 / 1099 横扫多国
高峰 - prompt 失败率峰值约 50%；后端数据库失败率升至 60%，数据库调用量上涨超 10×
期间 - Google Workspace 状态页初期仍显示正常（监控滞后），后升级为 Major Disruption
09:24 PT - Google 确认缓解措施推进中，无 ETA
10:30 PT - Google 宣布问题解除（持续约 7 小时）
根因
前端流量上涨冲击本已高负载的后端数据库服务。两个设计缺陷叠加： 1. 数据库索引设计缺陷，把工具部署元数据（tool-deployment metadata）集中到少数数据库分片，形成热点（hotspotting），读压力极度不均。 2. 缓存 TTL 仅 1 分钟，迫使客户端/中间层频繁回源刷新，放大了对热点分片的读取争用。 二者合力把一次普通的流量上涨放大为数据库读争用雪崩，数据库调用量涨超 10×，失败率升至 60%。
放大因素
- 流量突发：前端流量上涨是直接导火索。
- 模型集中度：承载大部分消费级流量的 Gemini Flash / Pro 共用同一后端处理路径，Flash Lite 因路径不同仅部分受损，进一步印证问题在特定后端路径。
- 监控滞后：故障初期 Google 自家状态仪表盘仍显示绿色"正常"，真实用户报错已数千，拉长了发现到响应的时延。
缓解措施
- Google 工程团队通过优化后端数据库负载分布（load distribution）缓解，恢复服务。
- 事后需针对热点分片做索引/分片重构，并重新评估缓存 TTL 取值，避免 1 分钟级强制回源。
经验教训
- 索引/分片设计要规避元数据热点；单点分片一旦成为热点即放大为全局故障。
- 缓存 TTL 不是越短越安全：过短 TTL 在高负载下反而制造回源风暴。
- 容量评估不能只看均值，要按分片峰值与故障放大系数（10× 调用量）预留余量。
- 状态页监控须与真实用户面信号对齐，避免"绿灯宕机"误导响应。
检查清单
- 数据库索引是否把高频元数据集中到少数分片？
- 缓存 TTL 在峰值流量下的回源频率是否可控？
- 是否按分片峰值 + 放大系数预留数据库容量？
- 状态页/监控是否与真实用户报错信号对齐？
- 关键模型流量是否做了后端路径隔离与降级？