作者：孙益远 已同意转载

此贴如果被删，说明网易不正视问题。

本人是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号折腾上线再说吧。

反正没得事，补偿没拿到，人呢？

假若说发生断电的是运行中的业务数据库而不是备份数据库，根据网易的公告，15：20分断电，现在也把数据回档到15：20分，说明网易对数据库的备份并不是简单的一天一备，而是实现了分钟级甚至秒级的备份。那么为什么在断电恢复当时不直接调用备份进行回档？而是要继续用那个损坏的数据库重新上线？毕竟当时立即选择回档，网易，暴雪，玩家付出的代价都比现在小得多。
借用《重返危机现场》的开场白：事故不会凭空发生,而是关键事件的连锁反应
电源，服务器，存储，备份，重重保护下的数据发生这种事故。不是单一因素所能造成，必然是多个环节发生了一连串的故障，巧合和失误。网易公告的断电也许只是压倒骆驼的最后一根稻草。

抛开断电说，推测故障的另一种可能
之前暴雪招聘DBA Lead，要求如下
深入理解Oracle内部原理，熟练掌握RAC和ASM，熟悉Golden Gate复制，熟悉Linux脚本编程。
那么暴雪的数据库架构就出来了
数据库：Oracle，RAC（实时应用集群）+ASM（自动存储管理）
系统：Linux
同步：Golden Gate（通过读取日志进行数据库同步，可以实现低于1秒的实时复制）
故障时间在14日，但是可能在15：20分之前发生
故障应该是数据库坏块，坏块不严重时，oracle可以带病运行。
数据库没有容灾，不能切换到备用数据库运行。（“备用”和“备份”是两个概念）
网易为了业务不中断，决定带病运行，并尝试在线修复（故障后游戏仍然可以运行，说明故障不严重）。这一决策的失误导致最终的大麻烦。
日志可能有损坏，导致数据复制也出现问题，没办法用备份修复。（所谓的“备份出问题”）
数据库坏块在线修复失败，且故障在扩大。准备将业务停止，修复坏块（停机8小时）
结果停机维护遇到相当大的困难，延长停机时间
最终，修不好了，回档
坏块的原因，比起停电，个人认为磁盘（不要和我说什么SSD，这里的磁盘是指的所有可能的存储介质）故障的可能性更大。
根据停机时间，推测数据库体积在8-12TB的样子。
所以，故障发生时，网易不愿意中断业务，选择了风险更大的带病运行。并最终导致2天的数据回档。
也许以后再出类似故障网易会选择停止业务，立即回档。
公司体量大，不代表不会出问题，比如这个

看来贴吧只适合水贴，不适合技术讨论

有人看的话，我补充点，网上找的。

运营事故分类：
1、官方服务类：
1服务器故障。服务中断，玩家无法进入游。
2缺缓存磁盘问题，玩家数据丢失。
3游戏BUG导致玩家无法正常游戏。
2、外挂，作弊类：
1) 大批量玩家使用外󰜵挂，作弊的方式获得了与实际能力不符的奖励，物品，严重破坏游戏平衡。
2) 对其他免费玩家，正常渠道的付费玩家造成了严重的不良影响。
3) 不良的情绪传染，导致很多玩家停止付费，对游戏的官方失去信心。

1、判断什么问题：
如果可以根据内容定性为运营事故及时通知相关人员，如果不确定，可以与运营部门沟通确定问题严重性。
2、通知相关负责人：
项目经理，技术经理，运维经理。如果无法准确描述具体内容，直接通知本体的负责人亲自查看问题

3、统计问题严重程度：
　　客服，技术，全方位出动。需要明确的信息。
　　1)出现问题的玩家群体。
　　2)不同玩家问题是否一致，或者分不同情况的问题。
　　3)导致产生了那些损失。
　　4、根据问题影响玩家群体数量，判断是否发公告：
　　1)个别人发生情况，虽然严重，但是小范围，不适宜公开发公告，避免让更多玩家知道造成不必要的麻烦。所以如果玩家有询问，单独告知。
　　2)如果玩家无法登陆，需要公告告知玩家情况。
　　3)如果玩家数据丢失，需要告知玩家正在处理，处理完成后会给予大家统一补偿。

5、根据问题严重性决定停服修复或者在线更新：
　　1)修复过程中要保持与玩家的沟通，不要让玩家盲目的等待。
　　6、修复后的补偿(服务类运营事故一定有补偿，作弊外挂类通常没有)：
　　1)问题修复后，首先确定是否一定没有问题了，不要着急发出补偿，可以等到第二天，确定没有问题后给予玩家补偿。避免刚给过补偿，又再次出现问题。
　　2)基本补偿方案：所有玩家统一补偿。活动期间消费过的玩家额外补偿，如果数据丢失，则应当补偿这些消费过的玩家所有购买的物品。
　　7、转移玩家注意力：
　　1)一个不大不小的运营事故，都会造成数据的影响。在确定没问题后可以尽快制定一些简单的游戏方案，活跃活动来提升玩家的游戏活跃度，转移玩家注意力。

　　外挂作弊类问题需要注意的内容：
　　一些游戏玩家群体足够大以后，如果运营方足够硬气，那么就可以在一些问题上比较爽快。例如直接封号。在这个前提下，其实以下内容帮助就不大，可以选择性忽略。

这次网易的炉石传说运维人员估计要换人