我们能从网易云音乐故障中学到什么？
今天下午 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》中就提到过这一点：
