摘要
2026 年 2 月 19 日 23:30 UTC 至 2 月 20 日 01:00 UTC，PagerDuty 发生主要事件，导致通过 Events API 的事件摄入降级；2 月 20 日 16:58–17:47 UTC 又出现入站邮件事件处理降级。根因是一次本应只升级「数据库负载均衡器」的 HAProxy 配置变更，因基础设施代码库中模块间未知依赖，被应用到全部服务器，新版本与大量负载均衡器不兼容，内部服务间 API 通信受阻，事件处理延迟。
时间线
2026-02-19 11:50 UTC对基础设施代码库提交 HAProxy 升级变更，意图范围仅限数据库负载均衡器
2026-02-19 事中因模块依赖，变更应用到全部服务器，LB 软件升级到不兼容版本
2026-02-19 23:30 UTCEvents API 事件摄入出现降级（主要事件开始）
2026-02-20 01:00 UTC通过降级/升级部分 LB 软件恢复
2026-02-20 16:58 UTC入站邮件事件处理再现降级
2026-02-20 17:47 UTC邮件事件处理恢复
根因
PagerDuty 用 HAProxy 同时作负载均衡器与本地代理，其配置由基础设施代码库管理。2 月 19 日提交的变更意图仅升级数据库负载均衡器子集，但因代码库中模块间此前未知的依赖关系，该配置变更被应用到基础设施中的所有服务器，超出预期范围。新版本负载均衡器软件与大量现有 LB 不兼容，表现为内部服务无法通过各自 API 成功互访，进而导致事件处理延迟。部分 LB 故障立即显现，其余在进程重载时才暴露。
放大因素
- 基础设施代码库模块间隐藏依赖，使「局部变更」自动扩散为「全局变更」
- 配置部署缺少针对版本不兼容的显式校验，变更不会因不兼容而失败
- 软件版本未严格固定（pinning），存在非预期升级/版本漂移
缓解措施
- 修正基础设施代码库的依赖链，避免同类情况再现
- 配置部署增加校验，遇到此类不兼容时显式失败
- 在配置管理中加入更显式的软件版本固定，避免非预期升级
- 对受影响的负载均衡器逐台降级或升级至兼容版本恢复
经验教训
- 基础设施即代码（IaC）的模块依赖是隐形炸弹：一处「小范围」变更可能因依赖扩散成全局事故
- 配置变更必须带版本兼容校验与显式失败，而非静默应用
- 负载均衡器/代理的版本需严格 pin，禁止非预期漂移
检查清单
- IaC 模块间是否存在隐藏依赖，变更范围是否会被自动放大
- 配置部署是否在版本不兼容时显式失败
- 关键组件软件版本是否固定（pinning）
- 负载均衡器变更是否先在隔离子集灰度
- 是否具备逐台回滚/升级的恢复路径