删库跑路的技巧总结

作为一个单身的程序员，在写代码的时候看见一个深V的——汇率波动图（程序员怎么可能对妹子感兴趣），表示手有点抖。手抖就容易达成程序员的最高成就：删库跑路。

犯案过程

首先，我的整个应用由于预算原因只有两个环境：local和production。至于数据库，只有一个环境，那就是production环境。当然，事情不会简单到只是因为只有一个数据库环境所以平时写代码的时候顺手删了个库。因为，“数据库”指的是正经的数据库，local和pipeline上跑build都是直接用我自己写的内存数据库（是的重点是我自己写了个内存数据库，自带事务和锁处理哦，全文重点就这一句话了），而真正连数据库其实是把内存数据库的数据同步提交到“真实”的数据库里而已。也就是说，所有环境其实都在用我自己的内存数据库，只是线上环境打开了自动同步功能。
然后呢，今天晚上我的任务是修复一个线上bug（最近由于有大的结构调整所以质量是一天不如一天啊）。这个bug大概是某一个应用与某些服务间通信存在问题，并且已经证明所有服务没有问题，确认是应用的bug。同时，我不能简单的在local把服务都起一整套，然后就在local重现这个问题。所以我需要把local的应用连接到各种服务中。
接着就发现，由于底层框架是自己做的（划重点，这句话是重点），自己的底层库的版本间依赖还是比较紧密，加上最近调整所有应用和服务的结构，版本间基本不兼容。于是就冲突了，而且是打包的时候冲突了，也就是local直接起应用是发现不了问题的，必须打包，然后运行这个包才能发现问题。
现在呢，因为要和线上的服务连接，所以所有配置都要用线上配置。其中就包括了数据库配置，因此现在的local是会同步到真实数据库的。然后，天真的我就开始跑build了。可怕的是，跑build是要跑测试的，跑测试是要准备干净环境的，准备干净环境是要清空数据库的！

犯案原因

直接原因就是配置出错导致的。

事后补救

不好意思，有定期备份，回档16小时……

总结经验

以后说删库跑路什么的不要再low到说什么sudo rm / -rf之流了，都不靠谱，还没上飞机就被抓回去了好不？正确的做法，悄悄修改配置，然后起一个定时任务，定时提交代码，或者定时merge。这样，一切都很正常，而你已经在某一个地方过着悠闲的日子。接着，某一天，突然大家发现数据库的数据没了，在经过连续72小时的加班之后，终于发现是你删了库。但可惜，已经没人能把你抓回去了。

所以，今天：
智商-1
删库技巧+1