微盟SaaS业务数据遭运维破坏，涉事员工已被拘留，数据正有序修复 作者 | 李冬梅 刚刚，微盟公司发布公告称，其业务数据遭到人为破坏，经查证系微盟研发中心运维部核心运维人员造成的恶意破坏，目前生产环境和数据修复正在有序进行。 事件回溯 2 月 25 日一早，微盟集团发布公告称，SAAS 业务数据遭到一名员工“人为破坏”，已向上海警方报案，该员工已被刑事拘留。 微盟在公告中称，2 月 23 日 19:00 左右，微盟公司收到系统监控报警，获悉 SaaS 业务服务出现故障，随后微盟公司立即召集相关技术人员进行排查，并与腾讯云技术团队一起研究制定修复方案。 2 月 24 日，公司经调查后获悉公司的 SaaS 业务生产环境和数据遭到集团研发中心运维部一位核心运维员工人为破坏，导致公司当前暂时无法向客户提供 SaaS 产品（“SaaS 生产环境和数据破坏”）。公司已于 2020 年 2 月 24 日向中国上海市宝山区公安局（“宝山区公安局”）报案，目前该员工已经被宝山区公安局进行刑事拘留。 据微盟集团所知，该员工是因个人精神和生活原因做出了上述不当行为。公司正在积极进行 SaaS 生产环境和数据的修复工作。 处理结果 根据公告，截止到 2 月 25 日 7 点，微盟的生产环境和数据修复都在有序的进行，预计 2 月 25 日晚上 24 点前生产环境将全部修复完成，微盟所有新用户将可恢复服务，老用户由于数据修复时间问题，微盟将提供临时过渡方案，预计老用户数据修复将可在 2 月 28 日晚上 24 点前完成。 对于此次事件，微盟官方发布公告称： 针对此次事故深表歉意，正在拟定相关赔付方案，以补偿因此次事故而遭受损失的商家，我们对此次因人为造成的事故灾难无比愧疚，我们今后将一定吸取这个惨痛的教训，加强对线上运维的治理，同时我们也对因远程办公而疏忽对员工的精神状态的关注而深表痛惜。 如何合理防范此类事件？ 虽然本次事故由于人为因素造成，但企业如果提前做好风险预案，可以将损失降到最低。dbaplus 社群联合发起人杨建荣老师在接受 InfoQ 采访时表示，技术、制度和流程规范，这三方面是企业在平时的运营中需要注意的。 在技术层面，企业需要注意如下 4 点： 1、完善备份恢复体系，使得恢复能够可控，高效，比如数据库增备和基于 binlog 的闪回技术； 2、集群环境的恢复是系统薄弱环节，系统服务之间互相依赖，这是之前很少有人关注的； 3、使用回收站技术，杜绝人为恶意，误删除； 4、服务权限设置，需指定客户端权限； 在流程方面，企业可以完善故障演练流程，作为一项共同目标来请协做完成，做到忙而不乱；完善故障响应流程，明确不同等级问题系统的具体负责人，并且运维操作需要报备；引入审计流程，实现独立的服务审计机制；业务异常预警，需要同步相关链路层。 在制度方面，企业的服务访问权限需要审批；定期清理无效权限或者调整密码；备份可用性检测和审计流程衔接。 如果可以把这三方面的工作做好，在遇到类似风险时可以有效将损失降到最低，避免人为造成的不可逆伤害。 技术人是保护用户数据的最后防线 最近几年，由于技术人员故意或者无意造成的事故不计其数。2018 年 3 月，Stack Overflow 发布了他们的开发者调查报告，并首次提出了有关道德的问题。对于“开发人员是否有义务考虑代码的道德影响”这个问题，有近 80％的人回答“是”。不过，只有 20％的人认为他们最终在为不道德的代码负责，40％的人会在被要求的情况下写不道德的代码，只有 50％的人表示在发现不道德的代码时会举报。 如果代码对世界的影响不大，那么这也许就不成问题。打个比方，如果你写了一个对 100 个人不利的算法，虽然这事不怎么光彩，但产生的影响也是有限的。但是，如果你在拥有数亿用户的 Facebook、Google、微信上做同样的事情，结果就会很严重。 对于开发者来说，光是每天写业务代码就已经让人心力交瘁了。更何况不管在国内还是国外，技术在大部分时候都是为业务服务，开发者的话语权是拗不过盈利这条大腿的。但是，遵守职业道德是最后的底线，如果技术人员做不到这一点，那保护用户数据的最后一道防线就会崩塌。 活动推荐 更多人工智能与机器学习相关实践请持续关注QCon北京2020，来跟业界大牛关注人工智能领域中正在兴起的技术和关键进展，探讨应用于机器学习问题的工程挑战及解决方案。目前大会8折报名中，点击【阅读原文】或识别二维码了解更多。有任何问题欢迎联系票务小姐姐Ring：17310043226（微信同号） 今日荐文点击下方图片即可阅读 一个模型大到让服务器瘫痪，这还怎么部署？ 你也「在看」吗？?? 阅读原文