谣传滴滴那个大事故是 K8s 升错了版本，导致所有 pod 都被杀了，然后控制节点也一起被 kill ，导致无法回滚，所以恢复了十二个小时。
这东西我第一反应是震惊，但仔细想了想从业以来的经历，觉得倒也不奇怪，这个世界就是这么草台班子。
当然，为啥能搞出这么低级的升级错误就不说了，我们还是讨论了一下为啥恢复这么慢的。
首先，一般来说你也不能一个机房里真的就一个集群吧，再降本增效，你也得考虑万一一个集群整体挂了怎么办吧？但看起来滴滴就是真的没有。
第二，真出了这种问题，先分出一部分机器来直接重装，把核心服务拉起来，半个小时一个小时顶天，也能快速恢复起来啊。但看起来滴滴也搞不定。大家想了想，可能几个原因吧。
第一，你也不知道真的核心链路上都有哪些服务。这不是靠人手工填一次就行的，必须上 tracing，真的把请求链路抓出来才是准的。并且平时要做演练，对于非核心链路上的服务，必须真的做到挂了也不影响主流程。但凡平时的功夫没做到位，真到了关键时候，你就是发现所谓“核心服务”都拉起来了，结果请求哪个犄角旮旯没人知道的服务不成功，主流程直接就挂了，最后兜兜转转，差不多所有服务都拉起来了，主流程才真的恢复，这可不大半天就出去了。
第二，虽然说的是上 K8s，但很多公司其实只是为了上而上，根本没有真的改造成无状态的样子，配置里写死 host 写死 path 的地方多如牛毛，pod 换一台机器拉起来服务就挂。那这出了这么大的事，配置全不能用了，那可不得一点一点儿的改？如果真是这样，我觉得滴滴的同仁还挺牛逼的，这么短时间就能改完把服务都拉起来，这东西搞个一周都搞不好太正常了。
最新消息，滴滴致歉声明里领优惠券的页面又挂了，加载不出来了，这脸打的真是啪啪响。。。
总之，如果说前一阵阿里云的故障是打破了互联网大厂的技术神话，滴滴这一把真是把所谓互联网大厂技术光环的底裤都输没了。
最后，还是应了那句话，开猿节流，降本增笑[二哈][二哈][二哈]