点击“技术领导力”关注∆ 每天早上8:30推送
作者| Mr.K 编辑| Emma
来源| 技术领导力(ID：jishulingdaoli)
微盟经历了8天的至暗时刻，数据修复工作终于有了进展，并于3月1日对外发布公告：
截止到3月1日晚8点，在腾讯云团队协助下，经过7*24小时的努力，我们数据已经全面找回，由于此次数据量规模非常大，为了保证数据一致性和线上体验，我们将于3月2日凌晨2点进行系统上线演练，将于3月3日上午9点数据恢复正式上线。
此次事故给商家经营造成了严重的影响，公司管理层对此深感自责和愧疚，我们准备了1.5亿元人民币赔付拨备金，其中公司承担1亿元，管理层承担5000万元。在紧抓数据恢复的同时，也在同步研究商家赔付方案，我们拟定了现金赔付计划和流量赔付计划供商家选择。
公告中宣布了对商家的补偿计划，总共赔付1.5亿，其中公司掏1亿，管理层掏5000万。堪称史上最贵宕机罚款，被罚高管包括：CEO孙涛勇、CTO黄骏伟、SaaS负责方桐舒等。高管不是那么好当的，前几年靠运气赚的钱，这几天凭本事全亏光了。
公告中，还提到了数据安全保障计划，内容截图如下：
图片来自微盟官方公告
熟悉老K的读者知道，老K曾担任沪上知名电商公司运维总监，下面我们尝试用互联网公司的事故分析方法（Postmortem），对微盟本次事故做复盘分析，以帮助大家更好的理解本次事故的原因和改进措施，并从中吸取宝贵经验。
事故经过回放
时间线，关键举措，结果
2月23日，线上生产环境及数据，遭到恶意破坏，导致系统服务不可用。
2月25日，紧急恢复了核心业务的线上生产环境，新用户使用不受影响，但是旧数据无法恢复。
2月28日，恢复了所有业务的线上生产环境，老用户可以登录，恢复了微站产品的所有数据。
3月1日晚8点，全面找回数据，做数据一致性和线上体验。
3月2日凌晨2点至8点，进行数据恢复上线演练，演练完成后系统数据回滚到3月2日的数据。
3月2晚上10点至3月3日上午9点，进行数据恢复上线，将2月23日与3月2日的数据进行合并，所有数据恢复完成。
实际在做事故复盘的时候，描述不会那么简略，必须包含：谁在什么时间点，做了什么，结果是什么。力求真实还原当时事故发生时的情况。这个环节，先申明不定责，只需要把事故过程描述出来，以便做下一步的事故分析。
事故复盘分析
改进措施，改进计划，定责
在做事故复盘分析时，对于事故过程的每个步骤，进行展开讨论，这一步我们做了什么？没做什么？怎么做效果会更好，我们如何改进？然后将分析的结果写下来，我们以微盟事故为例，分析结论如下：
1、引入外部安全专家，一起评估整改方案。这个操作并不是说微盟的数据安全团队没人。当然了，出了这么大的事情，数据安全团队是难辞其咎的。引入外部安全专家，主要是解决公信力的问题。出了这么大的事，你说你要整改，谁还敢信啊？引入外部专家，能解决信任问题。但是，方案落地工作还是微盟安全团队自己做的，也就是说，干活的还是同一拨人。
2、放弃自建数据库服务，全面使用腾讯云的云数据库。可以看出来，之前的方案是采用腾讯云的物理机，然后自建MySQL集群方案。大家会觉得奇怪，为啥要这么干？既然用了腾讯云，那还不用整套云数据库？原因不外乎，一是不愿意把自家最核心的数据资产，放在别人家里，哪怕你家有很好的保险柜，人性使然。二是对自己的数据方案、团队能力，都比较有信心，认为不就是个数据库嘛，搞得定。
3、数据安全机制的执行过程有漏洞。在改进措施中强调了，严格执行授权审批、使用腾讯云CAM进行云资源管理、分级授权，高危动作进行二次授权。比方说删库跑路这类操作，必须二次授权。倒不是说之前没有这些制度，只是没有严格执行。引入外部审计还是有必要的。
4、对开发/测试/预发布/正式环境，未做严格分离。这种情况在许多互联网公司，是非常普遍的，一是因为多套环境的建立，需要花费软硬件成本，二是需要专门团队和成熟的维护工具。做好了，工程效能得到极大提高，弄不好就磕磕绊绊，还不如开发、测试、正式环境混用，虽然有安全隐患，但是架不住方便啊。于是，大家就默认了，忽略了最基本的安全问题，平时没什么，一旦碰上情绪不稳定的运维人员，就悲剧了。
5、缺乏多云灾备、双活方案。老K在上一篇文章中，就做过论断：微盟本次事故，缺乏数据中心双活方案、数据灾备方案，不幸都被言中了。从整改措施里，也可以看到将建立三个城市的全备份的冷备系统架构。
6、缺乏日常演练。故障演练，指的是人为随机造成系统故障，比如偷偷到机房，随便拔掉某台机器网线或电源，看看系统能不能自恢复。高级一点的，是用软件来对生产环境进行故障注入，类似阿里的混沌工程、奈飞（Netflix）的Chaos Monkey等，通过随机制造的故障，检验系统的高可用性，暴露结构性风险。
最后一步，整理改进计划，落实到具体负责人，时间点，由QA团队进行跟进，跟踪短期和中长期的改进措施，直到执行结束。
以上，我们采用互联网公司事故复盘的方法，对微盟整个事故做了分析，关键是思路和方法。我们要善于借鉴他人的宝贵经验，毕竟1.5亿的经验教训，这个学费不是每个公司都交得起的。
总体来看，事故给微盟造成的负面影响是短期的，只要微盟顺利解决技术管理问题，那基本面对微盟仍然有利的。而事故给微盟带来的教训，却是非常宝贵且有长期价值的。从这一点来讲，长期看微盟一点都不亏。
截止发稿前，微盟股票已经反弹了，非常庆幸上周入了一点点，微盟加油！
作者简介：K，知名电商公司技术老K级人物。武做过CTO，文出过畅销书，带你一起洞见技术新时代。
-END-
关注“技术领导力”公众号
老K主理，文出过畅销书、武做过CTO
用故事讲技术，有趣，有料！
想加入社区，跟100位互联网大咖学习？
添加群助理Emma，注明“加群”
技术领导力社群
大家在看：
喜欢就点在看！
