转载

GitHub应对1.28宕机事故的前前后后

　　英文原文：January 28th Incident Report

　　上周 GitHub 是不能使用了两个小时 6 分钟。我们理解你们有多么依赖 GitHub，并且考虑到服务的可用性也是我们提供的核心功能之一。在过去的八年里，我们已经为了确保你和全世界开发者依靠 GitHub 取得了相当大的进步，但一周前我们未能维持您期待的正常运行。我们深感抱歉，并且愿与你分享发生的事件，我们正在采取的措施以确保你能够访问 GitHub。

　　事件记录

　　在周四 00:23am UTC,2016 年 1 月 28 日(1 月 27 日星期三,4:23pm PST)(1 月 28 日星期四,8:23am 北京时间)我们主要数据中心的系统服务器和设备历经了短暂供电中断。我们有略超过 25% 的服务器和一些网络设备进行了重启。这导致我们的基础设施部分运行状态和生成警报发送给多个待命的工程师。我们的负载均衡设备和大量的前端应用程序服务器未受影响，但你们请求的依赖系统服务是不可用。我们的应用程序开始提供 HTTP 503 状态代码作为响应，把独角兽的图片放到你看到的错误页面。

　　我们初期对这个事件响应是混乱的，我们许多 ChatOps 系统在重启服务器。我们有内置多余的 ChatOps 系统，但这仍然失败，在刚开始的时候导致我们的响应有一些混乱和延迟。这种延迟最大的面向客户的影响之一是：直到 00:32am UTC (1 月 28 日星期四,8:32am 北京时间)，status.github.com (面向用户的监控 github.com 运行状态的网址)网站状态不能修改红色。8 分钟后，网站无法访问。我们认为这是一个不能接受的长延迟，并且我将确保未来我们的用户更快的访问。

　　无法访问服务器的初始通知和连接 redis 高峰相关的异常，使我们的调查队把问题定向于内部网络可能中断。我们也明白尝试连接导致网络问题的增加。而后来的调查显示，DDoS 攻击不是根本问题，我们早就花时间构建的 DDOS 防御系统和网络的健康调查。因为我们有经验来减轻 DDoS 攻击，这是我们的现在已经习惯的反应过程，我们很高兴可以迅速行动和一心一意地努力解决这一事件。

　　启动我们的 DDoS 攻击的防御，反应小组开始有条不紊地检查我们的基础设施和那些已经回到初始故障相关的警报。无法到达的几个 redis 集群的所有成员带领我们调查整个设施设备的正常运行时间。我们发现一些服务器报告正常运行时间是几分钟，但是我们的网络设备无故障运行时间报告，显示他们没有重启。利用这一点，我们认为所有的离线服务器共享相同的硬件类，和那些启动没有问题是一个不同的硬件类。受影响的服务器有多架排在我们的数据中心，尽管集群成员被分布在不同的机架，还是导致一些集群经历了他们所有的成员服务器重启。

　　随着时间的流逝，我们注意到我们的应用程序进程并没有像预期的那样启动。工程师开始在我们的应用程序服务器上查看进程表和日志。这就是说后端能力不足是由于我们的 Redis 集群离线导致进程无法启动。我们无意地在应用程序代码的引导路径中增加了一个强型依赖 Redis 群集。

　　通过这一点，我们就有了一个很清楚恢复服务的思路，并且朝着结束而工作。我们需要修复没有启动的服务器，我们需要让 Redis 集群来让我们的应用程序启动。由于物理驱动器已不认可，远程访问控制台截图从失败的硬件显示启动故障。一组工程师与现场设备技术人员分开工作，以使这些服务器通过渐进的跳蚤电力，使他们从无状态中唤醒，这样的磁盘就显示了出来。另一组工程师开始重新构建受影响的 redis 集群硬件改造。这些工作中最困难的关键是内部系统在离线硬件上。这使得配置新的服务器更困难。

　　一旦 Redis 集群数据还原到备用设备上，我们就能够把 redis 服务器进程重新上线。内部检查显示应用程序恢复，并从应用服务器正常的反应使我们 HAProxy 负载均衡器返回这些服务器的后端服务器池。经过验证的网站操作，维护页面被删除，我们移动到状态黄色。这发生在 2 小时 6 分钟后，最初的电力中断。

　　在接下来的几个小时里，确认所有系统都正常运行，并验证了没有数据丢失这一事件。我们非常感谢工程师们在保证所有的代码、issues、拉请求( pull requests)以及其他关键数据的安全和安全的地方，我们的减轻灾难工作是成功的。

　　未来工作

　　复杂系统的定义是由许多分立组件的相互共同作用来实现的结果。理解一个复杂的系统中的每个组件的依赖关系是重要的，但除非这些依赖关系进行严格的测试，可能的系统故障在独特的和新颖的方式。在过去的一周里，我们已经投入了大量的时间和精力去了解连锁故障导致 GitHub 不可用两个多小时的性质。我们不相信这是完全可以防止的事件，导致在我们的基础设施的一个很大一部分失去能力，但我们可以采取措施，以确保恢复发生在一个快速和可靠的方式。我们还可以采取措施，减轻这些事件对我们的用户带来的负面影响。

　　我们确定了硬件的问题，导致服务器无法查看自己的驱动器后，功率循环作为一个已知的固件问题，我们正在更新我们的舰队。更新我们的工具自动在新固件更新可用的团队开放的问题将迫使我们对我们环境的更新记录。

　　我们将更新我们的应用程序的测试套件，即使某些外部系统是不可用的，也要明确确保我们的应用程序启动，我们正在改善我们的电路断路器，这样我们就可以优雅地降低功能，当这些后端服务。显然，这种方法有限制，存在一个最小的需要服务请求的要求，但我们可以积极地减少这些依赖关系的列表。

　　我们正在复查我们的内部系统可用性的必要条件，负责关键业务的任务。如配置新的服务器，使他们与我们的用户面临的系统。最终，如果这些系统需要从一个意外中断的情况中恢复，他们必须是可靠的系统被回收。

　　一些小的技术改进也正在实施。改善跨部门沟通会缩短恢复时间。预定的升级方案在所有需要的人手准备齐全的情况下使我们的事件协调员要花更多的时间管理恢复工作和更少的时间浏览文档。在这个事件中，提高我们的信息传递给你有助于你更好地了解发生了什么，期待未来的更新。

　　总结

　　我们了解 GitHub 在您的项目和企业成功的工作流程中是多么的重要。我们都希望 GitHub 为该中断的影响道歉。我们将继续分析导致这一事件的事件和我们采取的措施，以恢复服务。这项工作将引导我们完善 GitHub 的系统和过程。

正文到此结束