Boom，驚天一聲雷，全球最大的同性交友網站GitHub，掛了。
舉天同慶，歡度1024，GitHub真是良苦用心啊～
從北京時間早上7點開始，GitHub開始出現大面積癱瘓
截止目前北京時間21點整，GitHub仍處於未修復狀態，看這架勢得在要會時間了。
來看看國外的程序員們是怎麼看待這件事情的
不過我更喜歡下面這幅圖，雖然我已經2年不用windows了，但是看到這個圖還是很想笑啊，每次windows一個補丁，就能讓你半天不用看屏幕了。
下圖就有意思了，GitHub這艘巨輪撞上了Microsoft這座冰山，邊上的GitLab遊艇來救人（搶人）了。
下圖懂的人自然懂……
這次的癱瘓要麼讓Azure背鍋？
不過話說回來，正經起來還是要的，GitHub之所以癱了，官方給出的解釋是網絡和數據庫故障。從表徵上來看，這次應該不是rm -rf。
從技術角度出發，GitHub作爲全球性的託管平臺，容災能力不會差，只是造成這種大面積癱瘓的情況一定是棘手的，恢復也需要一定的時間。如果是硬件問題，應該有冗餘，但也沒有想象的那麼簡單，並不是切換一下IP地址，指到備份庫就完了。
硬件問題造成的癱瘓很有可能是一個批次的down，而根據GitHub給出的最新狀態顯示，似乎硬件問題已經解決，目前數據遷移工作也已經結束了。
在這場全世界矚目的大型真人秀直播節目中，GitHub其實要比攜程刪庫、GitLab刪庫要來的好很多。畢竟前者是硬件問題導致癱瘓，技術人員通過技術手段來補償，而後者則是一些人爲的誤操作，而補償手段也非常不理想。當然了，對於最終的影響面、影響結果還是要看官宣的。
在吐槽的同時大家不妨對比一下GitHub的做法，把自己當前解決故障的進度公佈出來，讓每一個小時都有所交代，這是很難得的。
截止發稿前（5:30），GitHub的狀態已經轉爲了Warning，基本都在做最後的校驗工作了。
總的來說，這次故障雖然影響面很廣，但是GitHub的技術團隊給予外界透明度還是相對較高的。這次不知道會不會有哪位背鍋俠站出來呢
所以作爲程序員，千萬不要做rm -rf，很有可能就被fire了，更有可能涉及到法律層面的責任。
同樣，如果是使用開源代碼，一定要注意他們的協議，就好像之前的Redis和mongoDB一樣，開源出來的代碼是讓大家用的，而第三方雲廠商拿來封裝一下，直接變成自己的數據庫，賣錢了。
而作爲程序員接私單是很正常的事情了，如何避免被甲方帶溝裏，不被甲方以合同漏洞的方式壓榨款項呢？