微盟“删库”，300万商户受伤，云数据如何保证安全？

　　微盟删库导致300多万户商家受伤

　　在经历了春节期间的疫情影响，新冠肺炎确诊患者逐步降低，很多商家正在准备恢复工作的时候，在微信上开通了微信小程序的商家突然发现在2月23日19点开始，在微信公众号上的小程序无法运行了，这个情况引起了微盟300多万户商家一片恐慌。

　　到底这是什么原因呢？原来这是负责微信小程序的公司微盟的一个核心技术人员将核心数据库给删除了！根据微盟的公告，微盟研发中心运维部核心运维人员贺某于2月23日晚18点56分通过个人VPN登入公司内网跳板机，因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏。

　　根据微盟的在2月28日的公告，微盟所有业务恢复服务数据恢复进展顺利，截止到2月28日下午14点，微盟所有业务恢复服务。微盟预计，到2月28日晚上可以恢复七成左右的数据。

　　“删库”事件影响下，百万级的平台商户均陷入了网店关闭、无法登陆和交易瘫痪的窘境，对于微盟提出的“6天才能恢复数据库”，6天（甚至还不确定的周期），对于任何一家平台商户而言，损失惨重。

　　微盟是什么公司？

　　微盟，成立于2013年的SaaS（Software-as-a-Service软件即服务）服务商，其主要业务是在微信等平台上为电商、零售、餐饮、本地生活、酒旅等企业搭建小程序，并为其提供精准营销服务，根据微盟提供的数据，目前微盟已经为超过300万商户提供这类服务。

　　核心数据该如何保护？

　　根据微盟自己的定义，那么微盟就是一个软件即服务的云服务商，一个以 技术见长的公司，可是为什么在时间过去了六天多数据库还没有全部恢复呢？到底是哪里出了问题呢？作为一个云数据服务公司，自己的核心数据库又该如何保护呢？历史上是否出现过类似事件呢？是否有什么经验教训呢？

　　早在2017年1月31日，全球第二大的开源代码托管平台GitLab内部的一位系统管理员，在给数据库做日常维护时，一时不慎运行了数据库目录删除命令。结果是虽然几经抢救修复，论坛上原本高达300GB的数据只保留下来 4.5G，直接导致当时的GitLab被迫下线。一个系统管理员的一个删除命令害了一家高科技公司。

　　后来由此很多SaaS平台公司对于删除命令或者删库这种行为，均从技术（软硬件）和管理上都做了很多限制的，保证即使误删的情况下也可以快速恢复。而微盟的一个技术人员即可以一个人删除核心数据库以及微盟经过六天多还没有完全恢复数据库，难道贺某还是一个超级黑客吗？否则的话不应该这样啊。

　　一般一个成熟的SaaS平台都会建立科学的部署结构，有着合理的内部分工和运维规范：

　　首先，主从应用。从技术上保证万一主服务出现问题的时候可以马上切换到备用从服务中。这个需要系统结构师从一开始就进行搭建，否则后面更改成本高昂。

　　其次，数据双活，多重备份。需要多做异地备份，在系统数据在多少量级时设立不同级别的物理备份。为了防止云运营商出现故障（19年几乎所有云平台都出现过几个小时的故障，影响用户都是百万以上），用户数据很大时，物理备份最好多找几个合作云平台。这个备份数据虽然有一定的延迟，当系统出现瘫痪时马上切换到出备份数据。备份数据时可能有些损失，不过这些损失的数据恢复过来时所花费的时间应该很少。

　　第三，管理分权。对于核心应用和数据库的管理一定要规范，在管理上做到一个人（即使是CTO本人）破坏系统和数据库的可能性为零：主程序运行、数据库管理、数据备份管理（如果有多个时，设立多人管理）。

　　从微盟的这次事件中可以看出，微盟忽略了这个最重要的系统安全结构的搭建。也就是说如果这次不是一个核心技术人员而是一个黑客的话就非常简单的将微盟系统破坏了。

　　从19年天猫双十一的数据来看，订单创建峰值更是创下新的世界纪录，达到54.4万笔/秒，是2009年第一次双11的1360倍。这个数据是建立在阿里自己的云上，已经成功征服住全球最大的数据流量洪峰。

　　在阿里这么大的数据面前，如果没有稳定的数据安全机制，那么出现微盟删库这样的事情的话，就将是一个电子商务上的灾难事件，影响的就不只是简单的300万商户了。

　　小编结语

　　疫情之后，各类云服务蓬勃发展，在云服务方面，系统首先一定要注意心态稳定，保证稳定超过一切。所有云服务只有在系统安全稳定的基础上才能得到长久的发展。管理分权、应用主从自动替换、数据双活方案、数据多云相互备份（多重保护）等都需要从一开始就考虑周全，才能保证系统稳定。

　　谢谢您动动金手指关注和转发

　　2019双十一销售再创新高真的就是好事吗？

　　健康码来了，大数据打通复工最后一公里！

　　钻石公主号：如何从豪华游轮变成了恐怖游轮？

　　NASA说今天地球引力最小能让扫帚立起来是真的吗？

　　大数据的精准分析已成为“反腐利器”，让贪腐无处藏身！