2月25日，微盟集团（2013.HK）发布关于系统故障的公告，称公司自2月23日19点起发现SaaS（软件即服务）业务数据遭到员工人为破坏出现故障，大面积服务集群无法响应，生产环境及数据遭受严重破坏。2月24日，微盟曾在官方发布公告称，由于技术故障，导致当前服务不可用，服务恢复预计需要24~48小时。而从最新的消息来看，微盟明显低估了这次事故的严重性。
据微盟预计，老用户数据将在2月28日晚上24点前方可完成数据修复，并表示已向上海警方报案，拘留相关人员。这意味着，微盟的老用户将面临超过5天的系统宕机，而其他商家受影响的时间远远超过预期。对疫情期间本来正在经受门店歇业重创的商家来说，可以说是致命性的打击。
有微盟商家爆料，称微盟系统于2月23日19:30前后崩溃，基于微盟的商家小程序悉数宕机，无法打开。目前等待微盟和所有微盟商家的，是接下来继续生意停摆的煎熬，以及笼罩在疫情阴霾和技术故障之上的巨大不确定性。
对于微盟公司及商家，此次事故不亚于一场天降横祸。曾有相关运维工作人员谈到，这次事件不同于常见的黑客入侵或误操作，而是源于内部发起的破坏，这种是最可怕、最难防范的行为。相信超过80%甚至90%的中小型公司，都无法避免这个问题。这种意外事故，受害人除了公司、员工，更多的是商户，因此，需要反思和预防此类事件一再发生。
为什么恢复这么慢？
此前，也有公司发生过数据库崩盘事件，但大多在几小时之内就能恢复。这一次，微盟为何长达36小时后，还是不能恢复数据？面对此次删库事件，相信IT运维人员都应该了解，数据恢复时间快慢，一方面是因为数据量，另一方面则是困难程度。此次微盟事件，是被删除全部数据，恢复起来是要慢一些，而且还要进行校验。
经过侧面了解，这起事件主要的影响是，数据库的主备库都被删了，并且执行的是类似"rm -fr /"这样的操作。这种行为，基本上只能通过其他备库或物理备份来恢复了。但很糟糕的是，这次事故赶上特殊情况，大家都在远程办公，协同起来很慢，进而也影响了恢复速度。
做好安全防范工作的重要性
一个员工损坏数据库，就导致整个公司数据库崩盘36小时以上，带来巨大损失。这种看起来匪夷所思的行为，但确实发生了。天降横祸于身后，企业也应对数据保护进行反思，并防范此类工作再三发作。
分级措施想做到位，就得有满足需求的人员，公司上市的目的就是通过融资以改进运营状况，该做好的安全工作就应该重视。毕竟不论企业的规模如何，都应该建立并完善适合本企业数据库安全的管理思想，同时需要拥有控制权限的一系列整体方案，使得企业在面对突发事件时，能做到及时应对与冷静处理。
从专业建议上来看，为了避免和减少类似事件的影响，企业可以在系统安全保障体系的建设上进行以下几个维度的深入思考：
首先，企业账户需要严格分等级、分权限、分体系设定，比如要限制研发人员对数据库本身进行的操作，从技术上限制他们只能通过页面级的控制台进行数据项的更新及简单运维操作，部分敏感表或数据项的操作需主管审批。
其次，可以采用专业的安全运维管理平台，对日常运维操作进行安全、高效、合规的管理。例如广州世安公司推出的世安Octopus安全运维管理平台能对全网服务器、应用等资产进行统一管控，然后设置只能通过运维管理平台才能进行维护，并建立健全的运维操作权限，进行分人员分资产分权限的管理，避免权力过度集中、运维随意操作、高危操作监管真空等情况。尤其对于生产业务、重要资产、高危操作等可以加强审核，通过工单审批后才能实施操作，像删库这样的高危行为可以实时阻断，下发短信、邮件等异常告警。简而言之，如果安装了世安Octopus安全运维管理平台，微盟也不至于36小时市值蒸发10亿了。
然后，还要设立机房管理制度、不同级别和不同维度的备份机制等，尤其是核心数据，至少要实时保障2到3份以上的异机、异地备份。另外，设立系统数据快照机制，强制执行数据快照，此举可以保证一般人员无法直接修改或干预系统数据。与此同时，还可以通过实时监控、利用大数据和AI等来实现智能风控，当频繁涉及对敏感数据的操作时，给予告警、暂停、走审批等流程的风控策略。
最后跳出技术本身的限制上来，就像前面所说，再好的技术与机制都可能会有“百密一疏”的情况，毕竟人类的智慧是无穷的，意外性的“内鬼”更是防不胜防，这就需要企业在安全意识和警示培训上进行不定期进的宣传，尤其是真实案例的宣讲。
当被追责被警示的案例深入人心后，再辅以定期的安全演练，针对机房断网、断电、丢数据、服务掉线等进行联合操演，以及定期的线上考核培训等。以此从根本上让员工明白：恶意破坏系统的影响是有限的，但所需承担的后果是极为严重的。