找回密码
 加入我们
关闭

CSDN热搜

草根吧
首页 官方推荐社区 移动开发 滴滴2023.11.27P0级故障技能复盘回首(k8s的的错?) ...

android-studio 滴滴2023.11.27P0级故障技术复盘回首(k8s的的错?)

IP:广东省广州市
一把剑 2023-12-3 11:01:12
本文从滴滴官方规复及技术公众号带大家从技术角度复盘此次变乱
  目录

1. 背景
2. 滴滴官方消息
3. 题目分析及定位
4.网传的k8s及剖析
5.k8s激发的思考:举一反三,怎样制止再次出现
6.近段时候其他平台崩溃回首


1. 背景

11 月 27 晚约 10 点,滴滴打车遭受大范围技术故障。用户在利用滴滴的利用法式及小法式时碰到诸多题目,包括叫车功用反应缓慢、没法利用青桔单车扫码功用,以及支付打车优惠券功用生效。直至第二天早上,滴滴发文已规复一般。
按照微博反应发现了以下题目:


  • 收集加载很是,没法排单;
  • 数据紊乱,一个定单被派到 4 个司机定单中;
  • 数据展现、数据状态有误,定单取消、定单支出都出现题目;
  • 排单逻辑出错,司机接单到 两千千米之外的单;
  • 定单流水出错,8 千米表示免费 1540 元;
  • 团体题目,连带滴滴、小桔充电、滴滴加油、青桔单车都出现题目;
  • 滴滴内网题目,员工没法一般利用内网关连办事;
至此,滴滴“喜提”微博热搜



2. 滴滴官方消息




3. 题目分析及定位

11月29日,滴滴出行再就27昼夜间系统故障道歉,提出了响应的补救办法和补偿计划。并公布了本次变乱的初步观察结果:起因是底层系统软件发生故障,并非网传的“蒙受进犯”。
本次变乱中,平台功用几近周全瘫痪,仅网约车办事功用规复时长近12小时,可以猜测不是某一个软件功用的bug,否则影响不会这么广,规复也不会这么慢。滴滴官方也发文分析是底层系统软件的发生故障所以解除了办事器硬件的题目,所以可以猜测为云办事器根柢底层软件的题目。
滴滴具有庞大的营业线,其底层系统由复杂的软硬件组成,其中包括办事器、收集装备、数据库等等重要组成部分,任何一个环节出现故障,都有大要致使全部系统崩溃,用户没法一般利用办事。

360 平安专家以为,滴滴闪崩背后的技术原因原由大要有六种:

  • 系统更新升级进程中出现了编程毛病、逻辑毛病或未处置惩罚的很是情况:一样平常情况下,互联网厂商公布更新城市在早晨,与滴滴发生故障的时候也能对应,固然营业升级保护是放量更新,但现在滴滴全平台、全营业都故障了,分析必定是他 “家里” 的题目。
  • 办事器故障:比如滴滴的焦点机房,大要恒温恒湿情况出了题目,致使办事器过热、CPU 烧了,大要焦点机房地点地发生了自然灾难如地震、洪流、海啸等,这类情况下,硬件需要重新更换,里面的办事软件也需要重新设备,规复周期相对较长,但这个大要性比力小。
  • 第三方办变乱障:滴滴的背景架构大要利用了第三方办事大要组件。假如第三方出了题目,也大要会影响滴滴的一般运转。但出于平安性考虑,滴滴大要不会将焦点营业托管给第三方,不外这个大要性也较小。
  • 其他收集平安题目(由于滴滴已经官方分析不是遭到进犯,所以都可解除其他3种猜测)
小我分析:


  • 由于官方声明底层系统软件发生故障,所以解除了办事器的故障,那末滴滴这类至公司,利用的第三方组件应当也都是很大的供给商供给的, 假如是第三方组件出题目,其他利用该组件的公司也会出题目,现在看没事,所以也可以解除,那末终极来看,应当就是底层系统软件升级的时候出了题目
4.网传的k8s及剖析

上面经过定位已经定位到了底层系统软件升级的时候出了题目,按照下面的网传图片,k8s合适揣度

