大家好呀，我是楼仔。

我之前在滴滴工作过一年多，也深度参与过滴滴十一前夕的重保，对于滴滴崩了的消息，估计很多同学都看到了，这里也想和大家简单聊聊。

回顾来看滴滴历史上类似故障情况在 2022 年 9 月 22 日也出现过，当日滴滴官方微博致歉称由于机房网络故障，导致滴滴部分服务受到影响。

然而像昨天这样大面积、长时间的故障，滴滴史上少有。

01 事件回顾

11月27日，全国多地滴滴用户反映，滴滴出行 App “崩了”，出现不显示定位、地图无法加载、扣费异常、无法打车等情况。

27 日深夜，滴滴出行对此作出回应：“非常抱歉，由于系统故障，今天晚间滴滴 App 服务出现异常，经技术同学紧急修复，目前正陆续恢复中。”

28 日早上 7 点 30 分许，滴滴出行再度道歉，称经技术团队连夜修复，滴滴网约车等服务已恢复，用户可下载滴滴 App 使用打车服务。

骑车等服务还在陆续修复中，所有可开锁或未关锁的青桔车辆均可免费骑行。

滴滴出行发文后，仍有大量用户反映滴滴 App 还是存在问题。

02 可能原因

滴滴官方还没有披露原因，科创版日报记者采访业内人士，推测原因：

下面是访谈记录：

个人感觉外部攻击的概率应该不大，大概率应该是基建服务挂了。

然后很多同学说，和 “降本增效” 有关。

滴滴的“减员增效”，裁减了多少人？

21 年底，滴滴员工总数 24396 人，22 年底是 20870 人，累计减少 3526 人，裁减比例是 14.4%。

相比阿里云之前裁员 7%，滴滴裁员比例的确有点大。

而且，滴滴研发人员占员工总数比重是 40%，光 2022 年一年，就裁掉 1090 研发人员。

然后也有一些其它博主经过详细计算，预计 2023 年，滴滴研发人员减少大概 1200-1400 人。

以上数据来源：滴滴系统崩了，跟裁员 14% 有关系吗？

对于这次的损失，据滴滴出行此前公布的 2023 年第三季度财报显示，单季度中国出行业务总交易额为 725 亿元，日均单量达到 3130 万单。

而以此次“崩了”的故障时长计算，估计将会让滴滴损失过千万的订单量和超 4 亿的交易额。

对于滴滴这次崩了，除了技术本身的原因，可能还是多少和降本增效有关。

这里的降本，很多同学可能只会理解为单纯的裁员，其实降本，还包括服务器费用的降本，这个费用占比通常也会非常高。

我是 18 年在滴滴呆了一年，做的是滴滴搜索，在滴滴高速扩张的时候，基本不用考虑服务器费用。

我记得当时整个搜索相关的机器就有几百台，仅仅一套 ES 集群，就有十几台机器，2 套就需要二十几台，而且每台的机器成本非常高。

但是在 18 年中下旬时，滴滴也开始考虑降本，首先是缩减服务器成本，当时滴滴全部用的是物理机，由于是双机房，费用加倍。

后来经过一轮物理机缩减后，为了继续降本，服务陆续上云（不过后来是否上云，我就不清楚了，因为当时离开了滴滴。）

虽然这次不是流量高峰将机器打挂，但是当用户发现请求失败时，就会一直尝试，请求数量就会爆发性增长，再加上早高峰，流量就非常高了，缩容后的服务，没有提前进行库容，有的可能会扛不住。

然后是关于人员的裁减，这个影响面就很好理解了。

不过作为一个国民级的应用，崩了 12 个小时，无论什么原因，确实很不应该。

具体原因还需要等滴滴官方解答，同时作为研发，我也整过严重的 P0 线上事故，希望滴滴的研发小伙伴能挺过这波难关。

最后，把楼仔的座右铭送给你：我从清晨走过，也拥抱夜晚的星辰，人生没有捷径，你我皆平凡，你好，陌生人，一起共勉。