GitHub宕机24小时，我们还能干嘛

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一样，开源出来的代码是让大家用的，而第三方云厂商拿来封装一下，直接变成自己的数据库，卖钱了。

而作为程序员接私单是很正常的事情了，如何避免被甲方带沟里，不被甲方以合同漏洞的方式压榨款项呢？