被删库后，微盟放弃自建数据库，全力上云

被删库后，微盟放弃自建数据库，全力上云

2020 年 2 月 25 日，微盟发布公告称，公司线上生产环境及数据遭到员工恶意破坏，导致公司系统服务不可用。经过几天的“抢救”，3 月 1 日，微盟再次发布公告称，数据已全部找回，将于 3 月 2 日进行系统上线演练，于 3 月 3 日上午 9 点恢复数据正式上线，同时针对受到影响的商家也给出了赔付计划。

事件回溯

“删库跑路”一直是运维人员常挂在嘴边的戏谑之词，但当现实生活中真的发生了，还是让人震惊不已。相信关于微盟被删库事件，大家多少都有所耳闻，不过，为了照顾不清楚前因后果的同学，这里先为大家梳理一下整个事件的经过。

2020年2月23日18时56分，微盟研发中心运维部核心运维人员通过VPN登入服务器，并对线上生产环境进行了恶意破坏；

2020年2月23日19时，微盟内部系统监控报警，出现大面积服务集群无法响应；

2020年2月25日，微盟紧急恢复了核心业务的线上生产环境，保证新用户使用不受影响，并提供老用户临时过渡方案，确保商家在数据暂时没有恢复的情况下可以正常经营；

2020年2月28日，微盟恢复了所有业务的线上生产环境，并且开放了老用户登录，以及恢复了微站产品的所有数据；

3月1日，微盟发公告称已全面找回数据。

微盟发布的公共中也对接下来的数据恢复工作，做了计划部署。3月2日凌晨2点至8 点，微盟进行数据恢复上线演练，在此期间微盟系统会停止服务，演练完成后系统数据回滚到3月2日的数据3月2日晚上10点至3 月3日上午9点，微盟将正式进行数据恢复上线， 恢复2月23日之前的数据，同时将2 月23日与3月2日的数据进行合并，完成所有的数据恢复工作。

微盟事后处理方法

根据公开资料显示，微盟目前的渠道代理商超1600家，注册商户超300万。此次微盟宕机或导致300万商家生意停摆，损失巨大。因此，微盟也公布了商家赔付计划，整体准备了1.5亿元人民币赔付拨备金，其中微盟公司承担1亿元，管理层承担5000万元。

针对商家因系统不可以而造成的不同损失，微盟也制定了不同的赔付方案：

现金赔付计划

针对因系统不可用而造成利润损失的商户，微盟将按照商家边际贡献利润额进行赔付，具体公式计算如下：

边际贡献利润额 = 日均收入×行业平均边际贡献利润率×系统故障时间

流量赔付计划

针对因系统不可用而造成流量损失的商户，微盟将给予腾讯广告 50000 曝光次数的流量补偿，并且提供账户运营服务，同时再延长 SaaS 服务有效期两个月。

放弃自建数据库，基础设施全力上云

以上是经济方面的赔偿，在技术方面，此次核心运维对微盟生产环境和数据造成破坏，使得商家对微盟系统安全和稳定性产生了质疑，同时也给微盟自己敲响了警钟。

微盟在3月1日发布的公告中称，微盟将会支持基础设施全力上云，逐步放弃自建数据库服务 ，迁移到腾讯云数据库（CDB），增加数据库跨可用区和异地灾备的能力，同时将黑石1.0 物理机全面升级黑石2.0，全面使用云主机。

除了之外，微盟还宣布将加强数据安全管理机制和安全灾备体系建设。

据了解，微盟将使用腾讯 AM权限系统进行云资源管理，严格执行分级授权和最小集权限制度，对高危险动作执行二次授权制度。

针对开发环境、测试环境和生产环境进行严格隔离，使用云堡垒机替换自建堡垒机，进行细粒度权限分级和授权管理，严格审计操作日志，发送安全审计报表。

同时，微盟将在北京、上海、南京等地区建立全备份的冷备系统架构，并建立高可用的同城双活架构，所有云主机启用每天快照策略，保证全量和增量备份，所有非结构化数据库使用腾讯COS对象存储系统归档保存，启用多异地复制功能，数据存放多地，COS 冷存储，确保数据只增不减。

删库事件如何避免和补救？

回顾最近几年的删库事件，我们发现并不在少数，删库原因也各种各样，有误删，有介质损坏，也有人为删除的。

2015年5月，携程员工操作失误，删除了生产服务器上的执行代码，导致官方网站和应用程序大面积瘫痪，无法正常使用；2017 年1月，开源代码托管平台GitLab系统管理员对数据库进行日常维护时，无意中运行了数据库目录删除命令，导致300GB的原始数据只保留了4.5G，GitLab 被迫下线。

微盟被删库事件，引发了运维领域众多技术专家和从业人员的讨论，针对如何预防删库，如何恢复数据，纷纷提出了自己的观点。我们整理了部分技术专家针对此提出的建议：

人肉运维是隐患

“直接在生产环境中敲命令是一种非常不好的习惯。”左耳朵耗子曾表示，一个公司的运维能力的强弱和上线上环境敲命令是有关的，越是喜欢上线敲命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。你敲了什么命令没人知道，但是你写个工具做变更线上系统，这个工具干了什么事，看看工具的源码就知道了。

数据备份系统足够强

系统是需要做数据备份的，但有时就算所有的备份都可以也会避免的出现数据丢失。左耳朵耗子表示：“如果你要让你的备份系统随时都可以用，那么就要让它随时都Live 着，而随时都Live着的多结点系统，基本上就是一个分布式的高可用的系统。因为数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist 等等都只是让人不要误操作，都不管用，这个时候，你不得不用更好的技术去设计出一个高可用的系统！别无它法！

MSP上云是个好方法

技术专家认为数据放在云端的保险系数还是相对较高的，因为云端有足够多的公共资源作为支撑。其中，快照和异地远程复制灾备服务是云端提供的非常好用的功能，建议大家使用。当发生数据删除时，可以使用快照迅速恢复或者回滚到某个历史时刻，然后再通过其他方法补平到最新数据状态；而云端异地远程复制灾备服务也是比较成熟的技术，相比本地实施的容灾，初期投入更加划算。

建立分级授权机制

即使数据容灾做得再好，也难以避免内部人员的主动破坏，因此建立分级授权机制是很有必要的，高危操作必须多人仲裁表决才能执行。

本文转自网络，站长持续关注微盟的事件，因为对于saas应用而言，数据库是核心，此次事件我们应该引以为戒。

​