共计 1307 个字符，预计需要花费 4 分钟才能阅读完成。
前言：
时常有听到各公司数据库故障的案例，比方数据库宕机了、误删数据了、歹意删库了等等。可能还有更多的故障没有披露进去。每次产生此类事件，都会在互联网圈引起热议，其实更应该留下的是警醒，咱们应该足够器重数据库安全问题，对数据库要有敬畏之心。
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 机制，请共事帮忙测验。
- 不要在疲劳状态下操作数据库。
- 要有责任心，记得本人操作了啥，出问题不要回避。
总结：
写本篇文章的目标是为了告诫大家，对数据库要有敬畏之心，不要认为天经地义，可能一个很小的操作会导致很重大的结果。当然，人非圣贤孰能无过，兴许只有经验过一些事变能力更好的成长，咱们要做的就是尽可能减少事变产生。
