被删库后,微盟赔付 1.5 亿,放弃自建数据库,全力上云

阅读数:2 2020 年 3 月 2 日 12:21

被删库后,微盟赔付1.5亿,放弃自建数据库,全力上云

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 等等都只是让人不要误操作,都不管用,这个时候,你不得不用更好的技术去设计出一个高可用的系统!别无它法!”

上云是个好方法

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

建立分级授权机制

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

相关阅读:

微盟 SaaS 业务数据遭破坏,涉事员工已拘留,数据正有序修复

因运维恶意操作,微盟宕机 36 小时,企业如何加强风险防范能力?

评论

发布