[译]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的系统和过程。

更多精彩内容~