炉石宕机运维警示 云和恩墨Bethune助力安全

　　最近暴雪公司和网易的一则声明刷爆了朋友圈，大意就是由于『供电意外中断的原因而产生故障，导致数据损坏』，这样一则公告引发了一系列的猜想，我们在围观时仿佛人人都是诸葛亮，而事实上设身处地，我想在一次负责任的故障考验下，也许很少有人能够幸免。

　　如同阿里云会误删文件、京东会泄露数据、支付宝会被修改密码、携程会大面积瘫痪，在灾难来临之前，谁都会觉得自己是幸运者，而事实上，只是措手不及那次灾难还没有来到而已。

　　先回顾一下《炉石传说》长长的公告，然后我们再基于事实做一下分析吧：

　　首先，关于暴雪的核心数据库架构，不是网友猜测的MySQL(如果是 MySQL 就必然是分布式，不可能全部回档的)，而是Oracle数据库。关键的系统架构如下(部分属于推测)：

　　数据库：Oracle

　　架构：RAC + ASM

　　版本：12.1.0.2 (猜测)

　　节点数：4 (猜测)

　　系统：Linux

　　同步：GoldenGate

　　基于这样一些真实的基础和前提去讨论这次的事故，才更有意义。

　　以下是前一段时间暴雪招聘DBA Lead的条件要求，系统架构由此一目了然：要求深入理解Oracle内部原理、Oracle RAC和ASM技术，熟悉Golden Gate复制，熟悉Linux脚本编程。

　　这些要求就深刻揭示了暴雪核心数据库的体系架构。在Linux上运行的基于ASM存储的Oracle RAC集群，使用OGG复制数据。

　　在招聘中有一个特殊的要求，『Evaluate new releases and features of Oracle DBMS』，评估Oracle新版本和特性的能力，这一独特要求可能和当时要升级核心数据库有关，而升级版本就应该是12c，据此我推测其数据库版本应该已经追到最新版本12.1.0.2，国外的大公司风格基本如此，有了12.1.0.2，肯定不会有人守在12.1.0.1版本上，而且这套中国的系统是部署不久的独立系统。

　　以下就是暴雪对于这个岗位的详细需求：

　　之前在互联网上已经披露了很多信息，包括一次故障的处理流程(来自搜索引擎)：

　　1.9C在一次服务器故障中的说明，下面只列出关键部分

　　08:29 收到EVA存储报警邮件，联系数据中心工程师，联系惠普工程师.

　　08:35 故障应急流程启动,相关人员包括THE9/HP/Blizzard US .

　　15:33 Oracle专家加入故障应急流程

　　15:50 暴雪数据库工程师开始与Oracle专家继续分析故障情况.

　　17:15 暴雪表示暂时还未从他们的admin以及DBA处获得任何有新的消息，他们仍然在研究此故障。

　　当时的数据库运行在HP服务器上(大约2013年)，现在已经迁移到Linux服务器上。

　　此外，暴雪的数据量很大，多年前Oracle 9i 时就是TB级别的数据库了，当然现在中国大陆地区肯定是独立的服务器，但是数据量也绝对会是TB级别的，再加上免费开放的热门程度，我推测两节点的RAC对中国玩家不够尊重，至少应该是4节点的Oracle RAC集群。

　　所以大家可能联想到了2016年年初的另外一则故障，在2016年3月22日，全日航空的故障导致了120个航班取消，据传是4节点RAC集群，由于网络问题导致故障：

　　【导致全日空(ANA)120个航班被取消的票务系统故障是交换机引起的】造成Oracle Cache Fusion的UDP通讯异常，4节点的Oracle RAC无法重组集群。本来交换机是有主备设计的，但是主交换机并未彻底坏掉，而是处于不稳定状态，备用交换机不知道主交换机出了故障所以没有接管。

　　我们再回过头来看暴雪的运维，最终看起来似乎没有找到合适的DBA Leader，所以内部晋升了一位，在LinkedIn上，这些信息是公开的：

　　好了，有了这些事实之后，我们再看公告就会清晰很多了。我们理一下时间轴：

　　1月14日 15：20 (据说)因为供电问题，导致数据库损坏;

　　DBA开始修复，但是发现备份数据库也损坏了;

　　数据库带病坚持工作，DBA同时开始在线修复;

　　1月17日1点开始停机修复，修复预计8小时，未能按照预期时间完成;

　　1月18日18：00发布公告，数据回档到1月14日 15：20，业务恢复;

　　外行看热闹，内行看门道

　　在了解了系统架构之后，从官方的信息里我们能够看到很多事实：

　　第一：故障出现在14日，应当早于15：20，公布时间推移，这是惯例;

　　第二：供电问题可能性不大，如果说成熟运营的IT，还存在单电单点是说不过去的，网易也不允许;

　　第三：数据库损坏应该是坏块，Oracle数据库在出现损坏故障时，仍然能够坚持工作的，应该是出现了坏块，坏块通常被大家疏忽，以为可解，所以拖延成了极慢长的次生故障;

　　第四：暴雪没有ADG的灾备，不可切换，请注意声明中明确说“备份数据库”而不是“备用数据库”;

　　第五：数据库依赖OGG进行复制，这个复制因为某种原因不能用于恢复，极可能因为Redo日志或 Undo 也有损坏，丢失了某些事务;

　　第六：最终坏块问题无法修复，只能选择基于时间点的不完全恢复，放弃了部分事务，也就是数据回档了，这是最无可奈何但是也是保证数据一致性的残酷选择;

　　第七：数据库的坏块，没有影响数据库运行，证明是小范围的损坏，不是文件级别的损失，这应当和存储的相关性更大，写丢失导致了数据块损坏;

