起因从震动吃瓜开端
从 2023 年 11 月 27 日晚上 10 点左右截止 2023 年 11 月 28 日正午 12 点期间，DD产生了长达12小时的p0级bug，形成的影响咱们通过各种渠道或者亲身经历怎样我就不多说了，单说对企业形成的丢失超千万单和超4个亿的交易额。我只想说不愧是大企业，这也太狠了
简单整理下溃散原因
DD自己在微博上说的是底层系统软件产生毛病，身为底层开发的我对此仍是挺感兴趣的，所以简单吃了下瓜，网传是滴滴未正常晋级k8s导致集群溃散，且因为集群规划过大(信任这么大规划集群必定跑着相当多的事务)导致形成影响必定很大
DD在微博的致歉中说是底层系统软件毛病
网传是因为晋级导致的毛病
恰巧DD技能在公众号上从前发布过一篇# DD弹性云基于 K8S 的调度实践文章，文章里介绍了他们挑选的晋级计划，以及如此挑选晋级计划的原因
DD的晋级计划
dd 不愧是大厂，还有这么老版别的k8s集群，估量是很早就开端引进k8s集群了。通用的解决计划
首要两种计划的对比，DD已经在他们的技能文章中给明晰优缺点，身为一个菜鸟我估量是不适合谈论别人的计划，所以我只从我实际工作中遇到类似的问题是怎样解决的，
问题一 集群规划过大
kubernetes 官方推荐了5000个node 上限，尽管并不代表超出上限必定会出问题，可是此次事端显着告诉咱们超出上限的集群一旦产生事端有多可怕了
通用的计划
实际出产环境当集群规划达到上限咱们一般是怎样处理的呢，很简单——联邦集群，让多个集群打通成联邦集群，网络和k8s资源互通，提高了事务容纳的上限，同时将危险分摊给多个集群。增加了些许运维压力，可是显着要比张狂给单个集群加节点要安全多了
问题二 怎样挑选晋级计划
现在我遇到的大规划集群，根本上都是像dd 这样挑选晚上的窗口期晋级的，这点倒是没什么可说的，可是很少有直接原地晋级的，根本上都是有备份晋级的，流量也不会直接悉数涌入晋级后的集群的，要通过逐渐验证才会切换到新集群的，原地晋级我只能说是艺高人胆大了。
通用的计划
从dd 的技能博文上能猜出来，原地晋级的计划必定是通过他们内部验证了，最起码短期内是没出问题，才敢拿到出产集群上实践，可是很抱歉出产集群的扛危险才能仍是太小了，所以仍是建议老老实实挑选替换晋级的计划吧
问题三多控制节点
最后一点便是网传的控制节点溃散的问题，我觉得这太离谱了，这种大厂应该知道多master 节点，以及master 不在同一机房的问题吧，不说多数据中心计划，根本的灾备思维仍是要有的吧
胡言乱语
最近如同许多大厂的产品溃散，先是阿里后是滴滴，加上最近的裁人潮，网上流出了许多笑话最知名的莫过开猿节省，降本增笑。诚然互联网企业最大本钱便是人力本钱，当事务成熟后开掉开发人员来降低本钱似乎是一个不错的计划。可是当企业剩下的大部分都是ppt高手，真实干活的人黯然退场。如此这般难免会遇到这样那样的技能问题。期望老板领导们能慎重裁人，尊重技能。
最后期望各位程序员技能越来越稳，静静奉献的同时也能有自己的收成
