3月1日晚间，微盟发布公告称，截止到3月1日晚8点，在腾讯云团队协助下，数据已经全面找回。
微盟表示，由于此次数据量规模非常大，为了保证数据一致性和线上体验，将于3月2日凌晨2点进行系统上线演练，将于3月3日上午9点数据恢复正式上线。
针对事故给商家造成的影响，微盟表示，管理层深感自责和愧疚，准备了1.5亿元人民币赔付拨备金，其中公司承担1亿元，管理层承担5000万元。
还不知道事情经过的小伙伴，可以戳下图。
从事故经过中可以看到从2月23日删库中断事件，到3月1日的数据全面找回，再到3月3日的数据恢复整个事件持续了一周多的时间。
这对于微盟这样体量的电商来说损失无疑是巨大的，股市市值的蒸发是一方面。更重要的是科技公司从本质上是经营数据的公司，而数据丢失事件与银行金库被盗事件从某种程度来说是同样性质的事件，都会对当事公司的声誉造成极大的影响。
做为一名多年战斗在银行业的IT老兵，笔者就以这个事件为切入点，来和大家聊聊大数据时代，灾备建设与数据安全方面的新趋势与新动向，提一些建设性意见。
数据治理之伤
其实数据安全的保护必须要以数据治理为前提，我们很少听说微信、支付宝宕机，这背后不是靠高可用性来保证，而是靠整个服务体系的治理水平保证的。
我们使用分布式架构对IOE进行替代，不是利用WPS替代Office的过程，而是根据数据的特点，找到能够适应大数据时代的方法论。按照笔者的观察，目前从治理角度，可以将数据分为以下三种类型：
应用数据
也就是交易类应用所产生的数据。为了满足业务需要构建业务IT系统，随着IT业务系统的不断运行，大量应用数据就产生了，这些数据经过ETL加工进入数据仓库，进行再处理，供业务应用。这些数据都是单一的关系型数据，数据量级是GB的。
用户行为数据
随着互联网和电商的快速发展，大量人的操作行为和使用行为产生的数据，像谷歌、脸书等大数据互联公司，都记录人的形成产生的数据。上网行为，浏览行为，购买行为，评论行为，刷微博，做抖音等都可以产生大量数据。这些数据不再是单一的结构化数据，出现了大量文档、音频和视频数据，数据量级是TB级的。
硬件日志数据
进入万物互联的时代之后，大量机器传感器和IoT设备都会产生大量数据。这些设备7*24小时产生数据，数据格式也是多种多样，有的是日志数据，有的是时序数据，有的是网格数据等等，数据量级是PB的。
从数据备份角度上讲，上述数据的备份需求是不同的，如果混到一起那么快速恢复业务根本无从谈起。
而从数据使用的角度上讲，随着海量的行为及日志类数据的出现，数据中心的架构将发生变化，整合TP与AP的HTAP时代既将到来。
比如目前一般银行的系统都是以Oracle数据库来进行交易操作，完成了整个流程性应用的内容，并产生应用数据数据，交易结束了，数据的生命周期也结束了。
要想把数据价值做二次表达，要每天做ETL，跑批作业，存到数据仓库中，然后在数据仓库中建模、挖掘、数据集市、ODS，一层一层地构建起数据仓库报表。
如果还回答不出更细节、隐含的问题，比如非线性问题，还要把数据复制到SAS中做机器学习，再做统计的指标体系，去做进一步的挖掘。
数据要在这里搬动三次，复制三份冗余，还要管理数据一致性，每天数据中心运维的大量工作在做数据搬家。
现在，数据中心也开始要做一个融合性的计算框架。比如，现在AI要做Online训练，淘宝推荐引擎，滴滴打车的路径动态规划都在做即时数据，数据闭环是数据基础设施的一个很大的要求。BI和AI操作都要Online化，也就是AP操作要变成TP场景。
可以说上述三类数据在流转的过程中，相互之间是有比对关系的，如果数据治理的水平够高，理清了各类数据彼此之间的一致性比对关系，那么即使出现了删库的操作也不会造成如此长时间的中断，不过从笔者目前掌握的情况来看，数据治理方面的工作并没有引起业界足够的重视。
灾备建设之伤
在讲灾备体系之前，我们先来明确评价业务连续性的两个重要指标：
RTO（Recovery Time Objective）
RTO是指灾难发生后，从IT系统崩溃导致业务停顿开始，到IT系统完全恢复，业务恢复运营为止的这段时间长度。RTO用于衡量业务从停顿到恢复的所需时间。
RPO（Recovery Point Objective）
IT系统崩溃后，可以恢复到某个历史时间点，从历史时间点到灾难发生的时间点的这段时间长度就称为RPO。RPO用于衡量业务恢复所允许丢失的数据量。
简单来讲RTO就是灾难发生后业务中断的时间，RPO就是灾难发生后数据丢失的数量。比如这次微盟的删库事件业务历时七八天完全恢复，而数据全部找回，那么其RTO就是七八天，RPO就是0。
一般来说目前比较流行的灾备体系是至少建设三个数据中心，其中：
主中心：正常情况下全面提供业务服务。
同城中心：一般使用同步复制的方式来向同城灾备中心传输数据，保证同城中心数据复本为最新，随时可以接管业务，以保证RTO的指标。但是同城中心无法应对此类删库事件。
异地中心：一般使用延时异步复制（延时时间一般为30分钟左右）的方式向异地灾备中心传输数据，其中同步复制的好处是一旦主中心被人工破坏，那么不会立刻涉及异地中心以保证RPO的指标。
一句话总结灾备体系的最佳实践就是两地三中心；同城保证业务连续性，优先负责用户体验；异地保证数据连续性，确保企业生存底线。而针对行为及日志等重要性等级不高的数据，一般采用异地磁带备份的方式。具体方式如下：
不过从目前情况看不少企业尤其是创业型企业，都没有百年老店的观念，因此在异地中心的建设上投入还不够，不过这样的模式缺点也很明显，一旦发生这种删库事件就影响就是致命的。
全面上云，势在必行
之前很多文章，分析了微盟的管理员权限过大以及涉事人员的法律负责问题，这些固然是造成此次事件的直接原因，但是笔者认为真正优秀的体系就是即使发生了恶性的操作事件也可以将风险降到最低。因此从这个角度来说，有以下几点建议：
尽快进行HTAP转型
目前的大数据时代的根本逻辑在于TP与AP的融合，而我们在上文也分析了数据治理完成后，数据最佳的使用实践就是HTAP转型。
全面上云
据称本次事件涉及微盟的核心系统其实还并没有完全上云，这就极大提升了操作风险出现的可能性。而据笔者所了解到的情况，腾讯云本身提供了相对比较完善的备份恢复功能，用户直接使用既可。
重视异地中心的建设
由于异地中心采用的是延时复制技术，在出现数据恶意损坏时是可以保命的。因此类似于微盟这样已经形成规模的企业，一定要按照标准建设异地数据中心，这样才能保证企业在极端情况下的生存。
