GitHub“災難性”宕機24小時，程序員通宵修復......
北京時間 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 小時沒有合過眼了，辛苦了!致敬每一位奮斗在前線的程序員與工程師!
?
?
