北京时间 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 小时没有合过眼了, 辛苦了! 致敬每一位奋斗在前线的程序员与工程师!
来源: http://developer.51cto.com/art/201810/585557.htm