其他
“微盟系统遭恶性删库事件”深度报告：今天就用3W方法还原其前因后果，并反思有哪些教训
【ZOOM CEO Eric Yuan当年经常对我们说，敲他Office的门之前，要把三个问题想清楚：What’s problem？ What’s root cause？What’s solution？这就是3W方法。今天我就用3W方法来分析 “微盟系统遭恶性删库事件”】
1. 问题是什么？
先上视频，问题（problem）就清楚了。如果心疼自己的流量，就跳过视频，直接看后面的“事件简要回顾”文字。
今年2月23日，18:56分，微盟研发中心运维部核心运维人员通过VPN登入服务器，并对线上生产环境进行了恶意破坏，包括数据库备份服务器； 2月23日 19 时，微盟内部系统监控报警，出现大面积服务集群无法响应，生成环境即数据遭受严重破坏，微盟公司立即启动应急响应机制； 2月24日，微盟在成功定位到嫌疑人登录账号及IP地址后，向宝山公安局报案。目前犯罪嫌疑人已被宝山区公安局刑事拘留，承认了犯罪事实。 2月25日7 时，生产环境和数据修复在有序进行（即得到部分恢复），预计25日晚24点生产环境修复将完成，到时新用户将得到正常服务，而老用户数据修复需要更多时间，直到2月28日晚上才有可能恢复。
从受害方微盟集团看，经济和公信力受到双重打击，特别是极大影响微盟的社会形象和商业生态，这种损失是不可估算的。截至2020年2月25日10点整，微盟集团报5.620港元，跌幅5.23%,市值约蒸发12.53亿港元，同时带给微盟客户的损失不可估量，特别是对微盟的老用户，由于系统故障5天无法使用服务，某些客户受疫情影响，其线下业务已经遭到重创，那现在线上业务又受到打击，真可谓屋漏又逢连阴雨。 对犯罪嫌疑人，根据《刑法》第二百八十六条等相关规定，如果达到“后果特别严重”这一标准，将被处五年以上的有期徒刑。之前，杭州某科技公司的技术总监，也是因不满被老板开除、心生报复，删除了数据库上的一些关键索引和部分表格（破坏比此案小多了），其结果因破坏计算机信息系统罪被判处有期徒刑二年六个月。
2. 根因是什么？
缺乏对数据保护更全面的规划，没有一套完整的数据保障体系； 有防黑客的安全措施，没有防内鬼的安全措施。这个问题比较容易发生，因为运维的管理制度本身就是由运维人员来制定，如果高层CIO/运维总监不亲自抓这样的事或不专业，这样的漏洞就大概率会存在。 权限设置是否合理。 备份/恢复技术还比较落后； 没有异地备份（灾备）数据中心或多节点备份机制，也没有更可靠的故障转移机制； 平时没有做过演练。这次恢复的时间很长，部分恢复是36个小时，而整个恢复将超过5天。
问题产生的根本原因找到了，其解决方案（solution）也就不难了，我们就能找到对症下药的解决办法。
首先要解决人的问题，多给员工一些必要的关怀和培训。正如上面所说的，对自己的招聘环节需要重新审视一遍，看看有没有改善的地方。平时员工的培训，特别是核心员工的培训，不能局限于专业技术（如Linux、shell脚本、网络协议、DevOps、AIOps等）的培训，而且需要进行职业道德、法律、心理等多方面的培训。
其次，要审视运维相关流程、规章制度和环境安全设置等，其中有没有漏洞，例如root权限的密码是不是受到严格的保护、通过远程IP地址访问的用户干不了任何危险的操作。有些专业公司还开发了“特权会话管理器”，杜绝危险操作、监控危险操作行为、定期更改root密码（连维护管理员都不知道）。
最后，在技术上增强数据安全保障措施，健全数据保障体系：
是否考虑全面部署自动化运维工具，极大地降低手工误操作带来的风险。 运维人员分工更细一些，设置更细、更安全的权限管理机制——不同级别的执行权限及对应的审批权限。 业务运维、网络运维、DBA 等都不能执行系统层的 rm 指令，系统运维也不能执行数据库的指令 在系统架构和系统备份技术上是不是需要升级换代？例如备份系统每次备份在完成之后，会自动完成数据有效性验证。 是不是要做常规的防灾演练，虽然很难。不在生产环境做，可以在测试环境、准生产环境进行演练，模拟各种可能的情况，类似混沌工程、可靠性故障注入测试等。 要不要加大投入、增加异地备份机制或者引入CDM（Copy Data Management）这种备份新技术？ ......
参考：
只要坚信自己，任何目标都是能实现的
不得不谈谈农历新年首次质量大事故：GitLab丢失数据
QECon演讲话题征集令到了，欢迎来接