崩上热搜，网易云音乐回复：没有删库，更没有跑路！

“网易云服务器炸了，502 Bad Gateway，不能听歌了……“

19日下午2点半，笔者所在的听歌群异常热闹炸了，不少人惊呼：快快快，网易云音乐听不了歌了。

于是顺手打开电脑上的网易云音乐，结果显示网络故障：

除了 APP 无法正常使用外，网页版的搜索、个性化推荐、歌曲播放等也都失败。

官方回复：基础设施故障

面对突然其来的故障，网易云音乐官方迅速回应：“因基础设施故障，导致网易云音乐各端无法正常使用，我们正在加紧修复，对此我们深感抱歉。”尽管官方已经采取措施解决这一问题，但在发稿时（已经2个小时过去了），网易云音乐的 APP、网页端仍未能恢复正常服务。

对此有不少网友猜测，难道又是删库跑路？也有技术专家怀疑与Kubernetes、数据库等技术故障有关。

针对“网易云音乐开发者删库跑路”传闻，网易云音乐官方称：“没有删库，没有跑路，正在加速修复”。今天稍早云音乐曾回应：“目前故障与机房无关，内容有失实”。

技术越来越成熟

但为什么阻止不了宕机？

就在本月，就有微软必应全球宕机、ChatGPT 宕机两小时等新闻，如今，即使互联网相关技术已经迭代多轮，却仍然存在许多大规模以及时间长的宕机事件发生。

针对这类问题，在CSDN之前报道的《“一天宕机三次”，为什么高并发这么难？》一文中提到，可以从两个方面进行解析：

• 一方面故障是不可避免的，有人为的故障（人是容易出错的——Human Error）和非人为的故障（机器 Failure）。这些是无计划的停机，还有有计划的停机，如发布新系统、升级维护、更新硬件等。这也是为什么行业中即使部分公司做得再好也只能说自己能做到多少个 9，而非 100% 的主要原因。

当前，我们所能努力的就是尽可能地做到多少个 9，这其中需要很强的技术实力支撑。

级别	可用性级别	通俗说法	年度停机时间	配套措施
基本可用性	99%	2 个 9	3d-15h-39m-29s	服务在一个数据中心里有冗余，简单基础的自动化运维
高可用性	99.9%	3 个 9	8h-45m-56s	大量的自动化故障工具，以及各种控制调度系统等基础设施要做好
具有故障自动恢复	99.99%	4 个 9	52m-35s	本地多机房（像 AWS 一样每个地方都有三个可用区）
极高可用性	99.999%	5 个 9	5m-15s	远程多机房，异地多活

• 另一方面，从分布式架构设计来说，世界上的软件都是有故障的，当故障发生时，大家首先希望故障不要蔓延开，能够控制得住，其次还希望故障的时间越短越好，不要太长。

然而，架构系统也有很多的依赖，如基础设施 DNS、CDN、运营商、机房等等，想要实现稳定，需要大家一起实现。“这个世界上不可能存在一种 100% 稳定的系统”。

能学习到新知识、产生共鸣，解答久困于心的困惑，这是《新程序员》的核心价值。欢迎扫描下方二维码订阅纸书和电子书。