我们能从网易云音乐故障中学到什么？

今天下午 14:44 左右，网易云音乐出现 不可用故障，至 17:11 分恢复。网传原因为基础设施/云盘存储相关问题。

---

故障经过

故障期间，网易云音乐客户端可以正常播放离线下载的音乐，但访问在线资源会直接提示报错，网页版则直接出现 502 服务器报错无法访问。

在此期间，网易 163门户也出现 502 服务器报错，并在一段时间后 302 重定向到移动版主站。期间也有用户反馈网易新闻与其他服务也受到影响。

许多用户都反馈连不上网易云音乐后，以为是自己网断了，卸了APP重装，还有以为公司 IT 禁了听音乐站点的，各种评论很快将此次故障推上微博热搜：

期间截止到 17:11 分，网易云音乐已经恢复，163 主站门户也从移动版本切换回浏览器版本，整个故障时长约两个半小时，P0 事故。

17:16 分，网易云音乐知乎账号发布通知致歉，并表示明天搜“畅听音乐”可以领取 7 天黑胶 VIP 的朋友费。

---

---

原因分析

在此期间，出现各种流言与小道消息。一眼假的有网易总部着火🔥 （老图），TiDB 翻车（网友瞎编），下载《黑神话悟空》打爆网络，以及程序员删库跑路等。但也有先前网易云音乐公众号发布的一篇文章《云音乐贵州机房迁移总体方案回顾》，以及两份有板有眼的网传聊天记录，可以作为一个粗略参考。

网传此次故障与云存储有关，网传聊天记录就不贴了，可以参考《网易云音乐宕机,原因曝光!7月份刚迁移完机房，传和降本增效有关。》一文截图，或者权威媒体的引用报道《独家｜网易云音乐故障真相：技术降本增效，人手不足排查了半天》。大体意思是这次故障和云存储，降本增效裁员有关。

我们可以找到一些关于网易云存储团队的公开信息，例如，网易自研的云存储方案 Curve 项目被枪毙了。

查阅 Github Curve 项目主页，发现项目在 2024 年初后就陷入停滞状态：

最后一个 Release 一直停留在RC没有发布正式版，项目已经进入缺乏维护的死亡状态。

Curve 团队负责人还发表过一篇《curve：遗憾告别 未竟之旅》的公众号文章，并随即遭到删除。我对这件事还有些印象，因为 Curve 是 PolarDB 开源版推荐的两个共享存储方案之一，所以特意调研过这个项目，现在看来……

---

经验教训

关于裁员与降本增效的老生长谈已经说过很多了，我们又还能从这场事故中学习到什么教训呢？

第一个教训是，不要用云盘跑严肃数据库！在这件事上，我确实可以说一句 “ Told you so” 。底层块存储基本都是提供给数据库用的。如果这里出现了故障，爆炸半径与 Debug 难度是远超出一般工程师的智力带宽的。如此显著的故障时长（两个半小时），显然不是在无状态服务上的问题。

第二个教训是 —— 自研造轮子没有问题，但你要留着人来兜底。如果卸磨杀驴降本增效把人一锅端了，那么遇到问题找不到人干着急也是活该。

第三个教训是，警惕大厂开源，特别是…。作为一个底层存储项目，一旦启用那就不是简单说换就能换掉的。而网易毙掉 Curve 这个项目，所有这些用 Curve 的基建就成了没人维护的危楼。Stonebraker 老爷子在它的名著论文《What Goes Around Comes Around》中就提到过这一点：

---

曾几何时，“上云“近乎成为技术圈的政治正确，整整一代应用开发者的视野被云遮蔽。就让我们用实打实的数据分析与亲身经历，讲清楚公有云租赁模式的价值与陷阱 —— 在这个降本增效的时代中，供您借鉴与参考。

点一个关注 ⭐️，精彩不迷路