2月23日19点左右，微盟官网消息，微盟业务系统数据库（包括主备）被黑客攻击公司运维人员。删除。目前，微盟技术团队正在努力恢复数据，但数据恢复缓慢。目前，新用户服务已恢复正常，但老用户官方数据预计要到2月28日才能出炉。微盟官网截图据悉，犯罪嫌疑人已被宝山区刑事拘留公安局，犯罪嫌疑人已承认犯罪事实。嫌疑人为微盟研发中心运维部核心运维人员何某。在线生产环境遭到恶意破坏。腾讯云官方表示，微盟运维事故发生后，腾讯云技术团队第一时间与微盟结盟，研究制定修复方案。工程师们日以继夜地赶工，将尽最大努力帮助微盟减少损失。微盟集团成立于2013年，是一家主要通过SaaS产品和精准营销为商家提供云商务和营销解决方案的提供商。截至2019年6月30日，微盟SaaS产品及精准营销服务注册商户300万，SaaS产品付费商户70006户。财报显示，2019年上半年，微盟营收6.57亿元（人民币），毛利3.65亿元，其中SaaS业务收入2.19亿元，毛利1.77亿元.由此可见，其两大核心业务之一的SaaS业务（另一核心业务为精准营销服务）对微盟的业绩有着决定性的影响。微盟认为，SaaS生产环境和数据损坏对整体财务状况的影响取决于修复的程度和速度，预计会对SaaS业务运营产生一定的负面影响。针对这次删库事件，网友们都炸了锅：删库跑路事件频发，在此提醒各企业注意两点：保养都放的比较宽，容易出事故。更可靠的备份机制：主备均可删除。一旦需要从磁盘恢复，恢复时间会很慢。作为一名技术人员，不要因为一时的脑热而做出错误的决定，让自己被禁锢。最后，让我们和一位老DBA一起回顾和深刻反思这件事。事件回顾时间如下：2020年2月23日18时56分，员工通过VPN登录服务器进行破坏。2020年2月23日19:00，系统监控报错，启动应急预案。2020年2月24日，微盟向警方报案。2020年2月25日7:00恢复部分生产环境和数据，预计0:00之前恢复完成，恢复新用户业务，老用户暂不恢复恢复到2月28日晚上，为什么会出现“删库”？从官方公告来看，是因为运维部核心人员蓄意破坏。常见的滥用或黑客攻击。不过，以我的经验来看，这起事件未必是真正的人为破坏，具体分析就不贴出来了。总而言之，我对官方公告持怀疑态度。但这改变不了人为破坏的事实，就看公安机关如何定性了。我们要做的是反思，防止此类事件再次发生，这也是本文的用意所在。此外，不仅是公司和员工，客户更是此类事故的无辜受害者。我们希望微盟可以节省更多的数据，将损失降到最低。事故恢复的速度从上面的复习时间点来看，我觉得恢复的速度并不算太快。从侧面了解到，此次事件的主要影响是数据库的主备库被删除，进行了“rm-fr/”等操作。这种行为基本上只能通过其他备库或者物理备份来恢复。从恢复后的情况来看，应该是没有可用的备份数据库了，但是应该有备份数据，所以才用了这么久。另外，备份数据恢复后，通常需要进行验证过程，所以一般会先发布公告，安抚客户情绪。但是，新老用户的服务恢复时间不同。由此，我们甚至可以猜测备份机制可能不合理。新数据的备份比较及时，旧数据的备份有延迟，或者因为旧数据量太大，可能延迟更新。长的。更糟糕的是，这次因为特殊情况，大家都在家远程办公，协作肯定比较慢，这也影响了恢复速度。幸运的是，听说腾讯云的很多技术专家都参与了救援工作，希望尽快恢复。事件反思与防范本次事件不同于一般的黑客攻击或误操作，而是源于内部破坏，是最可怕、最难防范的行为。我相信绝对超过80%甚至90%的中小企业都无法回避这个问题。毕竟中小型公司人员有限，进行非常详细的权限划分不太现实，更容易降低工作效率和员工积极性。尽管如此，我们还是想做一些事情来防止此类事件再次发生。首先是权限分级。我们知道，为了提高工作效率，会部署自动化运维工具。但这样一来，也大大增加了误操作的风险。在这起事件中，短时间内造成了大面积的服务器故障，基本可以断定是该工具的批量分发命令导致的。因此，必须进行权限分类，包括业务范围分类。例如，可以尝试以下解决方案：①角色分类区分业务运维、系统运维、网络运维、DBA等多个角色。每个角色只能联系其负责的业务服务器和相应的可执行权限。比如业务运维、网络运维、DBA等不能执行系统层的rm命令，系统运维不能执行数据库的命令。②权限分级区分一级执行权限、二级执行权限和审批权限。比如我们可以实现一个方案，由一级权限的人发起操作请求，由审批权限的人审核订单是否合理，然后由二级权限的人去实际执行。这样基本可以避免人为破坏，除非最终落地时同一个人承担所有角色，否则绕过这个规范很麻烦。分级措施要到位，必须要有足够的人员。公司上市的目的是通过融资改善经营状况。该招人的时候招人。其次，备份、备份、备份的重要性不言而喻。但实际上，光做备份是不够的，还有以下几点需要注意：除了本地备份，还应该有远程备份，以及本地备份和远程负责人的权限备份要区分，分级管理，防止恶意破坏，将全套备份放火烧。除了逻辑备份，还应该有物理备份，恢复起来比较快。除了备份，还应该做好备份校验，保证备份的有效性，即随机选择备份集进行恢复测试，保证备份文件的可用性（我有多年操作经验和维护，只有一处严重故障，即种植（如果没有及时进行备份恢复测试验证）。最后，防灾演练真的很难做好。毕竟很少有人敢在网上真正进行“rm-fr/”这样的操作。但是还是可以模拟各种可能出现的情况以及不同情况的组合，然后针对这些情况制定不同的方案，然后尝试在开发和测试环境中进行演练。并且要不定期进行演练，让每个岗位的负责人熟悉整个过程。就像在日本一样，中小学总是时不时地进行防灾演练。演练多了，遇到问题自然不会慌张，恢复得也快。最后，给予员工更多必要的关怀和培训。还有，作为管理者，要多关注负责后端的运维部门。运维部门一旦出事，真的有可能拖垮一家上市公司。这并非没有经验教训。