翻了一下滴滴技术公众号2023-10-17表一篇文章《滴滴弹性云基于 K8S 的调理理论》,发现滴滴技术同学在做k8s集群升级:k8s 版本的升级:先容到从 k8s 1.12 到 1.20 跨版本升级的计划,而且单集群节点已经跨越了5000个node,一旦爆炸,爆炸半径是不小
给了两个计划:
1. 更换升级计划先容:
   两个 k8s 集群,1.12 和 1.20,间接搭建新的一套新的 1.20 master 和周边组件;
  1.20 集群中建立和 1.12 和等量的营业负载,也就是 sts 和 pod;
  经过上游的流量管控利用决议流量散布,一路头流量都在 1.12 的 sts 的 pod中,慢慢切流到 1.20 的 sts 的 pod;
  有题目标时候可以快速回切流量。
  2. 原地升级计划先容:
   只要一个 k8s 集群,将 master 和周边组件间接从 1.12 升级到 1.20;
  慢慢将集群中的 node 也就是 kubelet 从 1.12 版本升级到 1.20;
  不做任何营业负载关连的操纵,也就是 sts 和 pod 无需重建,实在的流量散布也不做操纵,随着 node 升级流量自然就慢慢从 1.12 切到 1.20 了;
  有题目标时候需要部分回滚 node 的 kubelet,当出现全局性风险的时候需要全量回滚 master 和周边组件。
  滴滴,从计划可落地以及本钱角度终极拔取了原地升级万一失控了怎样办,万一回退不乐成怎样办?
至于为什么采取原地升级计划,估量还有很多细节我们不得而知,可是此种方式确切有点激进,一旦出现题目就很难处置惩罚。

5.k8s激发的思考:举一反三,怎样制止再次出现


  • 没必要为了炫技利用最新技术,固然k8s容器编排技术很新,能处理很多微办事安排的题目,可是现在的k8s很是重,对运维技术要求很高,一旦出现题目就很难明决。适当的技术选型才是最好的,对于一些QPS不是很高且对可用度要求不是很高的场景,一台高性能办事器上用个Docker充足了,以致有些场景Docker容器都没必要用,一个Tomcat就处理了
  • 鸡蛋不要放到一个篮子里,生产情况多集群安排,照旧有必要的,即使是原地升级,灰度可以按生产集群灰度,灰度集群有题目此外一个集群还能顶起来。
  • 故障演练,常常故障演练都是部分、某些模块举行停机演练,集群级别、机房级别故障演练的可以放置,究竟是百姓级利用。

6.近段时候其他平台崩溃回首


  • 10月23日语雀(在线文档编辑与协同工具)发生办事器故障,在线文档和官网现在均没法翻开。当日 15 时,语雀公布官方声明称,“现在因收集故障,出现没法拜候的情况。此故障不会影响用户在语雀存储的数据,不会引发数据丧失,我们正在垂危规复中,再次抱歉给你带来的损失。”
  • 11月12日下战书5点多,阿里云出现很是,随之“淘宝又崩了”“闲鱼崩了”“阿里云盘崩了”“钉钉崩了”等话题相继登上微博热搜。原因原由是2023年11月12日17:44起,阿里云产物控制台拜候及API挪用出现出现利用很是,阿里云工程师正在垂危参加排查。当天早晨7点20左右规复一般。
  • 阿里云第二次发生在11月27日。阿里云声明称11月27日09:16起,阿里云监控发现北京、上海、杭州、深圳、青岛 、香港以及美东、美西地域的数据库产物(RDS、PolarDB、Redis等)的控制台和OpenAPI拜候出现很是,实例运转不受影响。经过工程师垂危处置惩罚,拜候很是题目已于当日10:58规复。
不停频发的宕机变乱,警悟着大家:技术风险保障和高可用架构设想很是重要,确保数据备份、系统容错本事,如增加存储系统的异地灾备,实现快速规复,并举行定期的容灾应急演练,缩小运维行动灰度范围。此后,我们也要增强运维工具的质量保障与测试,根绝此类运维 bug 再次发生。

免责声明:本文章来自网友分享,假如加害了您的权益,请联系我们,我们会实时删除侵权内容,感谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?加入我们

x

使用道具 举报

您需要登录后才可以回帖 登录 | 加入我们