GitHub“災(zāi)難性”宕機(jī)24小時(shí)，程序員通宵修復(fù)......

作者：51CTO技術(shù)棧 2018-10-24 09:54:37

北京時(shí)間 10 月 22 日早上 6 點(diǎn) 52 分，GitHub.com 出現(xiàn)大面積網(wǎng)站宕機(jī)，GitHub 官方為用戶(hù)帶來(lái)的不便表示誠(chéng)摯的歉意，并表示將盡快修復(fù)。

程序員們忙了一個(gè)通宵，歷經(jīng) 24 小時(shí)，10 月 23 日 7 點(diǎn)，一切終于恢復(fù)正常。

GitHub 在 24 小時(shí)里都經(jīng)歷了些什么?

先來(lái)看下 GitHub“血紅”的狀態(tài)消息列表：

北京時(shí)間下午 2 點(diǎn) 51 分開(kāi)始，狀態(tài)消息不斷在更新：再給我 2 小時(shí)!再給我 1.5 小時(shí)!再給我半小時(shí)!......

然而，“小時(shí)復(fù)小時(shí)，小時(shí)何其多”，承諾了太多，做到的太少，無(wú)奈，官方發(fā)布致歉函，表示真摯的歉意：

北京時(shí)間 10 月 22 日早上 6 點(diǎn) 52 分，GitHub.com 上多個(gè)服務(wù)由于受到網(wǎng)絡(luò)分裂(network partition)和 subsequent 數(shù)據(jù)庫(kù)故障的影響，導(dǎo)致我們網(wǎng)站顯示的信息不一致。

我們非常謹(jǐn)慎地采取了措施確保數(shù)據(jù)的完整性，包括暫停 webhook 事件和其他內(nèi)部處理系統(tǒng)。

我們知道我們的服務(wù)對(duì)您的開(kāi)發(fā)工作流程是有多么重要，我們正在積極、努力地建立一個(gè)網(wǎng)站全面恢復(fù)的預(yù)估時(shí)間表。我們會(huì)盡快與您分享這條信息。

在此期間，GitHub.com 上的信息可能會(huì)顯示為過(guò)期，但數(shù)據(jù)并沒(méi)有丟失。一旦服務(wù)完全恢復(fù)，一切都會(huì)完好如初。

此外，此事件僅影響存儲(chǔ)在 MySQL 數(shù)據(jù)庫(kù)中的網(wǎng)站元數(shù)據(jù)，例如 issue 和 pull request。 Git 存儲(chǔ)庫(kù)數(shù)據(jù)并不受影響，并且在整個(gè)事件期間一直可用。

我們將繼續(xù)通過(guò)狀態(tài)頁(yè)面提供更新和預(yù)估的解決時(shí)間。

從問(wèn)題出現(xiàn)開(kāi)始到解決的這 24 小時(shí)里，GitHub 團(tuán)隊(duì)顯然處于崩潰狀態(tài)。

GitHub 到底怎么了?

由官宣的致歉函以及狀態(tài)消息列表可以看出，此次 GitHub 大面積的宕機(jī)主要是由于數(shù)據(jù)存儲(chǔ)系統(tǒng)出現(xiàn)了問(wèn)題。

給用戶(hù)帶來(lái)的困擾，簡(jiǎn)單來(lái)說(shuō)就是：存儲(chǔ)庫(kù)，突然“消失”了!舉個(gè)例子，你建了一個(gè)公共存儲(chǔ)庫(kù)，然后敲代碼時(shí)，GitHub 會(huì)提示你存儲(chǔ)庫(kù)不存在;同時(shí)也無(wú)法打開(kāi)其他存儲(chǔ)庫(kù)，也不能創(chuàng)建同名存儲(chǔ)庫(kù)。

然后網(wǎng)友們就炸鍋了：