微盟删库事件
微盟删库事件概述
2020年2月23日，微盟员工贺某因生活不如意等个人原因，通过VPN登陆公司服务器将包括源代码在内的数据全部删除，导致微盟SAAS服务平台瘫痪，300余万用户无法使用该公司产品，公司市值蒸发超10亿元，赔偿经济损失共计人民币2260余万元。
上海市宝山区人民法院以破坏计算机信息系统罪判处贺某有期徒刑六年。
事发后，腾讯云组织上百位安全专家，协助微盟，奋战七天七夜，最终完成了数据找回，微盟赔付商家1.5亿元(其中公司承担1亿元，管理层承担5000万元。其中公司董事会主席兼首席执行官孙涛勇承担3500万元，公司执行董事兼首席技术官黄骏伟承担500万元，公司执行董事兼智慧商业事业群总裁方桐舒承担500万元，公司执行董事兼智慧营销事业群总裁游凤椿承担500万元)，以弥补损失。
微盟介绍
微盟，香港主板上市企业（股票代码：2013.HK）， 成立于2013年，总部上海市宝山区长江路258号微盟大厦，致力于为商家打造可持续去中心化的数字化转型SaaS产品及全链路增长服务。 微盟为众多商家提供海量应用与产品服务，并面向电商零售、商超生鲜、餐饮、跨境、美业等行业提供数字化升级解决方案。基于近10年商业实践，微盟构建了微盟WOS新商业操作系统，为企业数字化转型打造出一整套去中心化的商业基础设施，通过多端一体化产品服务矩阵，助力商家智慧经营。同时，微盟也为开发者群体提供强大的PaaS平台，通过开放微盟核心产品技术能力，吸引第三方生态伙伴和开发者共同打造云端商业服务生态体系，实现企业服务价值共创共享，从而为商户提供更多应用选择和更好服务。
微盟致力于通过产品和服务，助力企业向数字化转型，通过科技驱动商业革新，让商业变得更智慧！
2015年以来，微盟是微信最大第三方服务提供商 ，基于微信为广大企业提供开发、运营、培训、推广等一体化解决方案服务，服务范围包括实现线上线下的互通(O2O)服务、社会化客户关系管理(SCRM)、移动电商(VSHOP)、轻应用(lightapp)等综合类业务服务
2020年3月17日，智慧商业服务提供商微盟集团（简称“微盟”）公布2019年财报，2019年公司营收与净利均取得大幅增长，实现上市后全面盈利，业绩增长超出市场预期。2019年全年微盟营收达14.37亿元人民币，同比增长66.1%；净利润达3.11亿元，实现全面盈利；经调整EBITDA（息税折旧及摊销前盈利）为1.68亿元，同比增长131.1%。
2021年年报显示：其由2020年盈利1.08亿元，在2021年转为亏损5.66亿元
微盟删库事件经过
2020/3/23 19:00 左右 腾讯云监控中心发出告警，监测到微盟部署在黑石物理服务器(注:可按需购买、按量付费的物理服务器租赁服务)上的业务出现大面积无法响应的情况，同时微盟也通过腾讯云售后和商务团队同步了这一信息。与此同时，微盟的商家服务群里已经炸开了锅
溯源到微盟部署在自建MySQL数据库上的核心业务数据，被微盟某运维人员用一种让程序员闻风丧胆的Linux系统下文件删除命令(注:rm -rf / )，整体进行了不可逆的删除
23日深夜，腾讯公司副总裁、腾讯云总裁邱跃鹏接到团队汇报，他指示团队 “不管微盟的故障是什么原因触发，腾讯云都要不惜代价全力支持”，并立刻决定由徐勇州组建一支30多人的技术团队，与微盟一起研究制定生产环境和数据修复方案，同时协调了内部等多个部门做好技术协助和资源保障
数据库连同备份文件被全部删除，且数据体量达到数百T。这种情况，哪怕是专业的数据恢复公司，也只敢谨慎评估20%左右的修复预期。难度可想而知
坚信数据肯定还在的是微盟CTO黄骏伟，他一再对徐勇州和腾讯云技术团队表示，“拜托你们一定要帮我们找回来”。
一场168小时的腾讯会议
23日晚，不眠之夜。徐勇州连夜带领团队与微盟方面进行解决方案的探讨和制定。
任务的十万火急，让每个人睡觉都只敢定2个小时的闹钟，闹钟一响就接着战斗。24日下午，已经连轴工作30多个小时的徐勇州，才第一次短暂休息。微盟CTO黄骏伟，也是始终保持在线，与腾讯云团队沟通修复过程中的技术问题
理论基础:数据删除后，没有覆写，因此数据应该还在，所以先从备份服务器中进行找回。
他们很快面临了第一个艰难的抉择——
通常来说，数据修复的第一步是对源数据进行镜像拷贝，以避免修复过程中源数据受损的风险。如果采用网络传输进行拷贝，以微盟的数据体量，光是数据拷贝过程就至少需要2天以上，会让数据修复的时间进一步加长。“微盟和商家们都等不起。”
另一种惯用的处理方式是将原来服务器上的硬盘拆装后挂载到新服务器上，以并行的方式进行“硬盘对拷”。这样可以节约时间，但风险是一旦中途出现故障，源数据可能会因此完全丢失。“对于仅有一次这样修复机会的微盟来说，这样做风险太大。”
两难之下，在征得微盟同意后，团队做了一个大胆的决定：越过镜像拷贝的步骤，同时不将微盟的数据盘从原有服务器上拔下来，而是将另外一块系统盘安装到原有服务器上，通过新系统盘加载OS和数据恢复软件，直接扫描提取数据盘中的“隐藏”数据。
这样做的依据是，数据硬盘的健康度良好，且腾讯云技术团队有丰富的硬件处理经验，有较大把握在源数据不损伤的前提下进行扫描。这相当于借助一根体外供血管在体内完成这场手术，通过完美的技术，实现效率与完整性兼顾。
为了万无一失，徐勇州还邀请了腾讯内部多位硬件专家通过腾讯会议进行远程视频指导。“所有的专家都在线，几十双眼睛，在屏幕前盯着现场工程师的每一个动作，以保证准确无误。”
小心翼翼的“手术”过后，更大的挑战在于如何将数据完整地提取出来。
2月26日，数据恢复工作已经开展了三天三夜。当天中午，第一批次的数据拿到，导入数据验证正常。但他们很快发现，他们扫描出来的最新一份数据是截止到2月17日的数据拷贝，完整性尚不确定。
“也就是说，即便这份数据完整，那17号到23号当天的数据也是缺失的。”徐勇州解释，“这个事情，好的一面是明确地告诉我们数据还在，恢复有希望。但是只找回一部分数据意义不大，我们需要完整的数据。”
扫描仍在继续尝试，工程师们逐步发现了更多数据的踪迹。到了周三深夜，新的问题再次出现：工程师们发现，现有的数据备份中，缺少大文件数据，而这些大文件极有可能是微盟最核心的业务数据。它们没有被扫描出来。
“用绝望来形容当时的心情都不夸张，核心数据如果没有，等于前期的工作都白做了，其他数据恢复了都没意义。”徐勇州说。
事实上，此时扫描出的数据大约是微盟数据整体的30%左右，已经符合甚至超过了此前行业对此类事故恢复程度的预期。“这难道真的是一个完不成的任务？”
徐勇州和技术团队不想放弃：核心数据找不回，影响的不止是微盟，还有那些商家的利益。“有一点希望都得试试看。”
徐勇州彻夜未眠。思量再三，决定两条腿走路：一是尝试对磁盘的每一块（block）进行二次扫描；二是让腾讯云的操作系统团队从OS底层入手，制定数据恢复方案PlanB，这需要极其庞大数量的尝试和数据验证，“方案一能成功是最理想的，方案二就意味着数据恢复的时间不确定，业务停摆，继续失血。”
周四上午，第一台服务器的第一块扫描成功，导回数据库查看是完整的。“方案一可行！大家信心一下子又起来了。”
从可行到成功，中间仍有艰难险阻。数据公司提取出来的单一的块，从体积来看还是达不到微盟核心文件的大小。这意味着，要获得完整数据，需要进行数据“拼接”。
就好像整块拼图被打散扔进了大海里，一块一块打捞上来是第一步，拼接是第二步。不同的是，拼图时还能够根据形状来判断哪些可以放在下一块，而拼接数据块，根本无法通过肉眼识别，只能靠一块块去扫描，寻找相似度高的拼接到一起，再重新扫描看断点是否能重合。
庆幸的是微盟的备份机制较为完备，数据的覆盖度和完整性检查等工作非常细致。徐勇州发现，文件类型只有一种，那么就能很容易判断出哪块是开头，拿着开头去找剩下的块，把工作量从“NN”降低到“1N”。 但“1*N”的工作量也不小。最大的一个文件，由7块碎片组成。找到开头以后，工程师开始扫描其他有相似性的块。运气好的时候，相似度可能只有一块，运气不好的时候 ，有二三十块。每进行一次拼接，都需要把数据块从头到尾扫描一遍，验证是否匹配。这需要大量的计算力。为了加快扫描和验证，腾讯云服务器团队还临时从上海机房调拨了100多台服务器进行算力支持。
徐勇州已经不记得这样的“打捞、拼接、扫描、验证，重新打捞、拼接、扫描、验证”进行了多少次，只记得每一次都是四五个小时的煎熬。“大家每隔一会儿就在腾讯会议上吼，好了没，好了没，快看看！”
终于，一块又一块的数据被拼接出来，核心数据逐渐被修复。“太不容易了，心情真的跟过山车一样。”
2月28日，深夜，数据修复胜利在望。
做到100分，在云上迎接重生的微盟
虽然最初大家并不敢断言数据能否修复，随着两边团队的共同攻坚，大家关注的焦点逐渐变成数据能不能做到100%的修复。
然而，即便是方法论经过了验证，但就像写程序一样，在一些细微的地方总会有一些意想不到的bug出现。
2月29日凌晨，恢复到最后一台服务器时，徐勇州和技术团队盘查发现，前面找回来的那些数据只有整体数据量的70%-80%。按照前面核心数据恢复的方法推演，如果逻辑成立的话，此时恢复的数据应该是100%。
剩下的数据去哪了？到底是哪个环节出了问题？“我们的目标是要做100分，哪怕失掉5分，对一个商家来说可能就是全部。”徐勇州和团队连夜把所有的数据又重新盘点了一遍，把验证的逻辑再推导了一遍：扫描了多少？提取了多少？哪些校验过？哪些没有？
又是一夜未眠。3月1日凌晨，终于在另一个的区段中，被遗漏的数据被“打捞”了出来。原来有一部分数据在提取时因为环境等各种原因被疏忽了，在把所有的数据都汇总整理和对齐后，很快找到了对应的那段未提取区段，然后又是进行紧张的“打捞、拼接、扫描、验证”，但这时的团队已经是技术娴熟，胸有成竹
3月1日晚，微盟发布公告称，数据已经全面找回。同时宣布基础设施全力上云。
微盟被删库后采取的措施
微盟将采取以下措施提升对数据安全的保障：
首先在权限管理方面，使用腾讯云CAM权限系统进行云资源管理，严格执行分级授权和最小集权制度，对高危险动作执行二次授权制度；
使用腾讯云堡垒机替换自建堡垒机，进行细粒度许可权分级和授权管理。
其次，在北京、上海、南京等地区建立全备份的冷备系统架构，借助腾讯云IaaS的底层服务能力，建立高可用的同城双活架构；所有非结构化数据使用腾讯COS对象存储系统进行归档保存并启用多异地复制功能。
最后，借助腾讯云数据库MySQL的数据高可用和安全体系，逐步放弃自建数据库服务，迁移到腾讯云数据库（CDB）,提升数据库跨可用区和易地灾备的能力，同时，将原来合作的黑石1.0物理机全面升级黑石2.0，全面使用云主机。
微盟删库事件警示
腾讯云30多位技术专家和微盟一起，经过七天七夜的奋战，竭尽全力完成了这项"不可能完成的任务"
在徐勇州看来，微盟事故的发生对其他企业的数据安全保护也敲响了警钟，数据安全事件背后折射出的是，仅仅依靠单点防护难以达到真正的安全防护效果，而构建基于全生命周期的安全防护成为必然选择。
业内经常调侃的程序员删库的事件，就如黑天鹅，没有想到真的发生了，而且一个普通运维人员就能给市值百亿的企业造成这么大的伤害。 让业界再一次深深的重视了数据安全，重新检查自身的数据备份及管理机制
核心数据或数据库的管理应该怎么做?
前提是数据的分类整理，每份数据可以承担哪些损失
- 梳理清楚公司共有几部分数据
常见的在线数据一份(简称A)，热备份一份(简称B)，冷备份一份(简称C)
注:每一份可能都是多台机器组成的集群 - A和B保障的是业务高可用，C主要保障当线上出现问题后，可能及时有恢复
- 权限管理
A和B可以一个人(P1)进行管理，C可以由一个人(p2)进行管理，P1和P2登录和管理需要使用双因素认证(确保账号信息不会被盗用), 更加核心的数据，P1应该由两人(P11,p12)，P2也应该由两人(p21,p22) 参考银行的管理模式,当然这样的效率会下降
后记
作者: 思安 时间: 2022/5/28 本文主要摘录了参考材料，希望尽可能全面展现微盟删库事件，提供一份完整的素材
参考文献
微盟数据被删后胆颤心惊的七天七夜
微盟百科介绍
赔付 1.5 亿元！七天七夜，微盟被删除的数据全面找回：放弃自建数据库，全面上云
被删除、被泄露、被窃取，企业如何才能保护好自己的数据？
尊敬的微盟商户：
截止到3月1日晚8点，在腾讯云团队协助下，经过7*24小时的努力，我们数据已经全面找回，由于此次数据量规模非常大，为了保证数据一致性和线上体验，我们将于3月2日凌晨2点进行系统上线演练，将于3月3日上午9点数据恢复正式上线。
此次事故给商家经营造成了严重的影响，公司管理层对此深感自责和愧疚，我们准备了1.5亿元人民币赔付拨备金，其中公司承担1亿元，管理层承担5000万元。在紧抓数据恢复的同时，也在同步研究商家赔付方案，我们拟定了现金赔付计划和流量赔付计划供商家选择。
同时此次事故也暴露出公司在数据安全方面出现了管理漏洞。事故发生后，我们加强了内部流程控制管理，同时邀请外部数据安全专家一起来评估数据安全保障方案，并迅速制定了一份数据安全保障计划，以杜绝此类事故的再次发生。
事故经过
2月23日，因公司员工恶意破坏公司线上生产环境及数据，导致公司系统服务不可用。目前，该犯罪嫌疑人已被上海市公安局宝山分局刑事拘留。
2月25日，我们紧急恢复了核心业务的线上生产环境，新用户使用不受影响，并提供老用户临时过渡方案，确保商家在数据暂时没有恢复的情况下可以正常经营。
2月28日，我们恢复了所有业务的线上生产环境，并且开放了老用户登录，以及恢复了微站产品的所有数据。
截止到3月1日晚8点，在腾讯云团队的协助下，经过7*24小时的努力，我们已经全面找回数据。由于此次数据量规模非常大，为了保证数据一致性和线上体验，我们将于3月2日凌晨2点至8点，进行数据恢复上线演练，在此期间我们的系统将会停止服务，演练完成后系统数据回滚到3月2日的数据。
我们将于3月2晚上10点至3月3日上午9点，正式进行数据恢复上线，我们将恢复2月23日之前的数据，同时将2月23日与3月2日的数据进行合并，届时我们所有的数据恢复完成。
事故责任
此次事故虽由“人祸”引起，但公司管理层有着不可推卸的责任。
首先公司董事会主席兼首席执行官孙涛勇没有对数据安全引起高度重视，没有对数据安全保障方案进行深入的评估和审查，没有聘请外部专家顾问团队对数据安全进行评估和测试，没有把数据安全管理纳入到日常管理范围。
其次公司执行董事兼首席技术官黄骏伟，作为公司技术负责人，没有对数据安全引起足够重视，没有严格按照公司的内控管理制度，对运维人员的权限进行分级和分区管理，对于数据安全技术体系的建设和引入，缺乏全局和前瞻性设计，对于安全监控体系没有执行到位。
公司执行董事兼智慧商业事业群总裁方桐舒，作为SaaS业务负责人，没有对数据安全引起高度重视，没有严格执行公司内控管理制度并推动研发侧加强数据安全管理。
赔付计划
此次事故给商家经营造成了严重的影响，公司管理层对此深感自责和愧疚。事故发生后，公司管理层在紧抓数据恢复的同时，也在同步研究商家赔付方案。
首先针对此次赔付计划，我们准备了1.5亿元人民币赔付拨备金，其中公司承担1亿元，管理层承担5000万元。其中公司董事会主席兼首席执行官孙涛勇承担3500万元，公司执行董事兼首席技术官黄骏伟承担500万元，公司执行董事兼智慧商业事业群总裁方桐舒承担500万元，公司执行董事兼智慧营销事业群总裁游凤椿承担500万元。
其次整个赔付方案中，我们既要考虑商家因系统不可用而造成的利润损失，同时也要考虑系统不可用而带来的流量损失，因此我们的赔付计划做了两个不同的方案供商家任选其一。
01
现金赔付计划
我们会针对因系统不可用期间商家边际贡献利润额进行赔付，具体公式计算如下：
边际贡献利润额=日均收入×行业平均边际贡献利润率×系统故障时间
（其中日均收入等于该商家在2020年2月17日晚7点至2020年2月23日晚7点在微盟系统中产生的实际成交额除税后的平均值；边际贡献利润率是指在收入（不含税）基础上扣除商品成本、仓储及物流费及推广费、销售佣金等与商品服务销售及交付过程直接相关的费用之后的边际贡献利润占收入的比例；行业边际贡献利润率最终参考值将以研究机构公开报告为准；系统故障时间自2月23日晚7点至3月3日上午9点）
02
流量赔付计划
我们会针对因系统不可用期间的商家给予腾讯广告50000曝光次数进行流量补偿，并且提供账户运营服务，同时再延长SaaS服务有效期两个月。
（其中腾讯广告包括微信朋友圈广告、微信公众号广告、小程序广告等；曝光次数是指该广告被用户看到的次数；运营服务包含广告的创意策划、素材制作、投放执行、数据分析、账户优化、数据报表等运营服务）
最后我们所有的赔付将通过线上赔付系统完成，公司将在接下来一个月左右开发完成线上赔付系统，届时商家可通过登录微盟商户后台，点击申请赔付即可完成。
数据安全保障计划
此次事故暴露出公司在数据安全方面出现了管理漏洞。事故发生后，我们内部在系统自查的同时邀请外部数据安全专家一起来评估数据安全保障方案，现公布措施如下：
措施一：数据安全管理机制全面加固与整改，加强运维平台治理
1、完善数据安全管理制度（涵盖权限、监控、审计方面），严格执行授权审批制度；
2、使用腾讯云CAM权限系统进行云资源管理，严格执行分级授权和最小集权限制度，对高危险动作执行二次授权制度；
3、建立科学、高效、安全的网络策略，对开发环境、测试环境和生产环境进行严格隔离；使用腾讯云堡垒机替换自建堡垒机，进行细粒度权限分级和授权管理，同时严格审计堡垒机操作日志，发送安全审计报表；
4、加强运维安全流程学习，职业道德学习，法律学习等。
措施二：加强灾备体系的建设，做到多云异地冷备
1、建立多云灾备体系，在北京、上海、南京等地区建立全备份的冷备系统架构；
2、借助腾讯云的IAAS的底层服务能力，建立高可用的同城双活架构；
3、云上所有的云主机，启用每天的快照策略，保证全量和增量备份；
4、所有非结构化数据，使用腾讯COS对象存储系统进行归档保存，启用COS的多异地复制功能，数据存放多地，并且COS 冷存储，确保数据只增不减；
5、建立月、季度级别的定期演练机制和制度 。
措施三：基础设施全力上云
1、借助腾讯云数据库MySQL的数据高可用和安全体系，逐步放弃自建数据库服务 ，迁移到腾讯云数据库（CDB），快速具备数据库跨可用区和异地灾备的能力；
2、黑石1.0物理机全面升级黑石2.0，全面使用云主机。
致谢
此次事故给商家带来了严重的不良影响，我们深表歉意，同时我们也要感谢在至暗时刻仍然选择信任我们的商家、服务商、合作伙伴、投资人以及所有关心微盟的朋友们，最后再特别感谢腾讯云团队！