GitHub 英文原文：Github Downtime last Saturday 上周六，也就是12月22日，我们遭遇了一次重大停机事件。我们想要花时间来解释发生了什么事。这是 Github 历史上最糟糕的一次中断，这个中断是我们无法接受的，我很抱歉发生了这次中断，我们整个团队正在努力防止今后出现类似的问题。

背景

根据预定维护时间，周六我们将执行软件更新操作。这个软件更新是在我们的网络提供商的建议下用以解决之前遇见的一些早期故障。我们已经在类似设备上做过很多次测试，测试结果正常，因此我们对这次的更新非常自信。但是，执行更新仍是一件有风险的操作，因此我们专门安排了一个维护窗口来做更新，以防止不可预测的问题发生。

出了什么问题？

在我们网络中，每个连接服务器的交换机也连接到一对聚合交换机。这些聚合交换机成对安装并用一种叫做MLAG 的功能来伪装为一个单路由，因为 link aggregation, spanning tree, 和其他layer 2 协议希望有一个单一的主设备. 这使得我们能够在一个聚合交换机上执行维护任务，而不会影响合作伙伴交换机或接入交换机的连接。我么已经成功运用这项功能很多次了。

我们的计划是一次升级一个聚合交换机，这一过程被称为在服务中(in-service)软件升级。首先上传新软件到一台交换机，然后配置交换机之后在新版本上重新启动，并发出reload命令。剩下的交换机探测到不能连接到它，将开始一个故障转移过程接管原来由MLAG共同管理的资源。

在升级后，我们遇到了一些无法预知的故障，这些故障引起了20-30分钟的网络抖动(不稳定)，但是我们尝试在维护期间处理这些问题。我们断掉了一半聚合层到接入层交换机的链路，这样子能够是缓和一些问题，然后我们配合网络供应商试图找到让我们不稳定的原因。这仍然没有起到作用，受累于繁琐的制度，使我们只能够操作一半的上级链路，但是我们的流量是比较低的，这在当时并没有产生真的问题，在太平洋时间 11:00，根据我们以往的经验，如果我们对着这个新的版本没有一个好的解决方案，我们打算回滚这次软件的升级，并且回滚到太平洋时间 13:00的状态。

在太平洋时间12:15分，我们的网络供应商开始从交换机上收集最后的取证信息，以便他们尝试找出本次事故的原因。绝大多数的信息收集是隔离开进行的，包括收集日志文件和检索交换机各部分的硬件状态。作为最后一个步骤，他们尝试收集一个运行在交换机上的代理的状态。这涉及到停止的过程和促使它以某种方式写入状态，并在稍后进行分析。于是我们断开了接入交换机之间的链路，让它们彼此不相互受影响。这与我们之前以MLAG模式重启交换机类似，而在此前多次测试中都是没有出过意外的。 这时候，事情开始变得糟糕起来。一个部署在交换机上的代理被终止后，（成对部署的）另一个节点将等待 5 秒钟窗口期判断前者是否会恢复。如果它无法收到第一个节点的响应，却看到两者之间链路处于活跃状态，它会默认对方处于运行但状态不同步的情况。在这种情况下，它不能安全地接管与另一个路由器共同管理的资源，因此它会默认回到link aggregation, spanning tree和其他两层协议下的独立交换机运行状态。 通常情况下，这不是一个问题，因为该交换机在他的对端失效之前还会查看这条链路的状态。当链路失效时，交换机会等待2秒看看链路是否恢复。如果链路没有恢复，交换机会假设对端完全失效同时接管的 MLAG资源。这一类接管并不会触发任何第二层（ 链路层）的变化。 当第一个交换机上的代理被终止时，这一对路由器之间的链接并未被中断，因为代理无法操作硬件去中断链接。只有当代理程序重新启动后才可能发送命令操作底层 硬件。当时间非常不巧，且路由器还需要更多额外时间由代理程序为分析而记录运行状态时，这一对路由器之间的链接保持了足够长时间的活跃状态，最终使得对端 路由器发现了在活跃线路上心跳消息的缺失，因此进行了后面这种有着更强破坏性的故障转移操作。 当发生这些的时候它引起巨大的流量损失并且我们所有的链路要重新建立，leader 选择使用生成树协议( spanning-tree 网络协议)，并且所有网络中的链路通过生成树协议恢复。这使得通过接入层交换机的流量被阻塞了1.5分钟。 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务