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

更多精彩内容

[译]GitHub应对1.28宕机事故的前前后后相关推荐

GitHub历史上最糟糕宕机事故回放及反省
http://www.csdn.net/article/2013-01-05/2813427-Github-Downtime-last-Saturday 摘要:距离今年9月份在两天内两次宕机仅间隔3个 ...
阿里云爆发史上最严重宕机事故。。。
阿里云香港区于2022年12月18日出现故障,多个香港和澳门的网站受到影响,包括Linux中国的官网(https://linux.cn/).澳门金融管理局.澳门银河.莲花卫视.澳门水泥厂等关键基础设施 ...
《让系统发生重大宕机事故的15个方法》
来源| 技术领导力(ID:jishulingdaoli) 你没看错,本文探讨的主题是"让系统发生重大宕机事故的15个方法",仔细研究后你会发现,把系统搞宕机是一件非常有技术含量的事 ...
2018年十大云宕机事故盘点：主流无一幸免！
根据IDC今年7月份发布的<中国公有云服务市场半年度跟踪报告>显示,阿里云的市场占有率已过45%,腾讯云达到10%.在全球市场,根据Gartner最新数据显示,亚马逊AWS占全球份额的51 ...
微软再现宕机事故部分用户9天无法使用电邮
据CloudPro称,微软Office 365中的电子邮件服务已经连续宕机9天了. 微软对CloudPro说,这个问题并没有影响到Office 365的所有用户,但是"那些受到影响的客户可能 ...
HBase案例 | 20000个分区导致HBase集群宕机事故处理
这是几个月前遇到的一次HBase集群宕机事件,今天重新整理下事故分析报告.概况的说是业务方的一个10节点HBase集群支撑百TB级别的数据量,集群region数量达 23000+,最终集群支持不住业务 ...
如何应对缓存服务器宕机的情况
假如所有缓存服务器都宕机,而且不能很快恢复,并且假设数据库服务器能够支撑,在代码中如何应对这样的情况? 之前的做法是在读缓存的地方捕获异常并写入日志,然后直接从数据库读取数据:在写缓存的地方捕获异常并 ...
携程网宕机事故深度剖析
2015年5月28日上午11时许,携程旅行网官方网站突然陷入瘫痪,打开主页后点击时均显示"Service Unavailable",经过12小时的紧急抢修后,携程网终于恢复,可正常 ...
如何应对java服务器宕机_代码中如何应对缓存服务器宕机的情况
今天在演练这样一个场景--假如所有缓存服务器都宕机,而且不能很快恢复,并且假设数据库服务器能够支撑,在代码中如何应对这样的情况? 之前的做法是在读缓存的地方捕获异常并写入日志,然后直接从数据库读取数据 ...

[译]GitHub应对1.28宕机事故的前前后后

[译]GitHub应对1.28宕机事故的前前后后相关推荐

最新文章

热门文章