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

故障经过 故障期间，网易云音乐客户端可以正常播放离线下载的音乐，但访问在线资源会直接提示报错，网页版则直接出现 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》中就提到过这一点：