我的删库经历

看了一篇文章讲自己删库经历,感同身受的一点是:

But, as far as I know, no one ever asked why a junior developer had access to a production database. I probably did need read access, but why write access? And if I did need write access, did I really need permission for a destructive command like TRUNCATE?

Blameless 的事故 review 如此重要,以至于如果没有它,我们会更加注重在人犯的错误上,而不会关注到系统上的漏洞:为什么初级工程师会有 write 权限?为什么 TRUNCATE 没有禁止?为什么无法从一张表恢复备份?

我唯一的一次删库经历是删除了一个线下的测试库。事情是这样的。

我刚入职上一家公司不久,pull 下来项目的代码,发现是一篇狼藉,几乎无法维护(不是我个人品味上认为的无法维护,是客观上的无法维护的代码,如果你读完,就可以想象这些代码的质量了)。

于是我的计划是:

  1. 先修复好单元测试,让每一次提交都通过单元测试;
  2. 逐步和团队重构代码;

那是一个基于 Django 的项目,之前的单元测试因为配置问题,都无法启动。在修复完这些问题的时候,我运行了测试命令:python manage.py test.

几分钟之后,发现测试库被删除了。这才发现,之前的代码中数据库的配置也有一个问题,测试环境连接的数据库,和单元测试定义(本来不需要定义,django 自己会生成)的名字是同一个数据库的名字。Django 运行测试的时候,如果不指定 --keepdb,Django 运行完测试之后会删除掉测试用的库。

虽然是一个线下的测试库,但是导致了很多的问题:

  1. 大家把很多配置数据直接通过 shell 写到了数据库里面,代码中没有备份;
  2. DBA 不负责维护线下库,无法恢复备份;

所以最后只能通过凭借记忆恢复数据。

这个也暴露出来很多问题:

  1. 为了图快,这个项目的开发有很多没有遵守规范的地方,比如直接将重要的数据保存在了一个没有 SLA 保证的数据库里面;(后来我发现很多这个公司内内部项目都是这么做的,以线下环境为主,因为线上环境每次发布和修改审批流程太复杂了,只改动一行代码发布到线上需要至少 40分钟。在很多人眼里,内部项目的质量是不重要的,只需要晋升答辩的时候能够有一些系统的截图就可以。)
  2. 数据修改应该使用 Django 的 Data migration,这样非业务写入的数据都会在代码库中持久化,还有历史记录;
  3. 项目有危险的配置错误;
  4. 单元测试从来没有运行成功过;

这个项目最后的命运也以无法维护而告终,我们最后重新写了一个项目来取代它。



我的删库经历”已经有7条评论

  1. 删库没干过。删代码倒是有过。

    我当年刚入职前前司的时候,IT 对办公电脑几乎没有管控,我就重装了个 Ubuntu。有次写脚本的时候 rm 后面路径的一个参数名打错了。然后直接把一个大项目的目录给删掉了。当时最新的代码还没提交到 SVN

    幸亏手快,立马把分区 unmount 了。后来用 ext3grep 把数据全恢复了。

    从那以后,我写 shell script,一定会加上 set -u

  2. 有过同样的经历,别人在一个start脚本里面添加了一些数据库清档的命令,自己接手后跑了下就将测试数据全部删除了,导致接手更加困难了

Leave a comment

您的电子邮箱地址不会被公开。 必填项已用 * 标注