受访者 | 腾讯云技术人员
记者 | 胡巍巍
出品 | CSDN（ID：CSDNnews）
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和数据恢复软件，直接扫描提取数据盘中的“隐藏”数据。
确定数据拷贝方式后，腾讯云立即组织团队，进行设备准备。
由于是远程结合现场的方式来进行救援，难免要进行远程沟通。远程连线的工程师们，一直用腾讯会议来开会、现场指导、以及战况汇报。
腾讯云数据中心硬件工程师，
通过腾讯会议远程展示操作细节。
腾讯云供图
在一些关键操作上，往往是几十双眼睛盯着会议直播画面，因为任何失误，都会带来不可逆的后果。
7天7夜里，他们随时起会，腾讯会议也默默记录着事态的进展，开远程会议的账号7*24无中断。各业务团队通过腾讯会议，累积进行766次会议沟通。而这个会议号，也将作为这场战斗的番号永久保留。
最担心的事情发生！
好在前期进展很顺利，但进行到最后三块系统盘安装时，团队最担心的事情还是发生了——新系统盘安装后，数据硬盘出现掉线。
庆幸的是，经过排查，挂载不上的原因，是由于新加的系统盘，触发了原来服务器中的硬件保护机制。
确定故障后，工程师们迅速施策，并对全部数据进行读取。相比通常的数据镜像进程，节省70%以上的时间。
这其中遇到的最大难题是，当肇事者把数百T数据删除后（含备份数据），工程师们再在这么短的时间内恢复起来，其数据量之大、难度之高，远超他们的经验。
正式进入数据提取过程时，微盟的大文件未能提取出来，这意味想要获得完整数据，就得进行拼接。
这好比整块拼图，被打散扔进大海，不仅得打捞出碎片，还得一片片重新拼图。
并且，数据越大，拼接难度也越大。好在微盟的备份机制比较完整，数据类型也比较统一，所以很容易就能判断出哪块是开头，拿着开头去找剩下的块，就会比较容易。
这其中，最大的一个文件，由6块原始碎片组成。找到开头后，腾讯云开始扫描其他相似的块。运气好的时候，打捞出来的数据，只有一块和原始碎片相似（那肯定就是它了），运气不好的时候 ，有二三十块都是相似的。
所以，每进行一次拼接，都要把数据块从头到尾扫描一遍，目的就是验证一下是否匹配。
扫描需要大量的计算力，为此腾讯云从上海机房临时调拨100多台服务器来支持扫描和运算。
团队的心情，也好比坐过山车，每当一个难题被打败，大家就觉得数据恢复有望，立马就嗨起来。但是又出现问题时，心情又跌到谷底。
好在最后恢复了100%的数据，所有辛苦和付出都值得。
7天7夜一百多个小时，这对于所有救援者的体力和意志力，都是巨大的考验。而经此一役，腾讯云工程师的能力再次得到验证，同时参与救援的工程师，也想借CSDN表达一些肺腑之言。
养兵千日，用兵一时
实际上，无论企业把业务部署在自有IDC（Internet Data Center，互联网数据中心），还是放在外部托管IDC里，只要暴露在公网下，都会存在威胁。
所以，建议企业从整体上梳理风险点，进行统筹和联动防御，并对外部、内部、大数据等不同场景，准备出相应的解决方案。
如果企业已经上云，就要做好云主机的定期快照、云账号权限管控，并对重要数据实施分级管理，同时还要做好加密，从而建立全生命周期的数据安全防护。
如果企业使用自建数据库，建议把通过Binlog或其他备份文件进行恢复的详细步骤制定成预案，并且定期演练，毕竟养兵千日，用兵一时。
对于开发者，可以多关注云计算领域的最新进展，包括云安全、数据防护、加密、恶意攻击等知识，还可以多关注数据恢复的案例实践。
上云的紧迫性和必要性
此外，没上云的企业，也可以考虑上云。
以腾讯云硬盘来说，其采用分布式块存储架构，每个数据块在可用区有个3副本，因此可以规避物理磁盘故障和宕机故障导致的数据损坏。
另外，通过云硬盘的快照技术，可实现数据“秒级”恢复到一小时内的状态。
更重要的是，腾讯云还有数据安全产品，能对安全事件实现全面监控、告警和事后审计等功能。
而腾讯云堡垒机，其结合人工智能技术，可以为企业提供运维人员操作审计，还能对异常行为进行告警，进而防止内部数据泄密。
坦白讲，过往很多企业，对于安全重视不足。而“微盟事件”依然在鸣叫的警钟，正是为我们敲响。
人常说，吃一堑长一智，但最省心的，难道不是他人吃堑你长智吗？可以说，微盟的天价学费，不只是为自己而交，更是为全行业而交。
最后，也为所有参与救援的工程师点赞，如果没有他们，微盟的损失可能会更大。7天7夜不间断工作，他们像极了“救火队员”。
每一次互联网事故的修复，网友能看到的，是产品又能重新使用，看不到的则是工程师们在背后的废寝忘食。
这位工程师，可能是你的家人，可能是你的同事，也可能是你的朋友......我们身边从来不缺乏这样的“救火队员”，所以以后对程序员们少些调侃（秃头），多些爱护吧！
【End】
在全民抗疫的特殊时期下，在人员复杂、流动量大地方的出入口处都设置了无接触式无感红外人体测温系统。
在这次疫情防控中，无感人体测温系统发挥了怎样的作用？高精准的无感人体测温系统的核心技术武器是什么？对于开发者们来说，大家应该了解哪些技术？
今晚8点《多场景疫情防控：解读云边端联动下的全栈 AI 技术应用》
推荐阅读
☞腾讯朋友、钉钉等被微信违规公示点名；谷歌更新安卓修复数百万台芯片漏洞；微软终止支持.NET Core 3.0 | 极客头条
☞重磅！教育部再次审批 179 所高校新增本科 AI 专业
☞必看！Spark 进阶之路之「SparkSQL」入门概述 | 博文精选
☞DeepFakes=假货制造机？一文告诉你深度伪造技术的发展现状！
你点的每一个在看，我认真当成了喜欢
转载：https://blog.csdn.net/csdnnews/article/details/104681939