内容简介:北京时间 10 月 22 日早上 6 点 52 分,GitHub.com 出现大面积网站宕机,GitHub 官方为用户带来的不便表示诚挚的歉意,并表示将尽快修复。程序员们忙了一个通宵,历经 24 小时,10 月 23 日 7 点,一切终于恢复正常。
北京时间 10 月 22 日早上 6 点 52 分,GitHub.com 出现大面积网站宕机,GitHub 官方为用户带来的不便表示诚挚的歉意,并表示将尽快修复。
程序员们忙了一个通宵,历经 24 小时,10 月 23 日 7 点,一切终于恢复正常。
GitHub 在 24 小时里都经历了些什么?
先来看下 GitHub“血红”的状态消息列表:
北京时间下午 2 点 51 分开始,状态消息不断在更新:再给我 2 小时!再给我 1.5 小时!再给我半小时!......
然而,“小时复小时,小时何其多”,承诺了太多,做到的太少,无奈,官方发布致歉函,表示真挚的歉意:
北京时间 10 月 22 日早上 6 点 52 分,GitHub.com 上多个服务由于受到网络分裂(network partition)和 subsequent 数据库故障的影响,导致我们网站显示的信息不一致。
我们非常谨慎地采取了措施确保数据的完整性,包括暂停 webhook 事件和其他内部处理系统。
我们知道我们的服务对您的开发工作流程是有多么重要,我们正在积极、努力地建立一个网站全面恢复的预估时间表。我们会尽快与您分享这条信息。
在此期间,GitHub.com 上的信息可能会显示为过期,但数据并没有丢失。一旦服务完全恢复,一切都会完好如初。
此外,此事件仅影响存储在 MySQL 数据库中的网站元数据,例如 issue 和 pull request。 Git 存储库数据并不受影响,并且在整个事件期间一直可用。
我们将继续通过状态页面提供更新和预估的解决时间。
从问题出现开始到解决的这 24 小时里,GitHub 团队显然处于崩溃状态。
GitHub 到底怎么了?
由官宣的致歉函以及状态消息列表可以看出,此次 GitHub 大面积的宕机主要是由于数据存储系统出现了问题。
给用户带来的困扰,简单来说就是:存储库,突然“消失”了!举个例子,你建了一个公共存储库,然后敲代码时,GitHub 会提示你存储库不存在;同时也无法打开其他存储库,也不能创建同名存储库。
然后网友们就炸锅了:
也有网友表示,“天呢!GitHub 还没修复好?!要破纪录了!”
还有网友说这个月不太平,微博、YouTube、Twitter、GitHub 通通都挂了......
有网友称找到宕机的真正原因:
作为 GitHub 的新东家,微软也就毫无悬念的躺枪了......
我也想知道是微软的锅么?
GitHub 是正在迁移到 Azure 云么?
GitHub 的终结者......
也有网友建议把项目迁移到 GitLab 上面:
但 GitLab 就一定靠谱么?那倒也未必。
GitHub 也给出了本次网络宕机热力图,可以看到遭受此次影响较为严重的是日本、美国西海岸、马来西亚以及澳大利亚东南地区。
不过,于北京时间 10 月 23 日早 7 点,GitHub 终于解决的此次“灾难性”问题,如下图:
想必 GitHub 的工作人员们应当是 24 小时没有合过眼了,辛苦了!致敬每一位奋斗在前线的 程序员 与工程师!
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 导致云原生微服务系统开发灾难性的8件事
- 谷歌大脑新研究:单一任务强化学习遇瓶颈?「灾难性遗忘」的锅!图灵奖得主Bengio参与
- 程序员高薪盛宴背后:程序员正在消失?
- 大龄程序员的出路,程序员的人生
- 程序员有话说 | 平时的程序猿 VS 面试的程序员
- 程序员被沦陷!国内程序员真的饱和了?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。