在过去的几周里，GitHub 经历了多次宕机事件，导致平台的服务降级，影响了许多用户的正常使用。GitHub 团队在解决问题的同时，近日也分享了这些事件的详细情况。

 

根据 GitHub 的 Keith Ballinger 的说法，潜在的主题是其mysql1集群中的资源争用，这导致在高峰负载期间事情发生翻倒。

 

第一次中断发生在 3 月 16 日，由于该公司的数据库代理技术达到了最大连接数，几乎所有的写入操作都停止了。峰值负载和不确定的查询性能的结合使事情脱离了轨道，直到 GitHub 能够故障转移到健康的副本，而团队试图找出问题所在。

 

没等多久。24 小时后重新开始装载（我们建议是美国在欧洲工作日中途醒来），事情再次开始摇摆不定。然而，这一次，该团伙认为他们走在了前面，并在事情失控之前按下了红色的大故障转移按钮。

 

这引发了一系列新的问题，再次导致连接问题。然而，好消息是，团队确定了负载模式并弹出了一个索引来解决主要的性能问题。

 

这是太多 DBA 熟悉的解决方案。有性能问题吗？用索引喷洒数据库，直到它消失。并不是说这位作家曾经做过这样的事情。

 

GitHub 承认“我们对缓解措施并不完全有信心”，果然，在启用内存分析以更好地了解正在发生的事情后，该服务于 3 月 22 日再次开始摇摆不定。再次，客户端连接mysql1开始失败，并且再次需要主故障转移才能恢复。

 

3 月 23 日，情况同时恶化，需要再次进行故障转移。这一次，GitHub 选择限制 webhook 流量，“作为一种缓解措施，以防止未来在峰值负载时间再次发生”，但调查仍在进行中。

 

这就是问题所在。

 

虽然 GitHub 在解释其失败方面的透明度值得称赞，但这些失败仍在继续发生并且公司似乎不太清楚如何解决这些失败的事实令人担忧。“我们已经开始在高峰时段对这个特定数据库的负载模式进行审计，”它说，同时还承诺将流量分流到其他地方，加快故障转移时间并审查其变更管理程序。

随着负载的增加，扩展基础设施和加强监控的承诺都很好，但是Reg读者可能无法摆脱这样的感觉，即简单地将资源投入到问题上并不能解决导致中断的潜在问题。

 

尽管如此，似乎 GitHub 也没有选择这次使用不受欢迎的类似社交媒体的算法提要来疏远其大量客户群。