为何网站挂的时间一长，大家就认为是「删库跑路」？

前两天网易云音乐挂了比较长的时间，网上最先出现的论调就是遭遇了「删库跑路」，不过后来官方出来解释，才澄清了事实并非如此。

你有没有想过，为什么这些大型网站或者服务挂了稍长时间，大家第一个冒出来的想法就是「删库跑路」呢？

首先「删库跑路」确实来自于真实案例。或是员工因为工作疏忽，误删生产系统的数据，给公司造成无法挽回的损失，无颜面对，只得跑路。也有员工因对公司产生怨恨，于是恶意删除公司数据，然后跑路。因为「删库」往往对公司造成的损失极大，「跑路」的畏罪感又进一步渲染了严重程度。两个动作串在一起，合体成了形容词，用来描述重要服务挂掉也是贴切不过了。

而从技术层面分析，一旦网站挂掉的时间稍长，也确实有不小的概率是和数据库相关的。

典型互联网服务分为两大组件，一个是运行着代码的应用程序，另一个则是保存着数据的数据库。数据统计，故障原因里排第一的是变更。而变更可以分为三类：

• 代码的变更。
• 配置的变更。这个也是用于改变代码的运行逻辑，广义上也可以归到代码的变更。

• 数据库的变更。

如果是因前两种变更造成的故障，恢复起来是相对容易的，就回退到之前好版本的代码就行了。但数据库的变更一旦出错，往往不能轻易回退，因为这时已经有新的数据存进来了。如果是粗暴回退，就会连同新的数据也删了。试想要是你千辛万苦抢到了演唱会的票子，回头主办方通知你，因为数据库故障，撤销之前的购买记录，要重新购票，是不是很崩溃？所以一旦涉及到恢复数据库变更导致的故障，操作起来就复杂。因为既要修复变更引起的问题，又要保证发生变更后的数据都在，时间也就自然拉长了。

如同海伯利安（Hyperion）里的时空穿梭者，既要纠正时间线，但又要避免产生其它的副作用。

所以每当一个服务长时间起不来，大家就天然会怀疑到数据库头上。因为如果是代码的问题，基本上在故障扩散之前，就已经被修复了。也正是因为看到数据库的操作风险和恢复之难，所以我们做了 Bytebase 这个产品，用于管控所有人为的数据库操作。对于数据库变更，覆盖了提交，自动检查，人工审核，发布，回滚，历史记录的整个生命周期。而在变更之外，查询操作也同样需要纳管。有时数据库无法提供服务，就是被几个开销巨大的查询任务耗尽了资源。

「删库跑路」自带的画面感，故事性，再结合其抑扬顿挫的发音，注定了它的传播。或许后人的新华字典里，它早已是一个成语，还附带着一段耐人寻味的典故。

「删库跑路」之外，你还能想到哪些类似的词语吗？欢迎在评论区里留言。