　　第八：最初的8小时，是计划恢复部分表空间，但是没有解决问题，最终进行了全库恢复，根据这个停机时间预估数据库整体容量应当在10TB左右;

　　所以我们大胆推测：是因为存储故障导致了RAC集群写数据丢失，最终选择不完全恢复，放弃了部分数据。

　　DBA第一守则：备份重于一切

　　如果大家还记得我曾经写下的DBA守则，没有备份对于DBA来说将会是致命的，而如果没有有效备份，那么备份也只能是心灵安慰。不论如何，备份至少可以给我们重来一次的机会，暴雪这一次最终救命的就是备份。虽然是回退到了14日。

　　既然备份这么重要，国内数据库的备份情况如何呢?云和恩墨白求恩平台最近发布的《中国2016年Oracle数据库运行现状报告》显示，有完整RMAN备份的数据库不到20%，24%的数据库甚至处于非归档模式下。

　　下图来自报告数据，可以看到其实国内的数据库的DG的使用率其实并不高，仅有21%：

　　Bethune 平台可以帮助大家检查RMAN备份完整性，Dataguard同步及时性，假期来临之前强烈推荐大家为数据库做一次健康检查。

　　关键节点是什么?

　　回顾一下，数据库带病坚持工作，这是整个案例最核心的一个决策，也就是说，通过在线运行，同时修复问题(坏块)，向前走。

　　这也是一个艰难的决策，如此可以减少业务的中断，但是面临的风险就是可能最终数据不一致，需要回退或者承受复杂的校验工作。

　　大家可以想想我们面临这样的工作会如何处置?

　　我就此访问了浙江移动王晓征王总，他表达了他的观点：

　　我觉得得按照业务特性，事先约定优先保A(可用性)还是保C(一致性)，如果没约定的话，如果我指挥，我会临机进行决断。

　　我非常赞同这一观点，有了事先约定，应急处置时才能有准则，不出现重大偏颇。

　　要一致性还是连续性?

　　如前所述，每一个DBA团队都应该有一个准绳，那就是在关键时刻，要保障一致性(准确性)还是连续性?

　　对于金融机构，毫无疑问，要保证数据库的一致性，在遇到故障时，可以果断中断业务提供，进行数据恢复或者修复;

　　而对于互联网业务等，可能连续性就更为重要，类似携程的业务，中断几天的服务是不可想象的;

　　王晓征就此总结说，在运营商系统建设的过程中，最初觉得业务连续性最为重要，但是当这些问题已经被较好的解决之后，现在觉得数据的一致性变得更重要起来，所以不同系统在不同阶段，就会有不同的取舍。

　　这是一个辩证的思考，也是运维发展到一定高度之后才能有的判断。

　　为何不切灾备?

　　关于这样严重的事故，为何不切灾备?

　　如前所述，从备份数据库的一字之别，我猜测这个系统根本就没有灾备，所以无从切换，毕竟这只是一款免费的游戏，在官网首页的显示『《炉石传说》官方网站_暴雪首款免费休闲卡牌网游』。

　　对于灾备的部署和切换，王晓征表示浙江移动内部是这样的：

　　按业务重要度，实现不同保障级别。

　　一般系统：只做数据备份，无高可用，无容灾;

　　重要系统：数据备份，高可用，无容灾;

　　核心系统：备份，高可用(部分含柔性可用)，容灾。

　　在实操层面，一般系统基本绝迹，目前以核心和重要系统为主。

　　如果出现数据损坏，核心系统肯定切容灾了，这种情况如果是硬件损坏或者删除数据文件引起的问题，基本就搞定了;当然，最怕的就是误操作或代码bug搞出来的数据丢失，可能把容灾端数据同时破坏，那就只能通过备份来恢复啦。

　　由此可以看出，即便有了完备的灾备环境，也很难防范所有问题，尤其是人为的误操作，所谓『功夫再高，也怕菜刀』，一个误删除可能就级联到所有的系统，再加上软件BUG不可避免，除了灾备，必然还要有可靠的备份来托底。

　　运维团队怎么配置?

　　大家还要思考一个问题，在处理复杂故障的时候，工作不能中断，但是人不能持续运转，在暴雪的这次事故中，从14日至18日，将近5天的时间，处理人员可能已经更替了几轮，如何延续处理思路、执行正确决策、保持核心战斗力，这也是运维要思考的重要因素。

　　如何幸存于类似事故?

　　好吧，我们谈一谈如何避免陷入这样的困境?以下是我们的一些思路，与大家商榷。

　　首先，要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制，但是这套备份机制能否真实奏效是需要检验的。我接触过某大型企业，投入巨资兴建的灾备中心，从未正式切换过，这样的灾备在故障来临时也很难有人拍板去进行切换，所以备份的有效、容灾手段的有效是必须确保的。注意，备份的恢复速度必须足够的考虑到，磁带的低效备份关键时刻会害死人。

　　其次，要有完善的故障处理策略和流程。对于不同系统，在关键时刻要优先确保什么，是要订立规则的，有了规则才能照章办事，不走错方向，不无辜背锅。几年前某国内金融系统出现数据坏块，同样选择了带病修复，最终没能解决问题，同样选择了回档承担了数据损失。

　　再次，要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案，从业务端同样要有对应的预案，以便应急时同步处理，区别对待。很多时候，有了业务上的应急、降级服务方案，技术层面的处理就能够从容许多。

　　最后，要有能够快速协同的团队资源。很多时候严重的故障，需要较大规模的专业团队协作处理，原厂商和第三方在其中都承载着重要的角色，所以关键时刻，要能够获得内外部快速及时的支持，尤其是在绵延数天的高强度工作中。

(本文不涉密)
责任编辑：

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。