GitHub服务中断24小时11分钟事故分析报告(2)

发布时间：2018-11-03 20:58 所属栏目：117 来源：高效开发运维

导读：所有主数据库在东海岸再次建立。由于写入内容现在被引到与我们的应用层在同一物理数据中心的数据库服务器，这导致网站响应极其缓慢。仍有众多数据库读取副本比主数据库延迟几小时，因而导致用户看到不一致的数据。

所有主数据库在东海岸再次建立。由于写入内容现在被引到与我们的应用层在同一物理数据中心的数据库服务器，这导致网站响应极其缓慢。仍有众多数据库读取副本比主数据库延迟几小时，因而导致用户看到不一致的数据。我们将读取负载分摊到庞大的读取副本池上，针对我们服务的每个请求就很有可能“命中”延迟几小时的读取副本。

10月22日13:15 UTC

这时GitHub.com上的流量负载接近峰值。复制延迟在增加，而不是逐步降低。我们开始在东海岸公共云配置更多的MySQL读取副本。

10月22日16:24 UTC

副本同步后，我们切换到原始拓扑结构，以解决延迟/可用性问题。我们开始处理积压的数据时，让服务继续处于红色警报状态。

10月22日16:45 UTC

我们不得不均衡分摊数据积压带来的更大负载，让服务尽快回到100%的可用性。排入队列的有500多万个钩子事件和8000多个Pages构建。

我们在重新处理这些数据时，处理了约200000个因超出内部TTL而丢弃的Web钩子载荷。一发现这个问题，我们暂停了处理工作，暂时调高了该TTL。

为了避免进一步影响状态更新的可靠性，我们仍处于性能降级状态，直到处理完全部积压的数据，并确保服务明显回到正常的性能级别。

10月22日23:03 UTC

所有待处理的Web钩子和Pages构建已处理完毕，所有系统的完整性和正常操作运行已得到了核实。网站状态更新到绿色，以示正常。

结束语

我们知道您们的项目和公司多么依赖GitHub。我们服务的可用性和您们数据的正确性备受关注。我们将继续分析这次事件，以便有机会为您们提供更好的服务，并不负寄予我们的信任。