时隔两年,GitHub竟然又挂了,程序员的崩溃只在一瞬间

作者 : 开心源码 本文共1189个字,预计阅读时间需要3分钟 发布时间: 2022-05-13 共164人阅读

前言

说到GitHub,不得不提一下18年的事,18年10月22号,GitHub曾意外宕机,官方表示:数据存储系统是本次故障的元凶

2020年7月13日,时隔两年,GitHub竟然再次出现严重宕机,这次事件让人们对单单在2020年4月发生三起单独故障后GitHub的可靠性提出了新的疑问。

GitHub将4月的那三次故障分别归咎于:

1.软件负载均衡系统的错误配置破坏了在服务于GitHub.com的应用程序与其依赖的内部服务之间的流量内部路由;

2.数据库连接配置错误,与当时进行中的数据分区工作有关,“导致意外地进入到生产环境”;

3.网络配置“无意中应用于我们的生产网络”。

GitHub在4月曾承认,其模拟试验室环境存在问题。

该公司称:“该模拟环境构建数据库和数据库连接的方式与生产环境不一样。这可能导致生产环境所特有的连接变更的可测试性受限制。我们会在未来几个月内处理这个问题。”

GitHub的大部分平台都在其自己的裸机基础架构上运行,网络基础架构则“围绕Clos网络拓扑结构而建,每个网络设施都通过边界网关协议(BGP)共享路由。”

GitHub在2018年被微软以75亿美元的价格收购,被5000多万开发人员所使用。考虑到它支持的工作负载以及外界广泛依赖它以确保高可用性,像这样的大规模故障可能会带来严重影响。

与其余许多大型基础架构提供商一样,GitHub的所有者微软也面临这个挑战:新冠疫情后远程工作人员数量激增,从而导致工作负载激增,因而需要迅速扩大数据中心基础架构的规模。微软在4月份承认,疫情过后,它面临供应链方面的少量问题。

众多网友在twitter、微博议论:

因为全球各地的工厂纷纷关闭,大企业和超大规模公司需要检修数据中心,新冠疫情严重影响了全球服务器硬件供应链。(Dropbox的首席技术官表示,他公司的数据中心团队“在8周内主动更换掉了30000个部件”,以安全地减少现场工作人员)。

与此同时,芯片制造商AMD在第一季度财报电话会议上表示,新冠疫情危机期间的短短10天内,一家未透露名称的云提供商为数据中心添加了10000台服务器,因为工作负载猛增,该云提供商拼命扩大其基础架构的规模。

然而,GitHub的问题似乎主要还是跟模拟环境与生产环境之间的缺口方面的问题有关。

最后

2017 年 1 月底,GitLab 因运维人员疲劳误删数据导致宕机超 24 小时。该系统管理员深夜在进行数据库维护时,使用 rm -rf 删了 300 GB 生产环境数据。不过,整个平台恢复之后,有 6 个小时时间的数据还是丢失了。

GitLab 的数据备份功能也失效了。修复报告称当时数据丢失并非仓库的数据,而是仓库相关的 issue 以及合并请求操作。为了纪念这个事件,还有人提议将 2 月 1 日定为“世界备份日”。

目前还不能确定 GitHub 故障的严重程度。唯一可以确定的是,什么云服务都是靠不住的,重要的是:备份!备份!备份!

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 时隔两年,GitHub竟然又挂了,程序员的崩溃只在一瞬间

发表回复