腾讯云“抢救”微盟!开 766 次在线会议、调拨 100 多台服务器、闹钟只敢定 2 小时

766次在线会议、临时调拨100多台服务器,“调兵”四地工程师,这是腾讯云“救援”微盟的付出。

3月1日,“微盟删库”事件收尾,并制定1.5亿元赔付计划。这,不啻于一场血的教训。此次灾难,对于有着300万注册用户、超7万的付费用户的上市公司微盟,后果非同小可。金钱上如此,时间上更是成本巨大。

作为国内开发界的佼佼者,即便是腾讯云工程师出马,也花费整整7天7夜才搞定。那么这次删库到底有多复杂?腾讯云又是如何做完这场堪称技术界的“心脏手术”?CSDN采访本次参与救援的腾讯云工程师,力图为读者复原“抢救”全过程,也希望能为开发者和企业,带来以此次事件为圆心的建设性建议。

事发后,三方组队救援

事故发生于2月23日周日晚上六点多,腾讯云基本和微盟同时发现,随后双方立马建立虚拟团队商量对策。腾讯云投入大约三十多位来自服务器技术、IDC现场、售后专家、安全、存储、数据库、网络、基础IaaS研发运维等团队工程师,这些工程师分别来自北上广深四地。

7天7夜中,他们时刻在和时间赛跑。由于任务十万火急,大家睡觉只敢定2小时的闹钟,闹钟一响就接着战斗。腾讯云副总裁王慧星,也多次连夜进行技术指导,有次一直忙到凌晨6点多。而这次救援的总指挥——腾讯云运维中心和客户服务部门负责人徐勇州,在事件发生后,连续工作至少36个小时,才去稍微睡一会。微盟CTO黄骏伟,7*24小时全天在线,为的就是及时和腾讯云团队,沟通修复过程中的技术问题。

救援很火急,在分工上需要做更专业的规划,故此腾讯云、微盟以及数据恢复公司技佳瑞康,以最快的时间排查原因、并制定出一套完整的数据恢复方案。

排查原因:微盟账号被执行高危操作

在排查到底哪个环节出问题时,工程师们发现所有服务器,都处于服务无法响应的状态,是的,所有!

然后,他们选其中一台服务器进行重启。重启后,发现系统所有数据都不见了,这说明数据库要么被入侵,要么就是被故意破坏。此时,腾讯云鼎实验室应急专家团队与微盟技术团队随即联合排查,很快就溯源到微盟部署在自建MySQL数据库上的核心业务数据,被微盟某运维人员用一种让程序员闻风丧胆的Linux系统下文件删除命令,整体进行了不可逆的删除。 

后续在对外公告中,微盟也披露了该细节。确定原因后,腾讯云开始制定救援方案。方案分三个步骤:第一,控制受损面。不能让还有机会找回数据的服务器,再出现任何闪失。

第二,把数据找回来。这个过程非常耗时,首先要去看到底还有多少数据在,找到数据后再把它恢复出来。恢复之后,还要给微盟验证数据是否完好、导入到数据库是否正常、以及加载到服务器上是否正常。

第三,调试数据。数据验证结束后,微盟要根据数据,进行业务上线和联调演练。但是,恢复过程也并非一帆风顺,因为以往没有任何可参考的案例,只能摸着石头过河。


数据恢复:行走在危险的边缘

找出原因后,就是艰难的数据恢复过程。腾讯云先是把微盟服务器上的源数据镜像,拷贝一份出来,以便保护好源数据。微盟有接近数百T的数据,数据拷贝很花费时间,因此工程师们想了两种拷贝方式。第一种方式,是通过两台机器网络来对拷。他们计算了一下,正常情况下,大概得两天左右,优点是相对安全。

第二种方式,是把硬盘挂载。把硬盘从服务器里拔出来,插到有更多盘的设备上,即用多台服务器并行的方式,把每个硬盘数据复制出来,虽然速度快、但是风险大,任何一步细微失误,数据可能就彻底没了。

两难之下,在征得微盟同意后,团队做了一个大胆决定:越过镜像拷贝的步骤,同时不把微盟的数据盘,从原有服务器上拔下来。而是将另外一块系统盘,安装到原有服务器上,通过新系统盘加载OS和数据恢复软件,直接扫描提取数据盘中的“隐藏”数据。

确定数据拷贝方式后,腾讯云立即组织团队,进行设备准备。由于是远程结合现场的方式来进行救援,难免要进行远程沟通。远程连线的工程师们,一直用腾讯会议来开会、现场指导、以及战况汇报。

腾讯云“抢救”微盟!开 766 次在线会议、调拨 100 多台服务器、闹钟只敢定 2 小时
腾讯云数据中心硬件工程师,
通过腾讯会议远程展示操作细节。
腾讯云供图

在一些关键操作上,往往是几十双眼睛盯着会议直播画面,因为任何失误,都会带来不可逆的后果。

