回答:我不小心把公司的数据库给删了，该不该离职?

这是学习笔记的第 2164 篇文章

今天回答了一个提问：我不小心把公司的数据库给删了，该不该离职？

这是一个潜意识里不应该有的操作，本质的问题不是该不该离职的问题，而是如何补救，你可以离职，对你来说潜在的风险就是你的口碑，对公司来说，你的隐身而退带给公司的可能是更加重大的损失。

所以不确定你是在怎样的心态下提问的，我假设几个场景。

1.你是开发人员，因为操作失误删除了数据库。到底是什么样的操作需要删除数据库? 这里涉及权限管理和安全管理，流程规范的一些事情，最关键的，这个数据库有没有备份，这块可以咨询下DBA,尽管你没有做备份，DBA的职责是需要做备份的。

2.你是DBA, 对于DBA来说，你备份了吗，如果备份了，可以考虑全量恢复或者更细粒度的增量恢复。

如果没有备份，那确实尴尬了，我们来说下补救措施。

1）理清楚事情的来龙去脉，告诉相关领导和负责人，开始启动相关的应急措施，从一个技术人员的角度是无法预料到后续的结果的，所以我们可以把问题的过程向上汇报，看看是否有相关的协助，比如商务或者技术层面的攻关。

2）这是一个什么样的业务，业务优先级高不高，如果业务优先级不高，可能诚恳的歉意，在业务部门的配合下快速恢复业务，外加一顿饭来缓和下大家紧绷的神经。如果业务优先级高，那么这个业务应该是完全陷入瘫痪了，可以进行下一步。

3）是否存在测试环境，是否可以快速恢复表结构信息，是否存在相关配置和日志信息，快速评估业务的可恢复性。这个事情需要多方并肩作战。

4）如果有补救措施，业务能够存活，后续的应该是问题复盘了，带给大家的应该是更多的教训，不是讨论应不应该这么做，而是讨论如何通过流程制度规范来杜绝这种操作，如果有了这些规范制度，出现了意料之外的问题，那明显就是规范制度的问题，各打五十大板，需要继续改进。

5）该罚的罚，该补救的补救，进一步完善规范，这个时候你的任性带给大家的应该是信任的缺失了，如何弥补，这应该是你需要考虑的问题。

6）离职？你离不离职已经不重要了，马上离职了恰好说明你的能力，态度和道德问题，而离职这个事情应该是一件相对体面的事情，至少在问题面前，不要做缩头乌龟，解决问题为先，这是一个职场人的基本素养和底线吧。

7）常在河边走，哪有不湿鞋，但凡是有一些经验的，哪一个人没有“案底”，因为个人原因，技术原因导致问题发生的情况数不胜数，这是你成长路上的警钟。

8）没有人能够拍胸脯保证永远不犯错，但是同样的错误不应该犯第二次，不管是不是在同一个公司。

9）网络上删库跑路，这是大家工作中的一种戏称，认真点说，跑路这件事情本身就是贬义词。

10）最后祝这种问题不要发生。也希望只是你的一种好奇而已。

近期热文：

迁移到MySQL的业务架构演进实战

数据库修改密码风险高，如何保证业务持续，这几种密码双活方案可以参考

MySQL业务双活的初步设计方案

如何优化MySQL千万级大表，我写了6000字的解读

一道经典的MySQL面试题，答案出现三次反转

业务双活的数据切换思路设计（下）

业务双活的数据切换思路设计（一）

MySQL中的主键和rowid,看似简单,其实有一些使用陷阱需要注意

小白学MySQL要多久?我整理了10多个问题的答案