滴滴出行：这起事故的起因是底层系统软件发生故障 并非网传的“遭受攻击”
@Apache9谣传滴滴那个大事故是 K8s 升错了版本，导致所有 pod 都被杀了，然后控制节点也一起被 kill ，导致无法回滚，所以恢复了十二个小时。
这东西我第一反应是震惊，但仔细想了想从业以来的经历，觉得倒也不奇怪，这个世界就是这么草台班子。
当然，为啥能搞出这么低级的升级错误就不说了，我们还是讨论了一下为啥恢复这么慢的。
首先，一般来说你也不能一个机房里真的就一个集群吧，再降本增效，你也得考虑万一一个集群整体挂了怎么办吧？但看起来滴滴就是真的没有。
第二，真出了这种问题，先分出一部分机器来直接重装，把核心服务拉起来，半个小时一个小时顶天，也能快速恢复起来啊。但看起来滴滴也搞不定。大家想了想，可能几个原因吧。
第一，你也不知道真的核心链路上都有哪些服务。这不是靠人手工填一次就行的，必须上 tracing，真的把请求链路抓出来才是准的。并且平时要做演练，对于非核心链路上的服务，必须真的做到挂了也不影响主流程。但凡平时的功夫没做到位，真到了关键时候，你就是发现所谓“核心服务”都拉起来了，结果请求哪个犄角旮旯没人知道的服务不成功，主流程直接就挂了，最后兜兜转转，差不多所有服务都拉起来了，主流程才真的恢复，这可不大半天就出去了。
第二，虽然说的是上 K8s，但很多公司其实只是为了上而上，根本没有真的改造成无状态的样子，配置里写死 host 写死 path 的地方多如牛毛，pod 换一台机器拉起来服务就挂。那这出了这么大的事，配置全不能用了，那可不得一点一点儿的改？如果真是这样，我觉得滴滴的同仁还挺牛逼的，这么短时间就能改完把服务都拉起来，这东西搞个一周都搞不好太正常了。
最新消息，滴滴致歉声明里领优惠券的页面又挂了，加载不出来了，这脸打的真是啪啪响。。。
总之，如果说前一阵阿里云的故障是打破了互联网大厂的技术神话，滴滴这一把真是把所谓互联网大厂技术光环的底裤都输没了。
最后，还是应了那句话，开猿节流，降本增笑 下一个要看百度了 开猿节流，降本增笑
原谅我不厚道的笑了 语雀，阿里云，滴滴 都相继出了重大故障 早台班子太多，话说嘀嘀最初架构有问题，腾讯入股后派了几十个专家去北京干了三个月，没能彻底解决问题。所以你用嘀嘀一直发现定位不准、显示不同步的问题。 据说跟阿里一样，把下面真正干活的裁掉了 总想着新人能完全替换老人。 HR看到运维整天无所事事，于是先裁年纪大的，好吧，有经验的就没有了，于是事情就来了 有句话怎么说来着：善战者无赫赫之功！
一个人技术很厉害，但是不善于表现的时候，就是这样。他不声不响的什么问题都给你解决了，又或者是通过丰富的经验，一开始就避免了那些问题的发生。然后，那些不懂的人，就会觉得他做的事情很简单，都不需要加班，没啥技术含量，随便找个两三年经验的就能替代。
当然，绝大部分时候，替代了也没什么事情。但是运气不好的话，祖传代码出了问题，就会发生这样的事情了。短时间内没人能搞得定。
页:
[1]