看到昨天滴滴打车软件崩溃，修复了一晚上还没弄好，让我想起五六年前创业时，公司一个代码员工不知道怎么搞的，莫名其妙删除了一堆服务器代码，然后我们这边的数据模型组的小伙伴就崩溃了，因为他平时研发的核心模型都在那里，两个多月的辛苦一下子全没了，关键吊诡的是他竟然没有备份而且自己电脑里也没有源代码！
然后公司开始评估和内部甩锅，一方面那个小员工是立马提出辞职了，他的上级有至少三个，顶头上级与交叉管理的团队领导开始内斗，会议室里吵翻天，CTO却跟没事人似的，以往不会影响到自己。
另一方面是评估数据模型的价值，要不要重新研发，怎么恢复？大家都没看过那个数据模型运行的质量好不好，只有我在过程中参与了一点，也只是对着他的个人电脑屏幕看他演示过效果，我根据自己的业务部门的认知，就说还是有价值的，尤其是检索准确率方面比以前高。然后这下可好了，公司的业务合伙人、技术合伙人、财务合伙人，都抓住数据小伙伴不放，非让他回忆起来，把前面两个月开发的东西都重新写出来。
哎呀，那个小伙伴要疯了，过去俩月他刚来公司、工作特别卖力，天天晚上在公司吃泡面，结果自己莫名其妙遭遇这种事情，大责任应该是公司的技术管理疏忽，缺乏安全流程。但最后最难的却是他自己。他也不可能完全重新写出来了，况且中间参与意见的那个专利数据小伙伴早已离职。所以他也只好离职，可是公司死活不让他走，万般刁难，不给开离职证明。这个小伙伴都眼泪汪汪的了，也没用。最后他去劳动仲裁，无果，然后声称要来泼汽油，白刀子进去 红刀子出来。哎呀，这是闹的。最终也只是用一周时间恢复出来一点点，效果可谓是前功尽弃。草台班子本质无疑。
谣传滴滴那个大事故是 K8s 升错了版本，导致所有 pod 都被杀了，然后控制节点也一起被 kill ，导致无法回滚，所以恢复了十二个小时。
这东西我第一反应是震惊，但仔细想了想从业以来的经历，觉得倒也不奇怪，这个世界就是这么草台班子。
当然，为啥能搞出这么低级的升级错误就不说了，我们还是讨论了一下为啥恢复这么慢的。
首先，一般来说你也不能一个机房里真的就一个集群吧，再降本增效，你也得考虑万一一个集群整体挂了怎么办吧？但看起来滴滴就是真的没有。
第二，真出了这种问题，先分出一部分机器来直接重装，把核心服务拉起来，半个小时一个小时顶天，也能快速恢复起来啊。但看起来滴滴也搞不定。大家想了想，可能几个原因吧。
第一，你也不知道真的核心链路上都有哪些服务。这不是靠人手工填一次就行的，必须上 tracing，真的把请求链路抓出来才是准的。并且平时要做演练，对于非核心链路上的服务，必须真的做到挂了也不影响主流程。但凡平时的功夫没做到位，真到了关键时候，你就是发现所谓“核心服务”都拉起来了，结果请求哪个犄角旮旯没人知道的服务不成功，主流程直接就挂了，最后兜兜转转，差不多所有服务都拉起来了，主流程才真的恢复，这可不大半天就出去了。
第二，虽然说的是上 K8s，但很多公司其实只是为了上而上，根本没有真的改造成无状态的样子，配置里写死 host 写死 path 的地方多如牛毛，pod 换一台机器拉起来服务就挂。那这出了这么大的事，配置全不能用了，那可不得一点一点儿的改？如果真是这样，我觉得滴滴的同仁还挺牛逼的，这么短时间就能改完把服务都拉起来，这东西搞个一周都搞不好太正常了。
最新消息，滴滴致歉声明里领优惠券的页面又挂了，加载不出来了，这脸打的真是啪啪响。。。
总之，如果说前一阵阿里云的故障是打破了互联网大厂的技术神话，滴滴这一把真是把所谓互联网大厂技术光环的底裤都输没了。
最后，还是应了那句话，开猿节流，降本增笑
网友评论