H1：PagerDuty 于 2025 年 8 月 28 日遭遇重大故障

• 事件概况：作为数千家组织用于系统问题警报的事件管理平台，PagerDuty 自身在 2025 年 8 月 28 日出现故障。公司在全面的故障报告中详细说明了问题范围、客户影响以及防止再次发生的措施。
• 受影响区域及时间：该事件扰乱或延迟了 PagerDuty 美国服务区域客户的传入事件处理，严重的服务降级持续了 9 个多小时。高峰时，约 95%的事件在 38 分钟内被拒绝，18%的创建请求在 130 分钟内产生错误。
• 故障原因：是正在推出的一个新功能中的一个 bug，旨在改进 API 和密钥使用的审计和日志记录。随着增量部署的进行，PagerDuty 的 Kafka 集群上的使用错误地增长超过了系统容量，由于上述功能中的逻辑错误，为每个 API 请求实例化了一个新的 Kafka 生产者，而不是使用单个 Kafka 生产者生成消息。报告解释了 PagerDuty 对如何使用 pekko-connectors-kafka Scala 库的解释导致了此编码错误，Kafka 最终每小时跟踪近 420 万额外的生产者，是典型新生产者数量的 84 倍，导致 Kafka 开始崩溃并耗尽可用的 JVM 堆，引发集群级联故障。
• 连锁反应及影响：导致其他依赖 Kafka 进行通信的服务出现连锁反应，无法连接到 Kafka 集群，增加了故障影响和恢复时间。公司承认级联故障难以预测，一个服务中的小问题可能会以系统图不明显的方式波及其他服务。
• 外部沟通延迟：影响到了外部沟通，PagerDuty 员工起草的更新未出现在公共状态页面上，导致客户更加困惑。
• 其他类似事件：PagerDuty 不是近期唯一遭受长时间故障的事件管理平台，Opsgenie 客户在 2022 年曾经历 14 天的故障。
• 社区反应：凸显了可靠事件管理系统对现代组织的重要性，用户提出添加冗余等建议，如始终有备用警报系统，监控工具本身也需要监控等。
• 未来改进措施：PagerDuty 列出了未来的改进和承诺，包括扩大自身监控，特别是在 JVM 和 Kafka 级别，实施更严格的变更管理措施，以确保工程师既能快速工作又能增加安全性。社区反应也验证了所有组织确保自身系统和流程有弹性的必要性。