微盟删库事件复盘与思考
文章目录
事故
先简单看一下整个事故的粗略时间线。
2月23日,微盟服务出现故障。商家商城、小程序均无法登录。
2月25日,微盟紧急恢复了核心业务的线上生产环境,新用户使用不受影响,并提供老用户临时过渡方案,确保商家在数据暂时没有恢复的情况下可以正常经营。
2月28号,微盟表示已经恢复了微站产品的所有数据,并已导入到商户店铺,新老用户使用将不受影响。
3月1号微盟表示数据已全面找回,并公布商家赔付计划。
影响
首先看股市反应:数据丢失,微盟损失惨重。在2月25日正式披露数据丢失后,微盟的股价连续三日大幅下跌,从6.2下跌到4.8差不多跌了25%,整个市值蒸发20亿元以上。
除此之外,本次事故对微盟的社会公信力有很大的影响,说明整个企业在运营、管理和技术安全上是有问题的,对企业的社会形象和商业业态都会遭受大家的质疑。
由于微盟整个系统的宕机,导致商家与消费者都不正常运营,部分可能直接停业,对整个社会的经济系统也有一些冲击与影响。
问题
作为一名局外人,对这次微盟删库事件,个人有以下问题:
- 运维贺某是由于什么原因作出删库的事件?
- 贺某删除了哪些数据?贺某删除整个生产环境的数据包括备份数据吗?
- 微盟是数据架构是如何设计?让一个运维能够删除整个生产环境的数据?
- 微盟的数据物理分布是如何设计的?
- 微盟运维权限是如何管理?
- 微盟离线备份数据是备份方式是怎么样?是增量还是快照方式?
- 微盟离线备份数据为什么花了五天都不能够恢复?离线备份数据有多少?
- 众多离线备份数据是如何恢复的?
- 微盟离线备份数据是否完整?
- 微盟离线备份数据恢复后如何验证?如何检查恢复数据与备份数据之间的一致性?
- 微盟离线备份数据恢复是否相互依赖?
- 微盟离线备份数据(毕竟微盟成立于2013年)是否兼容?如与应用程序兼容?
- 微盟离线备份数据恢复的速度的瓶颈在哪里?网络带宽?硬盘IO? 数据不能并行恢复?验证困难?
- 从备份数据到线上数据恢复,是恢复几份数据?如何保证这几个线上数据的一致性?
- 如何防止误操作?
- 如何量化赔偿商家的损失?
- 如何快速检测运维违规操作并迅速报警?
- 是否知道技术风险的存在,由于存在侥幸心理和事不关已,多一事不如少一事,放过这个潜在的风险?
经验教训
微盟经过七天七夜的抢救,成功救回了全部数据,从结果上来看是一次成功的抢救。但是数据恢复的时间太长,服务高可用直接打到99%以下。
事后微盟发布了改进计划,这些改进计划有针对性回答我上面一些问题。
|
|
上面这些总结很到位,个人帮微盟补充一些:
- 学习netfix的企业文化中的第一条:招聘成年人。成年人不会作出对个人和公司双输的事件,成人有自己调整心态与控制情绪的能力。
- 学习netfix的实践,应用混顿工程,主动拥抱故障,提前演练与操作。国内阿里双11每年都要进行演练。
- 减少对人的依赖。在执行方面机器比人靠谱多了。
总结
总之,微盟这次删库事故是技术债与管理债长期累积不解决的结果。欠债不还,一定会在某个时间被某个黑天鹅事件引爆。
这次显露出来的技术问题的本质是数据高可用性技术的不足。
欢迎关注
欢迎关注微信公众帐号:沉风网事(savewind)
文章作者 沉风网事
上次更新 2020-03-08