门户网站有哪些类型,中国建盏品牌形象设计大赛公示,佛山市官网网站建设企业,百度推广有效果吗?本文从滴滴官方恢复及技术公众号带大家从技术角度复盘这次事故 目录 1. 背景
2. 滴滴官方消息
3. 问题分析及定位
4.网传的k8s及解析
5.k8s引发的思考#xff1a;举一反三#xff0c;怎么避免再次出现
6.近段时间其他平台崩溃回顾 1. 背景
11 月 27 晚约 10 点#xf… 本文从滴滴官方恢复及技术公众号带大家从技术角度复盘这次事故 目录 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 再次发生。