7天7夜里,他们随时起会,腾讯会议也默默记录着事态的进展,开远程会议的账号7*24无中断。各业务团队通过腾讯会议,累积进行766次会议沟通。而这个会议号,也将作为这场战斗的番号永久保留。

最担心的事情发生!

好在前期进展很顺利,但进行到最后三块系统盘安装时,团队最担心的事情还是发生了——新系统盘安装后,数据硬盘出现掉线。

庆幸的是,经过排查,挂载不上的原因,是由于新加的系统盘,触发了原来服务器中的硬件保护机制。

确定故障后,工程师们迅速施策,并对全部数据进行读取。相比通常的数据镜像进程,节省70%以上的时间。

这其中遇到的最大难题是,当肇事者把数百T数据删除后(含备份数据),工程师们再在这么短的时间内恢复起来,其数据量之大、难度之高,远超他们的经验。

正式进入数据提取过程时,微盟的大文件未能提取出来,这意味想要获得完整数据,就得进行拼接。这好比整块拼图,被打散扔进大海,不仅得打捞出碎片,还得一片片重新拼图。并且,数据越大,拼接难度也越大。

好在微盟的备份机制比较完整,数据类型也比较统一,所以很容易就能判断出哪块是开头,拿着开头去找剩下的块,就会比较容易。

这其中,最大的一个文件,由6块原始碎片组成。找到开头后,腾讯云开始扫描其他相似的块。运气好的时候,打捞出来的数据,只有一块和原始碎片相似(那肯定就是它了),运气不好的时候 ,有二三十块都是相似的。所以,每进行一次拼接,都要把数据块从头到尾扫描一遍,目的就是验证一下是否匹配。扫描需要大量的计算力,为此腾讯云从上海机房临时调拨100多台服务器来支持扫描和运算。团队的心情,也好比坐过山车,每当一个难题被打败,大家就觉得数据恢复有望,立马就嗨起来。但是又出现问题时,心情又跌到谷底。好在最后恢复了100%的数据,所有辛苦和付出都值得。

7天7夜一百多个小时,这对于所有救援者的体力和意志力,都是巨大的考验。而经此一役,腾讯云工程师的能力再次得到验证,同时参与救援的工程师,也想借CSDN表达一些肺腑之言。

养兵千日,用兵一时

实际上,无论企业把业务部署在自有IDC(Internet Data Center,互联网数据中心),还是放在外部托管IDC里,只要暴露在公网下,都会存在威胁。

所以,建议企业从整体上梳理风险点,进行统筹和联动防御,并对外部、内部、大数据等不同场景,准备出相应的解决方案。

如果企业已经上云,就要做好云主机的定期快照、云账号权限管控,并对重要数据实施分级管理,同时还要做好加密,从而建立全生命周期的数据安全防护。

如果企业使用自建数据库,建议把通过Binlog或其他备份文件进行恢复的详细步骤制定成预案,并且定期演练,毕竟养兵千日,用兵一时。

对于开发者,可以多关注云计算领域的最新进展,包括云安全、数据防护、加密、恶意攻击等知识,还可以多关注数据恢复的案例实践。

上云的紧迫性和必要性

此外,没上云的企业,也可以考虑上云。

以腾讯云硬盘来说,其采用分布式块存储架构,每个数据块在可用区有个3副本,因此可以规避物理磁盘故障和宕机故障导致的数据损坏。

另外,通过云硬盘的快照技术,可实现数据“秒级”恢复到一小时内的状态。

更重要的是,腾讯云还有数据安全产品,能对安全事件实现全面监控、告警和事后审计等功能。而腾讯云堡垒机,其结合人工智能技术,可以为企业提供运维人员操作审计,还能对异常行为进行告警,进而防止内部数据泄密。

坦白讲,过往很多企业,对于安全重视不足。而“微盟事件”依然在鸣叫的警钟,正是为我们敲响。人常说,吃一堑长一智,但最省心的,难道不是他人吃堑你长智吗?可以说,微盟的天价学费,不只是为自己而交,更是为全行业而交。

最后,也为所有参与救援的工程师点赞,如果没有他们,微盟的损失可能会更大。7天7夜不间断工作,他们像极了“救火队员”。

每一次互联网事故的修复,网友能看到的,是产品又能重新使用,看不到的则是工程师们在背后的废寝忘食。这位工程师,可能是你的家人,可能是你的同事,也可能是你的朋友……我们身边从来不缺乏这样的“救火队员”,所以以后对程序员们少些调侃(秃头),多些爱护吧!

受访者 | 腾讯云技术人员

记者 | 胡巍巍出品

本文转载自 CSDN(ID:CSDNnews),本文观点不代表TakinTalks稳定性技术交流平台立场。

(0)
上一篇 2022年8月2日 下午4:43
下一篇 2022年8月4日 下午3:56

相关推荐

发表评论

登录后才能评论