区块链神吐槽谣传滴滴那个大事故是 K8s 升错了版本，导致所有 pod 都被杀了，然后控制节点也一起被 kill ，导致无法回滚，所以恢复了十二个小时。
这东西我第一反应是震惊，但仔细想了想从业以来的经历，觉得倒也不奇怪，这个世界就是这么草台班子。
当然，为啥能搞出这么低级的升级错误就不说了，我们还是讨论了一下为啥恢复这么慢的。
首先，一般来说你也不能一个机房里真的就一个集群吧，再降本增效，你也得考虑万一一个集群整体挂了怎么办吧？但看起来滴滴就是真的一个机房就一个集群，连个备用集群都没有，升级也真敢主集群上直接干。
第二，真出了这种问题，先分出一部分机器来直接重装，把核心服务拉起来，半个小时一个小时顶天，也能快速恢复起来啊。但看起来滴滴也搞不定。大家想了想，可能几个原因吧。
第一，你也不知道真的核心链路上都有哪些服务。这不是靠人手工填一次就行的，必须上 tracing，真的把请求链路抓出来才是准的。并且平时要做演练，对于非核心链路上的服务，必须真的做到挂了也不影响主流程。但凡平时的功夫没做到位，真到了关键时候，你就是发现所谓“核心服务”都拉起来了，结果请求哪个犄角旮旯没人知道的服务不成功，主流程直接就挂了，最后兜兜转转，差不多所有服务都拉起来了，主流程才真的恢复，这可不大半天就出去了。
第二，虽然说的是上 K8s，但很多公司其实只是为了上而上，根本没有真的改造成无状态的样子，配置里写死 host 写死 path 的地方多如牛毛，pod 换一台机器拉起来服务就挂。那这出了这么大的事，配置全不能用了，那可不得一点一点儿的改？如果真是这样，我觉得滴滴的同仁还挺牛逼的，这么短时间就能改完把服务都拉起来，这东西搞个一周都搞不好太正常了。
最新消息，滴滴致歉声明里领优惠券的页面又挂了，加载不出来了，这脸打的真是啪啪响。。。
总之，如果说前一阵阿里云的故障是打破了互联网大厂的技术神话，滴滴这一把真是把所谓互联网大厂技术光环的底裤都输没了。
最后，还是应了那句话，开猿节流，降本增笑[二哈][二哈][二哈]
RandomWalk__:这种灾备就是吃力不讨好[二哈]灾备没弄好，出了事，人家说要你有啥用，灾备弄得好了，平常不出事，人家说要你干啥用[二哈][二哈]
扳手和把手:那些吹嘘的异地双机热备份啥的，都是。。
知情人士阿风:常听到的一句就是：你一个破打车(外卖、网购、直播)软件哪需要那么几百千人维护？
小李寻欢d:这些工作没毛用啊，平时说这些没出事的时候体现不出价值，都去搞创新，搞营收
浪迹天涯O号:我们小厂升级k8s是先新建集群，再把流量慢慢切换到新集群，是不是太保守了
破阵起宫中:开了一线员工还想交接顺利？ 能有问有答就已经是很有职业道德的了，至于回答得细不细，有没有遗漏，那就另说了。
废话流GPT :虽然说的是上 K8s，但很多公司其实只是为了上而上，根本没有真的改造成无状态的样子，配置里写死 host 写死 path 的地方多如牛毛，pod 换一台机器拉起来服务就挂 这。。。。
Zelindorf:回复 @云股票:我听到的说法就是etcd挂了，我们就遇到过etcd挂了重启无法恢复的问题。博主真正不懂的是，没人敢直接操作生产集群的k8s版本升级，所谓的升级都是重新搭一个集群，服务滚动升级过去，理论可行不代表真有人这么做。要是最后发现滴滴真是直接操作k8s集群请务必告诉我让我嘲笑嘲笑
烧饼Core:回复@云股票:没啥不可能啊，以前的服务发现路由比较挫，看滴滴技术公众号自己写的 k8s 总结就有提到要固定 IP 漂移 Pod 的场景，有其他地方写死了 host 或者需要人工维护，世界很多样，多了解多看看[笑cry]
羊皮卷上的烙印:很多公司上k8s的时候压根没有全链路都改造合适，只改了部分，有的pod依赖很多写死的配置，还有网关这块，我就见到过10来种稀奇古怪的写法。当升级到的时候好了某处的命名规则这个系统就废了！
G_Jonny:控制pod是manifest，只要kubelet活着就会活着吧，除非是用的外部etcd数据库，升级导致连不上etcd或者etcd挂掉了，导致apiserver起不来，从而scheduler、controler manager无法管理deployment、statefulset、daemonset。导致pod挂掉。感觉更多的也是发布流程上的问题，uat环境升级或灰度发版时没发生？
star睡不醒:ppt做多了是这个样子的。运维工作鲜有创新点，不能做ppt，但是细节很多。想要晋升看这个没用，所以没人愿意做，然后就出事。
https://weibo.com/1876829375/NuOfIdoty
作为一名互联网科技博主，这次谈谈本行。
昨天阿里云的大事故，圈内人猜测都是 IAM 之类的挂了，比如鉴权。一个是因为挂的太彻底了，几乎所有产品全挂，如果不是 IAM 那只能是网络了。但同时，恢复之后很多客户发现自己的业务也没啥事，运行很平稳，说明大概率不是网络问题，那也就只可能是 IAM 之类的系统挂了。
然后呢，这个事情大概率是个变更导致的故障，不会是系统自己出的问题。这个只要大概了解点儿技术都不难判断。
IAM 类的系统其实功能粗略可以分三块，一块是后台管理，一块是登录，一块是鉴权。
后台管理也就是你创建删除用户，修改用户权限的地方，这块如果提供了什么跨所有可用区同步的能力，那确实有可能一挂全挂。但这块挂了并不会影响别的服务，而且这块功能本身使用频率也很低，所以通常也不是啥大问题。
登录其实就是认证身份，生成 token 的过程，比如你要登阿里云的管理后台这块肯定是要过的，如果这块挂了你看着确实看着就是阿里云全挂了。但已经登录的用户应该是不受影响的，所以应该也不会一下全炸。同时对于正在运行的服务应该也没啥影响，只是有可能新启动的服务会受影响，因为有可能拿不到新 token 了。
鉴权其实就是各种服务拿着 token 去问是否合法，以及校验这个 token 权限的过程。这块是所有服务都强依赖的，一旦出了问题确实影响会很大。但鉴权这个东西，本质就是个读操作，并且从产品设计上，权限生效啥的本身就是异步的，所以冗余啊高可用啊之类的非常好做，并且不同区域之间肯定是隔离的，我不信阿里云连这种基本的东西都做不好，所以在运行过程中突然出现所有可用区全挂的故障几乎不可能。
所以综合下来看，大概率还是人为操作导致的严重故障。并且这个操作一定是违规的，大概率是跳过了一些灰度的流程直接推了全量。至于是误操作还是有意为之，这个咱就不清楚了，等着看阿里云自己的通告吧。
不过作为一名搞了十来年基础架构的背锅侠，我还是想再多说两句。
稳定性这个东西，说难也难，说不难也不难。难是因为确实没见过哪个公司系统不挂的，而且从理论上，就不存在完全不挂的系统。说不难，是因为没有哪次挂从技术和流程上看是无法避免的，所以只要投入精力去做去搞，稳定性提高并不是啥难事。
但提高稳定性这个事情本身，其实是件吃力不讨好的事情。举个简单的例子，年年花钱修河堤，如果没发大水，领导会质疑说你年年花这个钱干啥，从来没出过事。如果发了大水，领导会质疑说年年花这个钱干啥，不还是发大水了。
看明白没？搞稳定性和修河堤其实是一样的，都是防患于未然，做的越好越没有存在感，一旦出了事所有努力全白费，还得背锅。这种事情但凡想做好，一个是需要找一个耐得住寂寞且有责任心的人来负责，另一个就是管事的一把手必须真的懂这个事情的长期价值，愿意顶住压力给下面人空间去做，在绩效和评价上也做到公平公正。所以在任何公司搞基础架构，一旦公司换了一个搞业务的老板过来，那么你最好赶紧准备简历留条后路，大故障马上就要来了，别到时候背锅走人还不好找工作。。。
另外，最近经济不景气，各行各业都在降本增效，这个对于搞稳定性的的团队也是个巨大的打击。任何公司降本增效，第一肯定是先干掉烧钱的新业务，这个没啥说的。第二就是要对成本部门下刀，而这些搞基础架构、搞稳定性的团队，必然都是成本部门，很难不挨刀。朋友圈看到一个说法，降本砍业务部门，业务部门马上摆烂收入就要降，老板也怕。但砍成本部门，他们又不敢主动搞大故障来反击(违法的，这么搞真的会进去的)，这些人工资又高，一砍下去成本降的立竿见影，然后所谓影响稳定性其实也是长期的，你砍完可能一年系统运行都很正常。所以越砍越上瘾，砍完还想砍，直到最后出了个大故障，才发现满地鸡毛没法收拾。。。
所以就现在这个大环境，我觉得其他竞争对手也别开心。阿里云遇到的问题，大家一个都不少。大环境这个样子，没有人能独善其身。更大的故障已经在路上了，就看谁家最倒霉吧，好日子还在后头呢[doge][doge][doge]
https://weibo.com/1876829375/Nsnpze2tK