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