滴滴崩溃超过12小时,这世道是怎么了

从 2023 年 11 月 27 日晚上 10 点左右截止 2023 年 11 月 28 日中午 12 点期间,滴滴打车 APP、小程序得常用功能终于相继恢复正常。放眼整个事件来看,滴滴打车得故障时间已然超过 12 个小时,整个事件放在 2023 年得互联网来看真是相当炸裂。

回顾昨晚,原本我在写下 降本增笑,滴滴打车也崩了 这篇文章后就入睡了,想着今天晚上滴滴得程序员可有得忙了。

没想到的是 28 号 7 点起来 9 点到公司发现滴滴打车 APP 昨晚出现的绝大部分故障任然还在,骑行功能无法使用、底部标签栏车主、领打车费等还是无法打开,查看微博,滴滴官方也是在 7 点 33 分左右对昨晚事故做出了第二次回应,

也就是说 28 号早高峰上班期间,全国上下不知有多少用户任然受到此次事故影响导致无法正常打车、骑行等。进一步也可能会导致这些用户的全勤不保。

心痛一波这些用户 ❤️‍。

我当时就在想,滴滴得程序员昨天晚上去干什么了?一晚上都修不完这些 bug?对于大厂的高级研发,架构师来说,线上系统发布出现问题时的回滚流程应该是一套很成熟的体系,但是万万没想到这个事故竟然能持续一晚上还没结束。

没想到 2023 年的互联网还有这么到超出我对大厂认知的事情在不断发生 😔。

事故影响最后一直持续到 28 号 12 点左右才相继结束。

那么这里面到底出了哪些问题?作为一个互联网从业者,我给大家分析一下这里面可能存在的原因。

事故分析

降本增效

一个词概括 2023 年的互联网行情就是 "降本增效" 。疫情三年可以说是导致本就难做的实体行业是难上加难,但确给互联网行业带来了一大波用户增长。可谁曾想到来都 2023 年初,互联网行业可以说是寸草不生,直接进入存量内卷时代,各家都不在出新产品,开始巩固护城河。

记得三年前阿里的市值巅峰是 8000 亿跌倒现在不到 2000 亿,想想这里面市值缩水了 4 倍,想想 8000 亿市值招了多少人,现在不到 2000 亿,那又需要裁多少人嘞?年初阿里裁撤 15000 人的消息还历历在目。虽然这里面有全球大环境、国家政策以及市场竞争多众多因素导致。但是裁员时,资本又不会管你一个普通底层干活的技术员工干了多少年,技术上做出了多少贡献,他只会看优化后的财务报表有多么好看。

回看滴滴这几年经历了什么,2021 年 6 月 30 日 滴滴是美国纳斯达克上市的,估值最高达到 800 亿美元,随后 2021 年 7 月 4 日,国家网信办发布公告称,"滴滴出行"APP 存在严重违法违规收集使用个人信息问题,依据相关法律规定,通知应用商店下架"滴滴出行"APP,滴滴宣布暂停新用户注册。2022 年 7 月 21 日滴滴被处以罚款 80.26 亿人民币,2023 年 1 月 16 日 滴滴宣布整改完毕,恢复新用户注册,整个事件才告一段落。

可以说滴滴也为自己的违法行为付出了代价,这里面滴滴为了能活下去裁撤了公司多少人员我们也不得而知。但是影响了滴滴打车系统的稳定性是肯定的,不然也不会有今天这件事情。

降本增效、降本增效,今年提到互联网企业就离不开这四个字。具体怎么执行嘞?

何为降本:裁掉底层干活的人,留下一堆中层领导,相信这是大部分互联网公司的降本举措。

何为增效:一个人干两个人的事情,这就是增效,相信这也是大部分互联网公司的增效举措。

试想一下,假如我是一个互联网大厂开发,周六领导开会整个部门被裁,周一上午 HR 宣读通知,下午要求走人,只留下我一人维护老系统。你说我咋接?这系统是整个部门同事多年以来共同合作开发维护,我也只是负责其中一个模块。现在要我接收全部,能不出问题吗?

OK,进一步来说,假如某个模块出问题了我找谁,或者谁担责,我只能向上反馈。领导一顿 PUA 教育,最后还是底层干活的我默默承受了一切。

结合滴滴崩溃这件事来说,会不会是某个人留下来的隐秘 bug 终于在 27 号晚 10 点爆发,而留下来的程序员不知道如何解决,而且当时半夜 12 点想要联系前同事,打不通电话是不是也有可能。这一切的结果叠加也就导致了滴滴此次事故持续事件超过了 12 个小时。

这个事情很难说,因为官方也不可能承认是裁员导致。

底层依赖更新出错

还记得语雀上次事故,事故原因就是运维工具升级报错导致。滴滴这一波会不会也是这个原因嘞?

想一想如果是应用层服务出错,线上环境针对应用服务都有完整的回滚措施。回滚操作一般不会超过 10 分钟,那么像滴滴这样的互联网大厂,就算线上服务真的很多,回滚也不可能超过一晚上 6 个小时吧。所以造成此次事故的元凶就不太可能是应用层服务。

那么造成这次事故的核心原因就只可能是一个平台已经使用了多年的底层依赖,而不凑巧的是昨天晚上某个运维升级了这个依赖导致平台应用服务全面崩溃。

想一想,在我这么多年的互联网从业经验中,一般公司只会针对线上环境针的应用服务做回滚举措。而运维负责的一些平台底层依赖,很少又回滚这一说吧。

所以这个原因是有可能的。

最后聊两句

分析到这里,这篇文章要将的内容也就讲完了,互联网大厂一直把高可用、异地多活、两地三中心这些词语挂在嘴边,但是 2023 年以来,阿里崩了、语雀崩了、滴滴也崩了,可以说互联网大厂 APP 或者服务崩了在今年已经成了一种常态。还是希望大家保持常态,大厂的 APP 也是无数人堆出来,是人就会犯错,习惯就好。

博君一笑

不过在我看了网友评论后,我又觉得合理起来,历来网友的想象力都比较丰富。

相关推荐
Mintopia2 分钟前
光影魔术师的秘密:用 JavaScript 打造软阴影的奇幻世界
前端·javascript·计算机图形学
Mintopia15 分钟前
Three.js 粒子系统:让代码化身奇幻造梦师
前端·javascript·three.js
itwlz37 分钟前
vite配置@别名,以及如何让IDE智能提示路经
开发语言·前端·javascript
lichenyang45339 分钟前
添加按钮跳转页面并且根据网站的用户状态判断是否显示按钮
开发语言·前端·javascript
皮皮高40 分钟前
itvbox绿豆影视tvbox手机版影视APP源码分享搭建教程
android·前端·后端·开源·tv
弱冠少年44 分钟前
golang入门
开发语言·后端·golang
Humbunklung1 小时前
Rust 函数
开发语言·后端·rust
喜欢踢足球的老罗1 小时前
在Spring Boot 3.3中使用Druid数据源及其监控功能
java·spring boot·后端·druid
Hilaku1 小时前
JavaScript 里的 !0、!1 到底是啥?聊聊那些压缩器最爱的“极简写法”
前端·javascript
全栈陈序员1 小时前
前端文件下载常用方式详解
前端·javascript·chrome·ajax·css3·html5·safari