职场里,对数据库要有敬畏之心!

·  阅读 423

前言:

时常有听到各公司数据库故障的案例,比如数据库宕机了、误删数据了、恶意删库了等等。可能还有更多的故障没有披露出来。每次发生此类事件,都会在互联网圈引起热议,其实更应该留下的是警醒,我们应该足够重视数据库安全问题,对数据库要有敬畏之心。

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 机制,请同事帮忙检验。
  • 不要在疲劳状态下操作数据库。
  • 要有责任心,记得自己操作了啥,出问题不要逃避。

总结:

写本篇文章的目的是为了告诫大家,对数据库要有敬畏之心,不要认为理所当然,可能一个很小的操作会导致很严重的后果。当然,人非圣贤孰能无过,也许只有经历过一些事故才能更好的成长,我们要做的就是尽可能减少事故发生。

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改