本文图片

作者 | 核子可乐、钰莹
这次真的只是误删！
猛然发现生产数据库被删除了
近日 ， 国外用于评分的在线软件提供商 KeepTheScore 猛然发现生产数据库被意外删除 ， 超过 300 块计分牌及相关数据瞬间化为乌有 。
好在该公司使用的数据库是云托管数据库 ， 云提供商每天都会进行一次自动备份 。 经历了 5 分钟的绝望 ， 技术人员进入网站维护模式 ， 而后开始恢复备份 。 到当天晚间 11:15 左右 ，即发生灾难的 30 分钟之后 ， 数据库已经恢复上线 ， 只是过去 7 个小时的数据再也无法找回 。
更确切地讲 ， 2020 年 10 月 17 日下午 15：47 至 23：21（CET 时间）之间创建或添加的所有数据均已丢失 。
在 KeepTheScore 的回应中写道：“谢天谢地 ， 这场灾难并没有威胁到员工的岗位——创始人不会解雇开发者 ， 因为他们俩是同一个人 。 另外 ， 这款应用只是个小项目 ， 而不是那种用于支撑电厂运转的大工程 。 尽管如此 ， 我们还是拥有不少用户 ， 其中还有一些付费用户 。 我们一直努力让他们满意 ， 但这次事件让他们失望了 ， 真的非常抱歉 。 ”
据公司介绍 ， 删除数据库的函数是在完全严肃清晰的情况下编写而成的 。 这条函数会删除本地数据库 ， 并从零开始创建所有必要表 。 就在当天晚上 ， 编程工作仍在继续的同时 ， 该函数接入了生产数据库并将其擦除 。
下面就是引发这场灾难的代码：
请注意 ， 其中 host 是被硬编码至 localhost 当中的 。 这意味着它不应连接到除开发者设备之外的任何机器 。 当然 ， 我们会在开发及生产当中使用不同的密码及用户名 。
KeepTheScore 意识到 ， 单是拥有一条能够删除数据库的函数就已经非常危险 。 问题是 ， 大家永远无法真正正确而全面地测试安全机制 ， 因为这样的测试要求将矛头指向生产数据库 。 通过此次事故 ， KeepTheScore 也意识到拥有一套能够快速恢复的备份有多么重要 。
另外 ， 即使是灾难也会有好的一面 。 但最重要的是 ， 无法百分之百确定类似的问题不会再次发生 。 计算机系统实在太过复杂 ， 总有一天小毛病会再次惹出大麻烦 。
删库事件如何避免和补救？
回顾最近几年的删库事件 ， 我们发现并不在少数 ， 删库原因也各种各样 ， 有误删 ， 有介质损坏 ， 也有人为删除的 。
2015 年 5 月 ， 携程员工操作失误 ， 删除了生产服务器上的执行代码 ， 导致官方网站和应用程序大面积瘫痪 ， 无法正常使用；2017 年 1 月 ， 开源代码托管平台 GitLab 系统管理员对数据库进行日常维护时 ， 无意中运行了数据库目录删除命令 ， 导致 300GB 的原始数据只保留了 4.5G ， GitLab 被迫下线 。
2020 年 2 月 23 日 18 时 56 分 ， 微盟研发中心运维部核心运维人员通过 VPN 登入服务器 ， 并对线上生产环境进行了恶意破坏 。 这次事件导致了 大约 300 万商家生意停摆 ， 损失巨大 。 因此 ， 微盟也公布了商家赔付计划 ， 整体准备了 1.5 亿元人民币赔付拨备金 ， 其中微盟公司承担 1 亿元 ， 管理层承担 5000 万元 。
针对如何预防删库 ， 如何恢复数据 ， AI 前线整理了部分技术专家针对此提出的建议：
1、流程
1. 完善故障演练流程 ， 作为一项共同目标来协作完成 ， 做到忙而不乱
很多公司都会对故障演练存在一些疑虑 ， 因为这会带来一些潜在的隐患 ， 越是不能动 ， 不敢动 ， 在出问题的时候 ， 修复效率越低下 ， 每个人和团队更加关注自己这一部分的工作 ， 显然会忽略一些相关环节 ， 所以能够组织故障演练的流程和规范 ， 把这些梳理和固化下来 ， 在处理问题时才能够做到忙而不乱 。
【数据库|作为创始人，我不小心删除了生产数据库，还跑路吗？】