4月份，我们经历了四起事件，导致GitHub服务的性能下降。
4月5日08:11 UTC（持续47分钟）
4月5日，UTC时间8:11至8:58，多个GitHub服务出现问题。Web请求错误率最高为6%，API请求错误率也最高为10%，超过100000个GitHub Actions工作流未能启动。根本原因是数据库负载平衡器发生了更改，导致我们三个数据中心之一的多个关键数据库连接失败。我们通过回滚更改解决了该事件，并实施了新措施，以在部署管道的早期检测类似问题，从而最大限度地减少用户对未来的影响。
4月10日08:18 UTC（持续120分钟）
4月10日，在UTC时间8:18到9:38之间，由于无边界查询导致主数据库实例过载，一些服务的错误率增加。为了减轻影响，我们扩展了实例，并提供了一个改进的查询版本，以针对读取的副本运行。该事件导致基于web的存储库文件编辑失败率为17%，其他存储库管理操作的失败率介于1.5%和8%之间。发布和拉入请求创作也受到了严重影响，正在进行工作以消除对受影响数据库主数据库的依赖性。由于授权存储库访问时依赖受影响的主数据库，GitHub搜索的失败率为5%。
4月10日08:18 UTC（持续30分钟）
4月10日，UTC时间18:33至19:03，由于计算密集型数据库查询阻止了关键数据库集群提供其他查询，导致多个服务降级。由于对该集群数据的严重依赖，影响广泛。GitHub Actions经历了延迟和失败，GitHup API请求有大量超时，事件期间的所有GitHub Pages部署都失败，Git Systems看到部分原始文件和存储库存档下载请求的HTTP 50X错误代码。GitHub Issues的创建和更新延迟也增加了，GitHub代码空间的创建和恢复代码空间的请求超时。通过回滚违规查询，事件得到缓解。我们有一种在CI测试中检测类似计算密集型查询的机制，但在该覆盖范围中发现了一个差距，并已解决了这一问题，以防止将来出现类似问题。此外，我们对各种服务进行了改进，使其更能适应这种依赖性，并检测和停止具有类似回归的部署。
4月11日08:18 UTC（持续3天4小时23分钟）
4月11日至4月14日，GitHub.com在发送电子邮件时出现了严重延迟（最多两个小时），特别是对于密码重置和未识别设备验证等时间敏感的电子邮件。没有2FA的用户尝试登录到无法识别的设备时无法完成设备验证，并且尝试重置密码的用户无法完成重置。延迟的原因是共享资源池的使用量增加，以及一个单独的内部作业队列变得不健康，导致邮件队列无法处理。已立即进行改进，以更好地检测和应对未来的类似情况，包括对时间敏感的电子邮件具有排队旁路功能，并更新了异常电子邮件发送的检测方法。已暂停不正常的作业队列，以防止影响使用共享资源的其他队列。
请遵循我们的状态页实时更新状态变化和事故后总结。要了解有关我们正在进行的工作的更多信息，请查看GitHub工程博客.
