1.案列盘点
我们再来回忆下近几年互联网圈发生过的“删库事件”。
2018 年 9 月份，据网上信息披露，顺丰科技数据中心的一位邓某因误删生产数据库，导致某项服务无法使用并持续 590 分钟，最终公司决定辞退工程师邓某，并在顺丰内网通报。
邓某错选了 RUSS 数据库，打算删除执行的 SQL。在选定删除时，因其操作不严谨，光标回跳到 RUSS 库的实例，在未看清所选内容的情况下，便通过 delete 执行删除，同时邓某忽略了弹窗提醒，直接回车，导致 RUSS 生产数据库被删掉。
因运维工作人员不严谨的操作，导致 OMCS 运营监控管控系统发生故障，该系统上临时线上发车功能无法使用并持续了 590 分钟
2020 年 2 月 23 日，微盟运维人员贺某因个人精神、生活等原因对微盟线上生产环境进行了恶意破坏，直接导致公司 SaaS 业务突然崩溃，基于微盟的商家小程序都处于宕机状态，300万家商户生意基本停摆，生意快做不下去了。同时，微盟自身也蒙受巨大损失，短短几天公司市值就蒸发超过 20 亿港元。
事件发生后，微盟团队与腾讯云团队并肩作战，尽全力抓紧修复，直到 3 月 1 日晚上 8 点，数据终于全面找回，并于 3 月 3 日上午 9 点数据恢复正式上线。尽管作恶的贺某在第一时间被警方抓获，但并不足以弥补给微盟、商家带来的损失。
2.经验与教训
从以上案例我们可以看到，一旦数据库发生重大故障，负面影响会非常大，对公司造成极大的损失。造成事件的主要人员也可能面临被辞退或负刑事责任的风险。
有人说了，为啥数据库故障这么难修复，不是都有备份的吗？其实还是想得太简单。真的发生此类故障，可能首先需要冷静下来制定恢复策略，要考虑最新的备份是什么时候的，是否可用，新产生的数据如何补齐，恢复时间预计多久，出现数据冲突问题如何处理等等。
那么我们从此类事件中可以得到哪些经验与教训呢？若想尽可能避免数据库故障，谈一谈笔者自己的看法。
公司制度方面：
- 通过堡垒机控制服务器权限，做好环境区分，最好有运维审计系统。
- 有详细的数据库变更流程，并责任落实到岗到人。
- 定期检查备份可用性，制定周期性演练计划。
数据库方面：
- 竭力完善数据库高可用架构，最好可以留个延迟从库。
- 数据库账号权限尽可能小，不允许个人使用程序账号。
- 有完整的周期性备份策略，最好增加异地备份。
- 增加数据库审计，对数据库流量或日志审计，设定告警通知机制。
技术人员方面：
- 熟悉你使用的可视化工具，SQL要看清楚再执行。
- 陌生环境不要操作，特别是古老的环境。
- 不做自己职责以外的操作。
- 数据变更之前记得备份。
- 高危操作要有 check 机制，请同事帮忙检验。
- 不要在疲劳状态下操作数据库。
- 要有责任心，记得自己操作了啥，出问题不要逃避。
总结：
写本篇文章的目的是为了告诫大家，对数据库要有敬畏之心，不要认为理所当然，可能一个很小的操作会导致很严重的后果。当然，人非圣贤孰能无过，也许只有经历过一些事故才能更好的成长，我们要做的就是尽可能减少事故发生。
