事故频发的 GitHub 是如何从这次网络故障中恢复的

2021 年 10 月 21 日，GitHub 经历了一次重大的网络故障，导致服务中断长达 24 小时 11 分钟。这起故障影响了全球数百万的开发者，也让 GitHub 的声誉遭受了重创。

事故原因分析

事故的根源可以追溯到 10 月 21 日 22:52，当时 GitHub 为了更换发生故障的 100G 光纤设备，美国东海岸网络中心与美国东海岸数据中心之间的连接被断开。连接在 43 秒后恢复，但这次短暂的中断引发了一系列事故，最终导致了服务降级。

故障发生后，GitHub 工程师迅速展开了调查。他们发现，由于连接中断，导致美国东海岸数据中心无法与其他数据中心通信。这导致了数据不一致，进而引发了一系列问题，包括：

• 代码库无法访问。 开发者无法克隆或推送代码到 GitHub。
• Pull request 无法合并。 开发者无法将他们的代码合并到主分支。
• Issue 和评论无法查看。 开发者无法查看或回复 issue 和评论。
• GitHub Pages 无法访问。 托管在 GitHub Pages 上的网站无法访问。

恢复过程

在故障发生后，GitHub 工程师立即采取措施来恢复服务。他们首先将受影响的数据中心与其他数据中心隔离，以防止问题进一步扩散。然后，他们开始修复故障的根源，并重新建立数据中心之间的连接。

在修复故障的同时，GitHub 工程师还采取了一系列措施来减轻故障的影响。他们向受影响的用户发送了电子邮件通知，并通过 Twitter 和 GitHub Status 页面更新故障的最新情况。他们还与一些主要的代码托管平台合作，以帮助受影响的开发者将他们的代码转移到其他平台。

经过 24 小时 11 分钟的努力，GitHub 的服务终于恢复正常。在故障期间，GitHub 的工程师们表现出了高度的专业性和敬业精神。他们迅速地找到了故障的根源，并采取了有效的措施来恢复服务。他们的努力值得我们钦佩。

经验教训

GitHub 的这次网络故障给我们提供了很多宝贵的经验教训。其中最重要的几点包括：

• 冗余是关键。 GitHub 的服务之所以能够在故障发生后迅速恢复，很大程度上是因为他们采用了冗余设计。冗余设计可以确保在某个组件发生故障时，系统能够继续运行。
• 容错是必备。 GitHub 的系统能够在故障发生后继续运行，还因为他们采用了容错设计。容错设计可以确保系统在遇到错误时，能够自动恢复到正常状态。
• 沟通是关键。 在故障发生期间，GitHub 工程师与受影响的用户保持了良好的沟通。他们及时地向用户通报故障的最新情况，并提供了有效的解决方案。这种良好的沟通有助于缓解用户的情绪，并减少故障的影响。

GitHub 的这次网络故障是一个警示，它提醒我们，即使是世界上最可靠的系统也有可能发生故障。因此，我们必须做好充分的准备，以应对可能发生的故障。