盖国强:《炉石传说》大故障,不要以为你也可以幸免(2)
如果大家还记得我曾经写下的DBA守则,没有备份对于DBA来说将会是致命的,而如果没有有效备份,那么备份也只能是心灵安慰.不论如何,备份至少可以给我们重来一次的机会,暴雪这一次最终救命的就是备份.虽然是回退到了14日. 既然备份这么重要,国内数据库的备份情况如何呢?云和恩墨白求恩平台最近发布的《中国2016年Oracle数据库运行现状报告》显示,有完整RMAN备份的数据库不到20%,24%的数据库甚至处于非归档模式下. 下图来自报告数据,可以看到其实国内的数据库的DG的使用率其实并不高,仅有21%: Bethune 平台可以帮助大家检查RMAN备份完整性,Dataguard同步及时性,假期来临之前强烈推荐大家为数据库做一次健康检查. 关键节点是什么? 回顾一下,数据库带病坚持工作,这是整个案例最核心的一个决策,也就是说,通过在线运行,同时修复问题(坏块),向前走. 这也是一个艰难的决策,如此可以减少业务的中断,但是面临的风险就是可能最终数据不一致,需要回退或者承受复杂的校验工作. 大家可以想想我们面临这样的工作会如何处置? 我就此访问了浙江移动王晓征王总,他表达了他的观点:
我非常赞同这一观点,有了事先约定,应急处置时才能有准则,不出现重大偏颇. 要一致性还是连续性? 如前所述,每一个DBA团队都应该有一个准绳,那就是在关键时刻,要保障一致性(准确性)还是连续性? 对于金融机构,毫无疑问,要保证数据库的一致性,在遇到故障时,可以果断中断业务提供,进行数据恢复或者修复; 而对于互联网业务等,可能连续性就更为重要,类似携程的业务,中断几天的服务是不可想象的;王晓征就此总结说:
这是一个辩证的思考,也是运维发展到一定高度之后才能有的判断. 为何不切灾备? 关于这样严重的事故,为何不切灾备? 如前所述,从备份数据库的一字之别,我猜测这个系统根本就没有灾备,所以无从切换,毕竟这只是一款免费的游戏,在官网首页的显示『《炉石传说》官方网站_暴雪首款免费休闲卡牌网游』. 对于灾备的部署和切换,王晓征表示浙江移动内部是这样的:
由此可以看出,即便有了完备的灾备环境,也很难防范所有问题,尤其是人为的误操作,所谓『功夫再高,也怕菜刀』,一个误删除可能就级联到所有的系统,再加上软件BUG不可避免,除了灾备,必然还要有可靠的备份来托底. 运维团队怎么配置? 大家还要思考一个问题,在处理复杂故障的时候,工作不能中断,但是人不能持续运转,在暴雪的这次事故中,从14日至18日,将近5天的时间,处理人员可能已经更替了几轮,如何延续处理思路、执行正确决策、保持核心战斗力,这也是运维要思考的重要因素. 如何幸存于类似事故? 好吧,我们谈一谈如何避免陷入这样的困境?以下是我们的一些思路,与大家商榷. 首先,要有完善、有效的备份和容灾机制.诚然很多企业都有了一整套的备份、容灾机制,但是这套备份机制能否真实奏效是需要检验的.我接触过某大型企业,投入巨资兴建的灾备中心,从未正式切换过,这样的灾备在故障来临时也很难有人拍板去进行切换,所以备份的有效、容灾手段的有效是必须确保的.
其次,要有完善的故障处理策略和流程.对于不同系统,在关键时刻要优先确保什么,是要订立规则的,有了规则才能照章办事,不走错方向,不无辜背锅.几年前某国内金融系统出现数据坏块,同样选择了带病修复,最终没能解决问题,同样选择了回档承担了数据损失. 再次,要有端到端融会贯通的应急机制.也就是说不仅仅技术上具备容灾应急的响应方案,从业务端同样要有对应的预案,以便应急时同步处理,区别对待.很多时候,有了业务上的应急、降级服务方案,技术层面的处理就能够从容许多. 最后,要有能够快速协同的团队资源.很多时候严重的故障,需要较大规模的专业团队协作处理,原厂商和第三方在其中都承载着重要的角色,所以关键时刻,要能够获得内外部快速及时的支持,尤其是在绵延数天的高强度工作中. 对于事后的补偿,19日暴雪已经给出了反馈,第一条就是“只要曾经在2017年1月18日18点之前登录过国服玩家,均可获得与25卡牌包等值的补偿”,越来越觉得,这次“营销”是很成功的. 感谢王晓征提供观点,欢迎大家留言回复您的观点,以上内容纯属猜测!! (编辑:ASP站长网) |