滴滴2023.11.27P0级故障技术复盘回顾（k8s的的错？）

本文从滴滴官方恢复及技术公众号带大家从技术角度复盘这次事故

目录

1. 背景

2. 滴滴官方消息

3. 问题分析及定位

4.网传的k8s及解析

5.k8s引发的思考：举一反三，怎么避免再次出现

6.近段时间其他平台崩溃回顾

---

1. 背景

11 月 27 晚约 10 点，滴滴打车遭遇大范围技术故障。用户在使用滴滴的应用程序及小程序时遇到诸多问题，包括叫车功能反应迟缓、无法使用青桔单车扫码功能，以及领取打车优惠券功能失效。直至第二天早上，滴滴发文已恢复正常。

根据微博反馈发现了如下问题：

• 网络加载异常，无法排单；

• 数据紊乱，一个订单被派到 4 个司机订单中；

• 数据展示、数据状态有误，订单取消、订单支付都出现问题；

• 排单逻辑出错，司机接单到 两千公里以外的单；

• 订单流水出错，8 公里显示收费 1540 元；

• 整体问题，连带滴滴、小桔充电、滴滴加油、青桔单车都出现问题；

• 滴滴内网问题，员工无法正常使用内网相关服务；

至此，滴滴“喜提”微博热搜

2. 滴滴官方消息

3. 问题分析及定位

11月29日，滴滴出行再就27日夜间系统故障致歉，提出了相应的补救措施和补偿方案。并公布了本次事故的初步调查结果：起因是底层系统软件发生故障，并非网传的“遭受攻击”。

本次事件中，平台功能几乎全面瘫痪，仅网约车服务功能恢复时长近12小时，可以猜测不是某一个软件功能的bug，否则影响不会这么广，恢复也不会这么慢。滴滴官方也发文说明是底层系统软件的发生故障所以排除了服务器硬件的问题，所以可以猜测为云服务器基础底层软件的问题。

滴滴拥有庞大的业务线，其底层系统由复杂的软硬件构成，其中包括服务器、网络设备、数据库等等重要组成部分，任何一个环节出现故障，都有可能导致整个系统崩溃，用户无法正常使用服务。

360 安全专家认为，滴滴闪崩背后的技术原因可能有六种：

1. 系统更新升级过程中出现了编程错误、逻辑错误或未处理的异常情况：一般情况下，互联网厂商发布更新都会在晚上，与滴滴发生故障的时间也能对应，当然业务升级维护是放量更新，但现在滴滴全平台、全业务都故障了，说明肯定是他 “家里” 的问题。
2. 服务器故障：比如滴滴的核心机房，可能恒温恒湿环境出了问题，导致服务器过热、CPU 烧了，或者核心机房所在地发生了自然灾害如地震、洪水、海啸等，这种情况下，硬件需要重新更换，里面的服务软件也需要重新配置，恢复周期相对较长，但这个可能性比较小。
3. 第三方服务故障：滴滴的后台架构可能使用了第三方服务或者组件。如果第三方出了问题，也可能会影响滴滴的正常运行。但出于安全性考虑，滴滴可能不会将核心业务托管给第三方，不过这个可能性也较小。
4. 其他网络安全问题（由于滴滴已经官方说明不是受到攻击，所以均可排除其他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引发的思考：举一反三，怎么避免再次出现

1. 没必要为了炫技使用最新技术，虽然k8s容器编排技术很新，能解决很多微服务部署的问题，但是如今的k8s非常重，对运维技术要求很高，一旦出现问题就很难解决。适合的技术选型才是最好的，对于一些QPS不是很高且对可用度要求不是很高的场景，一台高性能服务器上用个Docker足够了，甚至有些场景Docker容器都没必要用，一个Tomcat就解决了
2. 鸡蛋不要放到一个篮子里，生产环境多集群部署，还是有必要的，即使是原地升级，灰度可以按生产集群灰度，灰度集群有问题另外一个集群还能顶起来。
3. 故障演练，往往故障演练都是局部、某些模块进行停机演练，集群级别、机房级别故障演练的可以安排，毕竟是国民级应用。

6.近段时间其他平台崩溃回顾

1. 10月23日语雀（在线文档编辑与协同工具）发生服务器故障，在线文档和官网目前均无法打开。当日 15 时，语雀发布官方声明称，“目前因网络故障，出现无法访问的情况。此故障不会影响用户在语雀存储的数据，不会引起数据丢失，我们正在紧急恢复中，再次抱歉给你带来的损失。”
2. 11月12日下午5点多，阿里云出现异常，随之“淘宝又崩了”“闲鱼崩了”“阿里云盘崩了”“钉钉崩了”等话题相继登上微博热搜。原因是2023年11月12日17:44起，阿里云产品控制台访问及API调用出现出现使用异常，阿里云工程师正在紧急介入排查。当天晚上7点20左右恢复正常。
3. 阿里云第二次发生在11月27日。阿里云声明称11月27日09:16起，阿里云监控发现北京、上海、杭州、深圳、青岛 、香港以及美东、美西地域的数据库产品（RDS、PolarDB、Redis等）的控制台和OpenAPI访问出现异常，实例运行不受影响。经过工程师紧急处理，访问异常问题已于当日10:58恢复。

不断频发的宕机事件，警醒着大家：技术风险保障和高可用架构设计非常重要，确保数据备份、系统容错能力，如增加存储系统的异地灾备，实现快速恢复，并进行定期的容灾应急演练，缩小运维动作灰度范围。今后，我们也要加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生。