昨天，网易云音乐出了个重大线上事故，产品持续宕机两个多小时，所有终端都无法正常使用。

这事儿很快就上了热搜，打开网易云音乐 PC 页面显示「服务器拥挤」，App 显示「请求超时」。

网站页面显示的是 500 错误，但通过浏览器控制台可以看到，请求反馈状态码是 502。

简单说，就是网易云音乐的服务器挂了。

为了稳定局面，网易云音乐团队很快在微博上发了声明，给出的理由是「基础设施故障」。

本以为问题会被很快修复，没想到，这一宕机就是两个多小时。

从下午三点一直到五点多才开始部分可用，且还不是很稳定，很多人在线围观网易云音乐救火。

这下，P0 级重大线上事故算是坐实了。

那么，这场堪称灾难级的线上事故到底是怎么产生的呢？

对此，网上有很多猜测，有说程序员删数据库跑路的，有说服务器机房着火的，还有说被黑客攻击的。

在我看来，这些原因的可能性都不大。

首先，作为如此大体量的一款产品，核心数据库系统权限管理是非常严格的，轻易被个人滥用的概率极低。

况且，具备这种权限的个人在公司内职位都很高，即便遇到不顺，也不会拿前途命运去赌，这也涉及到了法律层面。

另外，稍微成熟点的产品都会做容灾方案，对核心数据更是会做多地备份。即便出现数据被删的情况，也可以在短时间内恢复。

其次，服务器机房着火属于物理灾难，但是这种体量的产品都会采用分布式架构，一个机房出现故障也会有其他机房服务器顶上，这一点运维也可以很快响应。

至于黑客攻击，因为不在现场，而且官方也不会明说，所以只能说是一种猜测。

按照官方给出的说法，基础设施故障，那就是服务器、操作系统、网络、存储硬盘、通信光缆等方面的问题了。

我记得前几年微信就短暂宕机过，后来原因是因为修路把光缆给挖断了，不过很快就恢复了。

对于这次网易云音乐两个多小时的宕机，我觉得可能还是因为基础设施故障导致服务起不来导致的。

这里说一个简单的技术知识。

我们所使用的产品其实都是计算机软件，软件就是一个代码包，里面包含了所有的代码逻辑以及资源文件，它们组成了产品功能。

开发完成后的产品会被打包成一个软件包，这个包会运行在一个系统容器中，这个容器可以理解为软件运行环境。

同时，这个容器还需要运行在操作系统上，操作系统则运行在计算机硬件，也就是服务器上。

搞明白了这个逻辑结构就知道，如果只是软件产品本身的 bug，那修复后重新打包上传到运行容器即可。

如果是容器的问题，也可以通过重启来判断和定位问题，耗时也不需要这么久。

唯独基础设施（操作系统、硬件、网络）层面的问题，搞定起来就比较棘手了。

就好比你的电脑突然蓝屏，而且重启后还是蓝屏，怎么弄都不好使，这下问题就麻烦了。

此时，只能从源头开始寻找和定位问题，耗时自然很长。

当然，这些都只能是推测，除非官方给出具体详细的事故说明，那才是可以被我们看到的真相。

用户使用产品通常是按照下面这个逻辑进行的，排除用户设备问题、网络运营商问题、以及软件 bug 问题，那只能是服务器异常了。

到了下午 5 点多钟，网易云音乐恢复了部分使用，而且不同产品模块之间也是先后可用。

也有用户发现，恢复后时而好用，时而又不好用。

实际上，这是在等 CDN 网络全部重新循环一遍。至于 CDN 是什么，我在我的书以及技术专栏里都有讲解。

事情终归是出了，网易云音乐团队惯例也一定会给出用户补偿。

很快，官方就在微博发声了。

从字里行间可以看出，真是满满的求生欲啊！

不过说实话，7 天会员权益未免有点抠搜，好歹也来个月度会员啊。

不仅诚意更足，对于后续转化为正式会员岂不是更为妙哉？

印象中上一次出类似大事故的产品应该是阿里旗下的「语雀」，不过他们宕机持续时间更长。

作为补偿，语雀也送出了 6 个月的会员服务，整整半年。

话说回来，对于这类故障负责的团队和个人来说，可以说是年度惊心动魄了，年终奖什么的就可以放心了。

我说的放心，是大概率没了。

最后，产品无小事。

················· 唐韧出品 ·················

安可时刻

我在产品训练营里说过，产品是由信息、交互、功能、业务、商业共同组成的集合体。

既要理解微观层面的产品，也要建立对产品的宏观认知，这样产品体系才完善，这是需要学习的。

广州和深圳产品训练营正在招募中，要报名的联系我：tangren0517（加我微信）

最后开心一下，这是网友们脑补的本次网易云音乐故障原因。。。