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. 服务权限设置 ， 需指定客户端权限
分业务管理主库和备份库是互联网行业的普遍惯例 ， 很多公司普遍都会授予运维较大的权限 ， 这也是导致很多故障发生的潜在隐患 。
在这方面我们可以参考如下的一张设计图（来自张文宇老师） ， 可以在多个环节发力 ， 改进权限问题 。
5. 上云是个好方法
技术专家认为数据放在云端的保险系数还是相对较高的 ， 因为云端有足够多的公共资源作为支撑 。 其中 ， 快照和异地远程复制灾备服务是云端提供的非常好用的功能 ， 建议大家使用 。 当发生数据删除时 ， 可以使用快照迅速恢复或者回滚到某个历史时刻 ， 然后再通过其他方法补平到最新数据状态；而云端异地远程复制灾备服务也是比较成熟的技术 ， 相比本地实施的容灾 ， 初期投入更加划算 。
3、制度
制度相对来说是比较严格、冷面的 ， 我们可以在技术和流程规范之中寻找一些平衡点来辅助作为制度的基石 。 比如 ， 密码的安全等级设置 ， 权限管理引入审批制度等 ， 在此就不赘述了 。

稿源：(EGO)

【】网址：http://www.shadafang.com/c/hn1023aV432020.html

标题：数据库|作为创始人，我不小心删除了生产数据库，还跑路吗？( 二 )