昨天下午看一篇程序员的搞笑文章，看到了删库跑路的段子，然后想起了自己曾经的经历，于是就想写写了。
图片来自 Pexels
记得是发生在 2013 年，具体日期记不清了。那时候，我们的存储系统已经成功在全部门铺开了，当时我们正准备着手进行第二轮的优化。
相比前面阶段，我们的压力已经小了很多，因为已经完成了最关键的 KPI, 我们可以有规划，有时间地慢慢做优化了。
那天晚上，我本着想 22 点就走的，想回去看部电影，毕竟太久没看了。不过正要走的时候，被 Leader 拉住，他跟我讨论起了存储冷备的问题。
热备我们已经解决的不错了，业务的可用性因此得到很大的提升，冷备是为了解决业务上的问题，比如有人不小心写了个 Bug 把数据给删了，便可以从冷备的数据中恢复回来。
我们讨论得很投入，方案也慢慢清晰了，不知不觉已经 23 点了，觉得太晚了，就约定明天再聊。
我关了显示器，正准备离开的时候，隔壁团队的 D 带着新人 J 跑了过来，很慌张地样子。
他拉住了我，对我说：“你们存储系统的数据可以恢复吗?”
我有点懵：“什么意思?容灾(热备)出问题了吗?”
D 答到：“不是，我们一个实习生的代码有 Bug , 把业务 G 的核心数据全删了!”
“啊!” 我吃惊道。
刚好我 Leader 也在，他走过来，“刚刚我们还在讨论冷备的事情，就是为了应对这种情况的，不过还没开始搞呢!” 他说道。
“那怎么办? 有没有其他办法可以恢复数据，要不整个业务就完蛋了，那是最核心的数据!” D 惊慌地说道。
“让我们想想 !” 我转过身就跟我的 Leader 讨论了起来。
讨论了不到十分钟，就想到一个办法。
因为我们的存储采用的是 BitCask 的模型，删除操作只是在对应的数据里面做了一个标记，没有真正删除，真实的删除会在业务低峰期，数据回收的时候才进行。
也就是说，只要执行数据回收之前，我们就有可能把数据捞出来做恢复。
但方案执行起来有很多需要注意的细节，而且有比较大风险，于是就具体的细节，我们又讨论了二十来分钟。
那时候时间已经是 00：30 了。
一切敲定后，我登录上了他们业务的机器，看配置，数据回收的时间是凌晨 3 点，我赶紧将配置改到了中午 12 点，为接下来的恢复争取时间。
我跟 D 解释了一番，并告知他，可以从未被回收的旧文件里面恢复数据，不过因为第一次遇到这种情况，我需要写个新的工具把旧文件的数据捞出来，然后 D 那边也需要配合写一个工具，将读出来的数据，从业务接口面写回去。
D 听到，仿佛得到拯救一般，连忙道谢!之后就一些细节，我们又进行了一番讨论。
一切敲定，大家便各自忙了起来。我也立马带上我的耳机，吭哧吭哧写起了代码。所幸工具的逻辑不是特别复杂，不到一小时就写完了。
我自己验证了几遍，可以正确的将数据从旧文件中读出来。这时候，已经是凌晨 2 点了。
我跑去了他们的座位，他们那边的工具也准备好了。
于是我们拿了一台机器，准备合起来跑一遍工具，做一次全流程的验证。D 执行了这个操作，看着黑底白字的屏幕上打出的一行行 log , 我们都屏住了呼吸，生怕看到 “Error” 的字样!
所幸，整个过程没有任何报错，我们又找了一个旧工具做了一次数据读取的验证，以确保恢复的数据是正确的。
当看到最终结果的那一刻，我们终于松了一口气，整个方案是可行的，可以正确的恢复数据。这时候，时间已经到了凌晨 3 点多。
此时放松的心，又紧绷了起来。
因为有数据的业务机器有上百台，我们必须在凌晨 5 点前完成全部数据的恢复，要不就会影响到用户的正常访问了。
我们又立马投入方案的讨论中。很快敲定了，单机多进程，多机并发跑的方案。
方案的执行，需要写些并发的 Shell 脚本。我们 3 人又赶忙跑到了运维大神 A 座位，他已经了解事情的前因后果，我们就执行方案跟他做了进一番的讨论，敲定后，他立马就写起了 Shell 。
十多分种后，两个 Shell 脚本都搞定了，A 做了一次验证，一切符合预期。
在准备开跑前，我们又讨论了异常的应对情况，需要监控的关键数据和曲线。这时候时间已经接近 4 点了。
“时间不多了，跑吧!”， 我们异口同声道。
D 和他的实习生也跑回了座位去看业务监控，我在运维大神 A 旁边看着他的操作和监控。
很快，一百多台机器上的自动化脚本和工具全部跑了起来，我们来回切换，看机器的负载和业务的曲线，一切都在预期之中，5 点前，数据终于全部被恢复了。
我们又赶忙找了几个测试号，从用户侧做了一次完整的验证，确保整个业务流程不受影响。
一切符合预期!我们的心才终于安定了下来。看了看时间，已经是凌晨 5 点多了。
搞了一整夜，大家已经是极度疲惫，我们下楼叫了出租车各自回去。
在出租车上，我看着冷清的街道，绿化树一棵棵飞快地往后跑去，马路两边的霓虹灯已经渐渐微弱，天边慢慢露出了乳白色的微光。
我感到疲惫，但也感到一种兴奋。似乎经历了一个人生的重大危机，所幸是有惊无险!
现在回想起来，那确实是惊心动魄的一夜，不过，所幸大家都响应的很及时，配合的很好，才避免了一次可能上微博的删库跑路事件。
我们后来看玩笑，幸好那晚的运气和配合都很好，D 和他的实习生终于不用跑了 。
这是一个业务高速发展路上的一个小插曲。因为当时的业务发展很快，无论是人员的培训还是技术方案的完备性上，都有缺失，但因为大家的努力和尽责，最终还是挺了过来。
在后面的日子里，我们做了多方面的改进，类似的事情，便从未再发生!
