回答:我不小心把公司的数据库给删了，该不该离职？
这是学习笔记的第 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多个问题的答案
转载热文：
《吊打面试官》系列-Redis基础
唯一ID生成算法剖析，看看这篇就够了
关于大数据运维能力的一些思考
DBA菜鸟的进化简史：不忘初心，记工作中踩过的三个坑
美女主持直播,被突发意外打断!湾区网友却高喊: 我懂!超甜
QQ群号：763628645
QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过
