30 多名腾讯工程师，七天七夜拯救微盟的奇迹行动
本文章经授权转载自公众号 "刺猬公社"（ID：ciweigongshe）。
正在家办公的徐勇州接到信息说，微盟数据被删，要恢复数据。他成为特别作战队总指挥。这件事远比他想象中的要艰难，他和整个团队要面对史无前例的一次协助客户进行数据恢复工程。
作者 | 石灿 编辑 | Tim
踏上征途
徐勇州得知微盟数据被删，是在 2 月 23 日（星期天）晚上 7 点 30 左右。
腾讯云监控中心的同事给他发信息说，系统检测到微盟部署在黑石物理服务器上的业务出现大面积无法响应。很快，他收到了腾讯云大客户售后服务团队发起的突发事件通知电话。
他是腾讯云运维中心和客户服务部门负责人，工作地点在腾讯深圳总部。受疫情影响，他跟其他同事一样在家办公。他接到消息，第一时间进入解决故障的备战状态。
据徐勇州说，腾讯云做运维和做技术服务的人，都是 7x24 小时待命，一旦系统出现问题，他们立即切换到作战状态。如果是比较重要的故障，个人作战模式转入团队作战模式，所有人集中进入腾讯会议，保持信息高效流通。
为应对突发情况，每个季度他们都要对团队作战进行预防演练。徐勇州当天知晓这一事情时，并没有表现出慌乱，但微盟数据被删这件事，远比他想象的要艰难，他和整个团队要面对史无前例的一次协助客户进行数据恢复的工程。
凭借多年的经验，徐勇州当时的第一反应是：“其他将业务部署在黑石物理服务器的公司有没有出现类似问题？”
黑石物理服务器是腾讯云推出的一种裸金属云服务。相对公有云的产品，黑石可以在云端给用户提供独享的一台物理服务器资源，有高性能、无虚拟化、安全隔离等特点。
通俗点解释，如果用户购买的是公有云的服务，那他们的业务有可能与云服务商其他客户的业务在同一台物理服务器上，也就可能与其他客户分享这台物理服务器算力资源；而如果购买黑石的服务，那这台服务器的所有算力资源是客户独享的。
因此，黑石物理服务器经常被企业用于核心业务场景，或者一些需要高性能计算的场景中。
腾讯云立即在内部调动网络团队、系统团队和售后团队查找问题，发现黑石物理服务器整体运行正常，一线也未收到其他客户的反馈。
因此，大家判断问题大概率出现在微盟业务系统内部。
腾讯云云鼎实验室安全应急团队随即与微盟开展了内部联合排查。他们很快发现微盟内部出现了黑天鹅事件——审计日志指向 2 月 23 日 19 时许，微盟内部某运维工程师删除了微盟业务数据，包括一般用来做紧急修复用的备份数据文件。
微盟成立于 2013 年，目前是微信最大的第三方服务提供商，微盟业务包括软件开发、广告营销，电子商务等。微盟的中期财报显示，截至 2019 年 6 月 30 日，微盟的 SaaS 产品及精准营销服务拥有 300 万注册商户。
也就是说，事件发生后，300 万注册商户都遭受影响，无法正常开展工作。
突发事件让微盟一筹莫展。一方面，连备份文件都被删除，尚不清楚有恢复的技术路径；另一方面，这么大体量的数据，想在短时间内找回，除非发生奇迹。
他们向腾讯云团队寻求技术帮助。
腾讯云团队将此事汇报给了腾讯公司副总裁、腾讯云总裁邱跃鹏。徐勇州转述邱跃鹏的话说，“微盟故障不管是什么原因触发，腾讯云都要不惜代价全力支持。”
这是一场自上而下的机动性作战。当天深夜，他们召集技术运维、技术研发、系统技术、服务器技术、网络技术、储存技术、数据库技术、售后服务等方面专家组成了一支 30 多人的作战组，徐勇州担任总指挥。
打响第一枪
技术团队经过评估分析，微盟被删除的数据体量达到数百 T。1T 能装下约 2 千多万张照片，数百 T 能装下数亿张照片。
要修复这么大的数据量，“刚开始，我信心不大。”徐勇州坦白。
事发当晚，他们向第三方数据恢复公司咨询，对方知晓事情的严重性后回复说：首先，数据能全部找回的希望不大，能恢复 30% 就了不得了；其次，恢复时间非常长，需要数周的时间。
最终，有着丰富经验的数据恢复公司“技佳瑞康”，参与到了本次史无前例的数据救援项目。
面对挑战，腾讯云团队立即调度备用服务器、加派服务器技术专家进入作战状态，他们与微盟技术支持团队线上开会研究被删除的数据基本情况。
微盟被删的数据大致分为两部分，一部分是存放在自建数据库里的现网业务数据，部署在数据库服务器上；一部分是存放在备份服务器上的备份数据。因为删除操作，两种服务器里的文件都是碎片化记忆，且不可见。二者区别在于，数据库服务器中的残存文件数量多，类型繁杂；而备份服务器文件类型单一，数据集中。
徐勇州和技术团队分析：如果备份服务器没有新数据写入，相对数据库服务器，他们更有机会在一片混沌中，打捞出原来的碎片，进行重组。
他们决定在备份服务器上动手。随即开始了争分夺秒“救数据”，但在执行中遇到了一个比较大的挑战——怎么把原始数据镜像拷贝到新的硬盘中？
恢复数据的过程可以理解为修复一幅被撕碎的画作。在一堆碎片中，找出一些被撕碎的画片的残痕，然后把很多不同形状、不同颜色的画片残痕拼接成原来的模样，拼接完成后，有些图片的色块可能有色差，需要专业的机器做色差检测。
按通行的做法，他们要先把这些残痕复制一份，也就是数据拷贝，这样可以避免过程中出现未知风险，确保原始数据的安全。
但问题是，数据量太大。这个复制过程，如果用网络传输的方式，短则几天，长则几周，中间还不能间断。但商家等不起，微盟也等不起。
还有另一种方式是，将那些存在残痕的硬盘安装到一台新服务器上，通过新服务器的能力，进行物理硬盘拷贝，这样可能节约一些时间，但中途一旦出现故障，这些数据残痕可能就灰飞烟灭了。对于微盟来说，这样的风险承受不起。
两难之下，征得微盟方面同意，腾讯云团队选择了第二种相对冒险的方式，就说在微盟现在的服务器上，安装带有新操作系统和数据扫描软件的新系统盘，通过这个外置的“供血机”，来直接读取数据硬盘中的数据。这个办法越过了数据拷贝的环节。但对于硬件处理技术和经验的要求都非常高。
2 月 24 日，上海腾讯云数据中心，一个穿红色毛衣的工程师操控电脑，一个穿着黑色毛衣的工程师拿着手机录像，旁边还站着几位戴着口罩的工程师，像他们的“护法”。
前线工程师在做拷贝数据，图片由受访者提供
类似于这种事，他们之前也处理过，但这次格外谨慎，不容有失。徐勇州邀请很多专家通过视频在线指导身在上海数据中心一线的工程师，几十双眼睛等着手机屏，看工程师推进每一个步骤，生怕哪个环节出现纰漏。 前期进展得很顺利，终于处理到最后一台服务器了，更换完系统硬盘，在进行服务器自检时，数据硬盘突然发出掉线警告，所有人都被吓到了。 “就像几个大夫会诊一样，一起诊断病人身体到底发生了啥？” 2 月 25 日凌晨 6 点，徐勇州远在深圳，只能通过腾讯会议与前方连线。 “我当时眯了一会儿，我听到他们在（腾讯会议群里）吼。”他没睡着，立刻蹦起来在群里问“到底怎么样？” 经过排查，原来是新硬盘触发了服务器的保护机制。外力介入，半小时后，解除保护机制，数据继续传输。 这是整个征途的第一步。
点亮“太阳系”
完成第一步，徐勇州更加坚定了之前的理论判断：备份服务器没有新数据写入，有机会在一片混沌宇宙中，打捞出原来的星系碎片，重组星系。
“进入第二阶段，我们已经有一定的信心了……无非就是说我们怎么去扫描，拿到文件。”徐勇州说，有两种技术可拿到文件。
最先采用 A 计划，扫描目录。但他们在扫描第一轮目录后，发现整个文件系统的目录结构全都被破坏，拿到一些残余文件的完整性也很差。
大家好不容易拾起来的信心，又被击碎了。
腾讯云团队与数据恢复公司、微盟一起开会讨论，还有什么办法能扫描出已经被删除成碎片的文件数据？
“基于块的方式来扫描。”徐勇州解释说，这个备份服务器上面的数据单个文件体量比较大，数量也不多。
技术人员设置常规服务器和备份服务器时，在时间上也做了区分，常规服务器每天24小时录入数据，而备份服务器只在某些固定时段录入数据。
这样就让备份系统内部形成了连续、集中的数据形态，形成一个又一个类似于以行星为单位的太阳系系统。第一种方法可理解为逐一攻破各个星球体系，最后统一太阳系；第二种方法是从上帝视角，一次性打捞整个太阳系。
太阳系八大行星运转示意图，以作比喻，图片来自堆糖网
2 月 25 日深夜，他们实行 B 计划，整个过程很煎熬，除了等，大家不断复盘之前操作的方案。12 小时后，扫描完成，他们检测发现了截至 2 月 17 日的备份数据，而且数据相对完整。他们把数据交接给微盟做导入，对方回复说“正常的”。 这意味着，2 月 17 日及以前的所有数据，都找回了。 徐勇州记得很清楚，微盟方面检测数据完整后，说了两句话：“如果有 23 号的数据就更好了”；“我们的核心文件到底还在不在？” 这个“核心文件”如果拿不回来，将对商家带来毁灭性打击，所有的商户和订单信息都会丢失；它就像太阳系中的太阳一样，如果没有太阳，太阳系也就不复存在了。 徐勇州是一位老腾讯人，2005 年 10 月进入腾讯，负责 QQ 的运维能力建设，经历了 QQ 从 1000 万到 2 亿最高同时在线的技术架构演进。加入腾讯前，他爱好跑马拉松，喜欢这项运动的人大多韧性十足，实力内敛，爆发力强；进入腾讯后，他把身体、意志追求的韧性和实力映射到云计算马拉松的跑道中，在执行腾讯云全球布局时，号称“只为打造最高品质的数据中心”。
徐勇州给团队下命令：“不管怎么样，我们要先把核心的文件先找回来。” 一开始，他们就碰到了一个大难题。沟通时，微盟告诉他们，服务器里有一个很关键的压缩文件，是微盟的核心数据，就像太阳系里的太阳一样，但他们没有发现太阳，整个太阳系依旧一片漆黑。 2 月 26 日晚上 9 点，徐勇州和微盟 CTO 黄骏伟说了这一信息。徐勇州的心情很复杂，“我们觉得这个很严重，我当时真的心里发凉，原来想我能拿多少回来，尽量拿多少回来，现在的情况是，如果拿不回核心文件，我们团队的努力就白费了。” 这时，腾讯云出现了另外一个建议，一位技术专家介绍了另外一家数据恢复公司，他们在扫描数据时有经验。腾讯云、微盟和数据恢复公司又组团在一起开了个会，一直开到夜里 12 点，对方表示可以试一试，但把握不是很大，而且需要 1~2 天的时间才有结论。 但他们提供了一条信息：通过小文件拼接大文件存在“一定对”的肯定性。 除了他们，腾讯云其他技术团队也在想办法怎么恢复核心大文件，但一直没有直接办法。唯一解决办法也是通过打捞小文件拼接大文件。 “我们扫出来的数据块，肯定是我们要找的文件，怎么把它们变成一个有效文件呢？”这就好像是太阳系中发现了太空垃圾，怎么把太空垃圾变成有生命力的行星呢？ 他们假设了最糟糕的一个打算：把打捞上来的所有小文件都扫描一遍，寻找同类项，做图片拼接。这样做的工作量非常大，不是几天就能完成的事情。 “有没有一种方法能做一部分数据的筛选呢？”基于这个假设，他们开始分类甄别文件类型，这是整个复原大文件的关键步骤。 在服务器的备份文件中，想要组成一个偌大的数据系统，工程师会按照文件类型，对每一个数据做标签。就像我们每一个人都有自己的身份证一样，而且是独一无二的，每一串身份证号码都有它的规律，比如按从左到右数 1~6 位数字表示出生地编码，只要查看这几个数字，就能区分你来自哪个省份。 按照这个逻辑，他们找到文件开头，逐一拼接。说实话，这个过程带着“蒙”的意味，“蒙”对了，就能拼接出大文件，“蒙”错了，就得继续尝试其他碎片。 2 月 28 日，微盟拿到 2 月 17 日的备份数据后，恢复所有业务线上生产环节，老用户可登录后台，微站产品所有数据重新上线。徐勇州他们也正在焦头烂额地拼接碎片。 很快，一个核心文件块被拼接出来了，“我们紧接着开始按照之前的方法批量操作，如果方法是对的，其他数据也能成功，就有机会拼接出更大的文件来。” 每一次拼接，都要数据从头到尾扫描一遍，匹配是否成功。为了加快扫描和验证，需要强大的计算力，腾讯云临时调用腾讯上海机房 100 台服务器做支持。如果能顺利推进，整个过程可无障碍执行，一旦出现问题，就要推翻重来，一次需要 12 小时，“我们耗不起这 12 个小时。” 由于是分环节分团队操作，大家不断在腾讯会议里吼：“你不能那个……”“你做的这个是什么？”“你不能跟我有冲突……”天涯各一方的工程师们在会议里闹哄哄，而喧嚣背后，是一个又一个谨小慎微的确认环节。
经历了无数次“打捞、扫描、拼接、验证”后，终于，最大的一个核心数据文件在 2 月 28 日晚上找回来了，它由7个碎片组成。他们相当于修复了一个被击碎的太阳，整个太阳系，见光了。
怎么避免“太阳系”变暗？
2 月 23 日的备份数据还没有找到，他们立即投入到恢复数据的战斗中。
由于备份数据放置在不同的服务器里，他们要对所有的备份服务器进行扫描，2 月 29 日下午，所有的服务器都扫描完了，怎么会没有 2 月 23 日的数据呢？
事情又变得紧张起来。
“到底发生了什么？我当时很焦虑，我在会议里大声吼，‘你们把所有的过程都去复翻一下，看看到底是什么原因？’”徐勇州下达这个命令时，已经是 2 月 29 日凌晨，大家都处于连轴转状态，熬了好几个日夜。
3 月 1 日早上，大家冷静下来，有人说，“可能我们有一段数据没有提取。”
这时，他们把所有数据汇总，做加减法，简单计算，前面提取了多少，后面提取了多少，一下子就知道缺失数据在哪儿了。
最终，在一个服务器的区段中，把遗漏的数据找了回来。
“我觉得这个事情我们应该是成了。”徐勇州暗喜，并第一时间把这个信息同步给了邱跃鹏，“微盟数据恢复工作重大进展，经过 7 昼夜的抢救，团队最终协助客户挽回了重要数字资产。”邱跃鹏回复：“太好了！”紧接着又详细询问了解微盟业务的恢复计划和进展。
他们立即把数据交给微盟，对方进行业务验证后，数据确实已经全面找回，只是还需要一些时间进行导入、联调。
3 月 1 日晚，微盟发布公告说，由于此次数据量规模非常大，为了保证数据一致性和线上体验，3 月 2 日凌晨 2 点进行系统上线演练，3 月 3 日上午 9 点数据恢复正式上线。同时发布了 1.5 亿元的商家赔付计划。
公告对这件事进行了反思，有一条反思内容写到：“没有严格按照公司的内控管理制度，对运维人员的权限进行分级和分区管理。”
腾讯安全数据安全团队在接受
刺猬公社（ID：ciweigongshe）
的访谈时说，权限管理是数据安全的重要一环，任何不受控制的超级管理员都不应在生产环境中出现。特别是核心业务系统，应执行严格的权限管理、命令管理，防止高危操作的执行。
此次事件中的最大问题在于，权限管理过于简化，没有严格划分业务场景并且梳理最低的操作权限需求，导致了超级管理员的出现，而恰巧超级管理员出现了不轨意图，给企业造成了重大损失。
类似于微盟删库事件，在国内外也有很多。
2017 年发生过 “Gitlab 删库事件”。Gitlab 是全球第二大开源代码托管平台，当年 1 月，运维人员错误地在生产环境上执行了数据库目录删除命令，导致 300GB 数据被删除，且此前采用的 5 种备份机制均不可用，最终导致公司丢失了近 6 个小时的数据。
据彭思翔介绍，这些数据给 Gitlab 造成了重大损失，很多开源项目文件丢失，大量用户无法正常访问，严重影响了代码托管业务。
另一个删库事件发生在荷兰。Verelox 是一家位于荷兰的云主机商，2017 年 6 月，公司一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容，最终导致 Verelox 暂时将网络下线。史称 “Verelox 删库事件”。
数据安全七分管三分治，彭思翔认为企业数据安全需要从完善整体管理体系开始，同时建立一个可有效落实管理制度的安全产品体系。
首先，梳理企业数据的整体风险。随着《网络安全等级保护 2.0 制度》《数据安全管理办法》 GDPR 等法规的陆续出台及完善，合规是企业首先需要应答的一点。企业的数据安全应该从梳理数据的整体风险开始，对照相关法规明确自己的差距点和控制项，并有针对性地改进。建立一套完善的数据安全管理办法，确定合理的数据使用及权限管理制度，明确数据安全的责任主题，使业务侧与安全侧协同起来。
其次，好的策略需要好的工具才可以有效地落地执行，因此需要一个整体的“数据安全战略官”去对风险点进行持续的梳理与监控，进而统筹和联动防御。
“战略官”需具备数据资产感知、异常行为分析、数据流分析、联动防御等核心功能，帮助企业全面掌握业务核心数据资产的分布、使用情况、与风险情况。
最后就是对外部、内部、大数据等不同场景构建，在“战略官”的指挥联动下，针对性地构建一体防护方案。
针对外部攻击，采用身份认证，数据库审计，加密网关保护核心数据不受外部攻击的威胁；针对内部数据泄露，采用 4A(认证 Authentication、授权 Authorization、账号 Account、审计 Audit )与 DLP 等安全能力，全面保护企业运维、办公、数据分析等场景的数据防泄漏风险；针对大数据共享中的数据泄露问题，建设脱敏，水印，加密，审计与权限管控等安全能力。
从管理制度开始，针对场景、结合业务构建一体的数据安全解决方案，才能更有效地保护数据安全，确保企业数据防线稳固可靠。
打完这一仗，徐勇州和大家说，“给大家放假，放一周的假，大家好好休息一下”。他也最想休息，但实际上还有很多扫尾的工作要推进。
“你让我评价这件事，我第一感受是不要再发生这种事情了，企业的IT治理一定要把安全放在第一位。”徐勇州说，“微盟是幸运的，能 100% 找回数据是奇迹，但如果再发生一次，未必有这么幸运了。”
往期精彩：
刺猬公社是聚焦内容产业的垂直资讯平台，关注领域包括互联网资讯、社交、长视频、短视频、音频、影视文娱、内容创业、二次元等。
本文分享自微信公众号 - 生信科技爱好者（bioitee）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
