微盟事情的反思：希望删库跑路永远是一句玩笑而已

读完需要9 分钟

速读仅需7分钟

相信这些天微盟的事情大家已经听说了。

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

根据事件跟踪得知，本次腾讯云从一开始就大力支持微盟，派了很多技术专家来帮助微盟和微盟的客户，使得恢复得以顺利开展。

但是问题要补救和修复，需要一套流程和制度和技术相辅相成，而且是一个持久改进的过程。米兰.昆德拉曾经说过：永远不要以为可以逃避，因为每一步都决定着最后的结局。

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

我打算通过如下的三个部分来进行阐述。

流程：

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

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

2.完善故障响应流程，什么等级的问题系统哪些负责人介入

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

3.运维操作需要报备

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

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

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

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

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

技术：

1.完善备份恢复体系，使得恢复能够可控，高效。

比如基础备份（全备和增量备份）和热数据恢复(基于binlog的闪回技术)

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

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

2.集群环境的恢复是系统薄弱环节。系统服务之间互相依赖，这是之前很少有人关注的，所以毫无疑问，这是一块硬骨头，我们需要重点关注。

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

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

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

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

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

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

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

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

制度：

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

希望删库跑路只是大家的一种玩笑，一旦当真就麻烦了。