我的删库经历

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

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 下来项目的代码，发现是一篇狼藉，几乎无法维护（不是我个人品味上认为的无法维护，是客观上的无法维护的代码，如果你读完，就可以想象这些代码的质量了）。

于是我的计划是：

先修复好单元测试，让每一次提交都通过单元测试；
逐步和团队重构代码；

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

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

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

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

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

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

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

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