炉石传说 服务器 维护,炉石传说超长维护究竟发生了什么？告诉你真相。

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

本人是IT系统集成从业人员，主专业是网络，其他方向略懂。

网易对外发布的信息非常有限，我的回答是在已有信息的基础上做的猜测，不代表事情的真相。

摘要：

可能性1：

这是一起运维人员操作失误与玩忽职守的责任事故。

可能性2：

发生小故障不愿停机维护，带病运行导致事故扩大。

正文：

从网易的官方声明中得知14日下午15点20分，数据库断电导致损坏。

说真的，网易要说起火说不定我还信了，首先这种数据库肯定不是放在一般的服务器里，而是存储在专业的磁盘阵列柜或者说是专业存储服务器中。这种专业存储设备我还没听说过哪家不是用的双电源，一般都是一路市电一路UPS。高档点的机房都是两路独立UPS。(网易当年魔兽的服务器规模甚至超过暴雪，买不起两路独立UPS？啥，你说两路UPS同时都挂了，三石买彩票去吧)

高档点的存储还有3电源4电源内部还带一个应急电池的，虽然电池就够个几分钟，接个备用电源也还是来得及的。

退一万步讲，既然14日下午数据库已经断电故障了，那15日16日游戏还在运行，还可以玩，那么这个数据哪来的？那么本人在此做一个大胆的推测：故障的数据库是备份数据库

既然16日还在运行，那么为何要回档到14日？16日的数据当真是找爸爸去了？

另外有个回答是封号失误造成滥杀无辜，那么我想封号记录应该是有记录封号时间的(如果没有，那是数据库结构设计的不合理)，重做今天的封号就好。即使是真的没有封号时间的记录，需要把之前的封号脚本全部重跑一遍，对于一个商用数据库，每秒1万次的update操作应当是可以达到的。那么24个小时就足够封掉8.6亿个账号，炉石有这么多玩家？

即便真的是操作不当丢失了16日的数据，那么还有一个手段可用：数据库审计。

数据库审计是串接(也可以旁路)在数据库前面的硬件设备，记录了对数据库的每一次操作，拿着14日的数据和审计日志一步步还原，也可以完全还原数据。如果说这种重要的数据库不弄个数据库审计，网易还真是心大。特别是携程删库事件之后。

无责任推测事件过程：

N久以前，备份数据库的某一路供电坏了，管理员eat sh_t去了没发现。

14日下午，备份数据库的另一路电源也挂了，管理员又没发现。(我为什么要说又呢？)

17日维护，以为数据已经自动备份，没有检查备份状态，也没有单独手动备份，直接开搞。‘结果操作失误，数据被搞坏了。

回头去翻备份，结果发现备份数据库14号就已经挂掉了。没有单独手动备份，没有数据库审计的日志。折腾了快两天被弄坏的数据也未能复原。没办法了，再不上线就要上吊了。回档到14号折腾上线再说吧。