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

2 月 25 日，微盟发布公告表示 SAAS 业务数据遭到人为破坏。经调查后获悉公司的 SaaS 业务生产环境和数据遭到集团研发中心运维部一位核心运维员工破坏，导致公司当前暂时无法向客户提供 SaaS 产品（“SaaS 生产环境和数据破坏”）。

公司已于 2020 年 2 月 24 日向中国上海市宝山区公安局（“宝山区公安局”）报案，目前该员工已经被宝山区公安局进行刑事拘留。本文，InfoQ 邀请了 dbaplus 社群联合发起人杨建荣，给企业提供一些防范风险的建议，希望对从业者有所帮助。

以下为杨建荣老师回复全文：

每每看到行业内的数据事故，我们在感慨之余，更需要的就是自省，因为这可以敲响我们的警钟。微盟技术团队从一个创业团队一路走来，逐步建立了较为成熟的安全管理规范，对服务器和数据访问权限有着明确的分层和分级的授权管理制度，这次虽然有疏忽，实际上也是受害者。

根据事件跟踪得知，腾讯云本次从一开始就大力支持微盟，派了很多技术专家，不计成本来帮助微盟和微盟的客户，使得恢复得以顺利开展。但问题是要补救和修复，需要一套流程、制度和技术相辅相成，而且是一个持久改进的过程。米兰.昆德拉曾经说过：永远不要以为可以逃避，因为每一步都决定着最后的结局。

从个人理解来看，因为涉及的环境复杂、涉及团队较多，所以恢复效率和验证方面需要一些时间。在数据恢复方面，有一条不成文的规定，那就是数据在一定程度上可以丢，但是不能乱。丢的数据，可以通过其他方式进行补救，但是数据一乱就失去了修复基准。因为这次是人为恶意操作，所以恢复的难度会更大。

接下来，我通过流程、技术和制度三方面来分别进行阐述，如何在此类事故中将损失降到最低，希望对企业有所帮助。

1、流程

1.完善故障演练流程，作为一项共同目标来协作完成，做到忙而不乱

很多公司都会对故障演练存在一些疑虑，因为这会带来一些潜在的隐患，越是不能动，不敢动，在出问题的时候，修复效率越低下，每个人和团队更加关注自己这一部分的工作，显然会忽略一些相关环节，所以能够组织故障演练的流程和规范，把这些梳理和固化下来，在处理问题时才能够做到忙而不乱。

2.完善故障响应流程，不同等级的问题系统由具体的负责人介入

为什么很多问题的修复进展不可控？一方面是需要团队协作；另一方面是临时去协调和熟悉问题，排查问题的效率是比较低的，可以考虑引入故障的等级分类，及时通知相关团队，把一些问题的处理作为预先处理的环节提前接入。

3.运维操作需要报备

运维不做无准备的操作，不做加塞操作（比如临时补充一些未经测试的脚本），重要操作，重大操作都需要报备，及时通告，把被动变为主动。

4.引入审计流程，实现独立的服务审计机制

审计环节是一个相对重要的独立环节，可以引入服务审计机制，可以通过独立的审计服务发现潜在的隐患，及时督正问题。

5.业务异常预警，需要同步相关链路层

对于业务层的异常，业务预警尤其关键。及时预警并同步到相关链路，可以避免系统雪崩的情况。

2、技术

1.完善备份恢复体系，使得恢复能够可控，高效。比如，基础备份（全备和增量备份）和热数据恢复(基于 binlog 的闪回技术)

备份恢复体系的建设是数据库建设的基础，也是衡量服务可用性的最后一根稻草，充分结合全量备份和增量备份，提高恢复效率。

举例来说，下面是一个全量备份和增量备份方案，实现一次全备，永远增量的实现策略，然后在这个基础上实现基于 binlog 的闪回。

2.集群环境的恢复是系统薄弱环节

系统服务之间互相依赖，这是之前很少有人关注的，所以毫无疑问，这是一块硬骨头，我们需要重点关注。

3.使用回收站技术，杜绝人为恶意/误删除

备份能够解决一些异常情况下的数据恢复，但是效率相对不高，从规范角度来说，如何避免危险操作，转而使用更加优雅可控的处理方式是我们需要思考的问题。

Drop 操作是默认提交的，而且是不可逆的，在数据库操作中都是跑路的代名词，MySQL 层面目前没有相应的 Drop 操作恢复功能，除非通过备份来恢复，但是我们可以考虑将 Drop 操作转换为一种可逆的 DDL 操作。

MySQL 中默认每个表有一个对应的 ibd 文件，其实可以把 Drop 操作转换为一个 rename 操作，即把文件从 testdb 迁移到 testdb_arch 下面；从权限上来说，testdb_arch 是业务不可见的，rename 操作可以平滑的实现这个删除功能，如果在一定时间后确认可以清理，则数据清理对于已有的业务流程是不可见的，如下图所示。

此外，还有两个额外建议，一个是对于大表变更，尽可能考虑低峰时段的在线变更，比如使用 pt-osc 工具或者是维护时段的变更，这里就不再赘述了。

4.服务权限设置，需指定客户端权限

分业务管理主库和备份库是互联网行业的普遍惯例，很多公司普遍都会授予运维较大的权限，这也是导致很多故障发生的潜在隐患。

在这方面我们可以参考如下的一张设计图（来自张文宇老师），可以在多个环节发力，改进权限问题。

3、制度

制度相对来说是比较严格、冷面的，我们可以在技术和流程规范之中寻找一些平衡点来辅助作为制度的基石。比如，密码的安全等级设置，权限管理引入审批制度等，在此就不赘述了。

结束语

最后，希望所有技术从业人员可以遵守职业道德，希望所有企业可以具备风险防范意识，在这类事件中有效降低损失。

作者介绍：

杨建荣，dbaplus 社群联合发起人，Oracle ACE，竞技世界资深 DBA