summary
2025-02-26 约 06:45 PST 起，Slack 因一次数据库系统的维护操作叠加其缓存系统的潜在缺陷，导致数据库负载过高，约半数依赖该数据库的实例不可用，发送/接收消息、工作流、登录、API 等大面积异常；为缓解主故障而采取的 Events API 队列暂停又造成二级事件。
timeline
06:45 PST 主故障开始；工程通过限流/修复数据库分片逐步恢复，主故障约在当日晚间缓解；但为缓解主故障而暂停的 Events API 队列积压，直至 2-26 23:27 PST 重新启用队列，Events API 相关与 Slack Connect @提及问题延至 2-27 08:30 PST 才完全解决。
root_cause
数据库维护动作触发了缓存系统的潜在缺陷，二者叠加使大量请求直冲数据库、负载飙升，半数实例不可用。二级事件则是缓解措施本身：暂停 Events API 队列并在恢复后才重放，导致集成/机器人事件积压。
amplifiers
① 维护+潜缺陷叠加放大故障。② 半数数据库实例不可用，影响极广。③ 缓解措施（暂停 Events API）引入二级事件，事件未重放造成集成不一致。④ 恢复窗口跨两个工作日。
mitigation
稳定并修复数据库层、重放/重建 Events API 队列；后续改进缓存缺陷修复、数据库维护的安全性与 Events API 的优雅降级（而非丢弃积压）。
lessons
数据库维护须规避触发潜在缺陷的路径；缓解措施本身要评估二级影响，事件队列应可安全重放而非简单丢弃；关键功能（消息/登录/API）需独立降级。
checklist
① 数据库维护前做缺陷/兼容评估。② 缓存系统修复潜在缺陷并加容量护栏。③ 缓解措施评估二级影响，事件可重放。④ 关键功能独立降级与监控。