2023年11月17日，星期五，晚上11点47分。那是我职业生涯中最恐怖的一刻。
我正在家里刷手机，突然看到公司技术群里弹出一条消息：
“数据库被删了。”
发消息的是我们公司的运维工程师小张。我当时以为他在开玩笑——这种事，在正经公司里怎么可能发生？
直到我看到第二条消息：
“我不知道是谁干的，但我刚才发现的时候，线上数据库已经被drop了。没有备份。”
那一刻，我的心跳漏了一拍，整个人震惊得说不出话来。
事件背景
我们是一家做企业协同软件的公司，名字就不提了。产品叫”协创”，做文档协作和项目管理的 SaaS 服务。到2023年11月，公司运营了差不多4年，用户数大概有8万多，企业客户接近2000家。
技术团队一共23个人。后端8个，前端6个，运维3个，还有产品和测试。
删库事件发生的时候，我们 CTO 正在国外出差。那天晚上11点47分他发了第一条朋友圈：落地旧金山了，网络不太好，先睡一觉。
他做梦也没想到，他睡的这一觉，价值可能超过500万。
事件经过
第一阶段：发现（23:47 – 00:15）
让我把时间线重新梳理一下，这样才能看清每一个失误是怎么累积成灾难的。
23:30 — 某云服务商控制台日志显示，有一个来自浙江杭州的 IP 地址，通过 RDS 管理账号登入了我们的主数据库实例。该 IP 地址属于一家网吧的公共WiFi。
23:35 — 登录后约5分钟，执行了第一条高危命令：drop database production;
紧接着是：drop database test;、drop database backup;
三连击。总共耗时不超过90秒。
23:47 — 运维小张的手机响了。监控告警：线上服务全部报错，数据库连接失败。小张以为服务器又OOM了（这种事之前发生过几次），一边骂骂咧咧一边连上VPN，打开终端准备重启服务。
连上之后，他发现不对劲：show databases; 返回的结果是空的。
他以为自己眼花了，又敲了一遍。还是空的。
他给我发消息的时候，打字的手是抖的。
00:15 — 我接到电话，从床上爬起来打开电脑。远程接入公司内网，登录云控制台。看到的画面让我整个人都凉了：数据库实例列表里，三个数据库状态全部显示「已删除」，且没有留下任何可回滚的操作日志。
云服务商的技术支持电话一直占线。
第二阶段：混乱（00:15 – 03:30）
00:20 — CTO 被我们的电话叫醒。他在旧金山凌晨4点20分接到电话，据说当时还以为自己在做梦。
他的第一反应是：“你们确认一下，是不是连接字符串配错了？”
小张发了截图。不是连接字符串的问题。数据库是真的没了。
CTO 第二反应：“找云服务商，做数据回滚！”
00:35 — 我终于打通了云服务商客服。客服听完我的描述，沉默了大概10秒钟，然后说：「先生，我们这边查询到您的实例确实执行了删除操作。数据已经无法从我们平台恢复。」
我问：「你们不是每天都有自动备份吗？」
客服说：「是的，我们每天凌晨2点有自动备份。但您刚才说，删除操作发生在23点35分，距离下一次备份还有2小时25分钟。今天凌晨2点的备份里，有你们前天的数据。」
我算了算：2天。所有数据回到2天前的状态。
这意味着：2023年11月15日凌晨之后的所有数据，全部丢失。
01:00 — CTO 在电话里做了几个决定：
- 立即停止所有服务，避免用户继续写入产生更多不一致数据
- 联系云服务商，看有没有技术手段可以恢复（答复：没有）
- 通知所有企业客户，说明情况
第3条是我强烈建议的。CTO 一开始不太愿意——怕影响客户关系。但我说了两句话让他改变了主意：
「我们现在主动说，客户会觉得我们坦诚。如果我们不说，等客户自己发现数据没了，那就不叫坦诚了，叫欺骗。」
01:30 — 我开始起草客户通知邮件。正写着，技术群里又炸了：
「各位，有个好消息和一个坏消息。好消息是，我们查到了是谁删的数据库。坏消息是，是咱们的开发干的。」
是小张发的。
第三阶段：真相（03:30 – 07:00）
02:45 — 小张和后端负责人老王开始查日志。查了两个多小时，终于把整个事件的链条拼出来了。
删库的人，是我们公司后端组的一个开发，叫李明（化名）。2021年入职，工号排第17，技术能力中等偏上，平时话不多，但代码写得还行。
事情的起因，要从三个月前说起。
2023年8月，李明向公司提交了离职申请。原因：个人发展。他当时负责的是订单模块的维护，离职前有大量的交接工作要做。
但交接并不顺利。
李明后来跟我说，当时他提了离职之后，leader 的态度突然就变了——从之前的「你是骨干」，变成了「反正你要走了，能干多少干多少」。
「我当时手上还有三个模块的交接文档没写完，leader 就一直催我，说你反正要走了赶紧交接。我说我还没写完，他说那你自己看着办。」
他离职前的最后一周，没有人跟他做正式的交接。只是把代码仓库的权限移除了，钉钉群退掉了，电脑交回去了。
但他心里有口气，一直没咽下去。
2023年11月17日，23:30 — 李明在家里的电脑上，用自己之前保存的 VPN 账号连上了公司内网。VPN 账号是他在职的时候申请的，离职之后没有人收回。
他后来在笔录里后悔地说：
「我就是想让他们知道，随意对待一个人是有代价的。」
他登录了 RDS 管理控制台（密码是他在职时设置的，离职后没人让他改），然后执行了三条命令。
执行完之后，他关机，睡觉了。
第四阶段：善后（第一天到第七天）
第一天（11月18日）
早上8点，我们向所有企业客户发了邮件。标题是：「关于11月17日服务中断的通知」。
邮件里说了三件事：
- 服务因技术故障暂停，预计恢复时间48小时
- 数据可能存在2天的丢失
- 我们会尽快恢复服务，并提供补偿方案
邮件发出去10分钟，客服电话被打爆了。
有一家客户是做工程预算的，他们11月15日到17日之间录入了大约300多份工程预算文档，这些文档是他们准备第二天去投标用的。老板当时就急了：「这些东西你们赔得起吗？」
我说赔不起。但我们会尽全力恢复数据。
第二天（11月19日）
云服务商做了一次数据回滚，恢复了11月15日凌晨2点的备份。数据是回来了，但11月15日到17日这三天的新增数据全部丢失。
客服那边统计了一下：23家企业客户丢失了核心数据，涉及订单数据、项目文档、协作记录，总计约4.7万条记录。
有几家企业客户直接发来了律师函。一家客户要求赔偿12万，一家要求赔偿8万，还有一家说「你们赔我丢失的商机，我不跟你算具体数字，你们自己看着办」。
第三天（11月20日）
CTO 从美国飞回来。落地之后第一件事，是开全员大会。
他在会上说了两句话我记得很清楚：
「这件事，技术层面是李明的问题。但管理层面，是我们所有人的问题。让人心痛的是，这场灾难本来完全可以避免。」
第二句：
「VPN 账号、数据库账号、权限管理……这些东西我们早就知道有漏洞，但我们一直觉得’应该不会出事’。今天这个’应该不会出事’，让我们付出了几百万的代价。」
第五天（11月22日）
李明被刑事拘留了。罪名是「破坏计算机信息系统罪」。根据刑法第286条，后果严重的，处五年以下有期徒刑；后果特别严重的，处五年以上有期徒刑。
他的律师联系我们谈和解。CTO 当时的原话是：「我们不要他的赔偿，我们只希望他受到应有的法律制裁。」
但现实是残酷的——李明工作两年，月薪1.8万，存款大概不到20万。就算他赔，他赔得起几百万吗？无力感笼罩了整个会议室。
损失清单
下面是这次事件的经济损失清单，我尽量客观地列出来：
这是我能算出来的直接损失。真正的损失，是那些流失的客户、受损的品牌，以及整个团队在接下来三个月里的惶惶不安。
真正的问题出在哪里
事后复盘，我们总结了三个层次的致命失误：
第一个层次：技术失误
问题一：数据库账号密码没有定期更换
李明在职时设置的 RDS 管理密码，他离职之后没人改。这是最基本的安全规范，但我们没有执行。
问题二：VPN 账号没有及时回收
员工离职，VPN 账号应该立即禁用。但李明的账号在他离职后一周才被移除。而且移除的原因还不是主动审查，而是技术部门某次清理「僵尸账号」时顺手关掉的——关错了人又临时打开了，结果这条线反而被遗忘了。
问题三：数据库没有异地灾备
主库在一个可用区，备份也在同一个可用区。没有跨地域的灾备方案。这次删库，连备份一起没了——因为用的是 RDS 的自动备份功能，而自动备份和主库在同一存储上。
问题四：没有操作审计日志
RDS 管理控制台有操作日志功能，但我们没有开启。等发现删库的时候，只知道是哪个 IP 执行的，具体是谁用的这个 IP，一度查不清楚。
第二个层次：管理失误
问题一：权限管理混乱
一个普通后端开发，不应该有 RDS 管理权限。但当时的权限配置是：后端 leader 有 admin 权限，他可以给团队成员开任意权限。结果权限越开越多，到最后有5个人可以直接操作生产数据库。
问题二：离职流程不完善
李明的离职，交接工作做得很差。但更差的是，离职之后没有任何人对接他的账号和权限做审计。这不是一个人的问题，是整个 HR 和技术部门的协同失误。
第三个层次：文化失误
CTO 在复盘会上说的那句话我印象很深：
「我们对李明的处理方式，让他觉得自己不被尊重。一个不被尊重的人，是最危险的人。」
我不是在为李明辩护。他做的事情是违法的，必须承担责任。但企业也必须反思：有没有给员工足够的尊重？有没有在员工离职时做好情绪安抚？
很多公司觉得「员工离职就是背叛」，这种文化下，员工也会觉得「公司对不起我」。一旦这种情绪走极端，就会变成定时炸弹。
事件之后，我们做了什么改变
安全层面
第一，所有数据库账号密码立即更换，所有管理员账号开启 MFA（双因素认证）。
第二，数据库权限最小化。后端开发不再有生产数据库的直接访问权限。所有的数据库操作必须通过工单系统，走审批流程。
第三，异地灾备上线。主库在北京，备份在西安。两地同步延迟小于5分钟。
第四，操作审计日志全开。所有高危操作（delete、drop、truncate）实时告警到运维手机。
第五，堡垒机上云。所有线上操作必须经过堡垒机，堡垒机记录所有操作日志。
管理层面
离职流程重构。现在离职员工的账号回收是这么做的：
- HR 发起离职流程当天，同步通知技术部门
- 技术部门在24小时内完成所有账号的禁用
- 离职当天的最后一步是技术部门确认「账号已全部回收」
权限审计常态化。每季度做一次权限审计，检查有没有过期的权限、越权的账号。
工具层面
部署了巴别鸟企业云盘的日志审计模块。这是我们事件发生后做出的选择之一。
巴别鸟的日志审计功能有几个点特别打动我们：
- 所有文件操作（上传、下载、删除、移动、权限变更）都有完整的操作日志
- 日志不可篡改，有哈希链验证
- 高危操作（如批量删除）实时告警
- 可以对接 SIEM 系统，和现有的安全运营中心打通
- 操作回放功能，可以还原任何一次数据变更的时间线和操作者
用了三个月之后，我最大的感受是：这不只是防删库的工具，这是让整个技术团队的协作变得规范化的契机。
当所有操作都有记录可查的时候，所有人都会更守规矩。不是因为怕被抓住，而是因为你知道「我在做什么，系统都看得见」。
一个感悟
写这篇文章，不是为了吓大家「删库跑路有多可怕」。
我想说的是另一件事：
很多公司觉得安全建设是成本，不是投资。省掉安全建设的钱，看起来是省了。但这笔钱，会在某个你意想不到的时刻，以你意想不到的方式，让你加倍还回去。
我们这次事件，损失了差不多500万。但500万买来的教训是：
- 权限管理不能懒
- 账号回收不能忘
- 备份不能只做一份
- 日志不能不开
- 对员工的尊重不能少
这五条，每一条都不难做到。但难的是，在「业务跑得很快」的时候，还有人愿意停下来，把这些「基础工作」做好。
但正是这些基础工作，决定了一家公司的系统能活多久。
本文由巴别鸟市场部原创。巴别鸟是企业级云盘，支持完整的文件操作日志审计、权限管理、异地灾备和数据恢复。如需了解更多，欢迎访问 http://babel.cc。