最近某公司DBA（资料库工程师）删库被开，这真的是DBA的责任吗？

作为DBA应该如何保护自己？大数据、AI（人工智慧）时代，互联网公司又该如何保护数据呢？

请教大神们有什么好的办法和建议？

不说话，不做事，永远不会犯这个错。涉及到手工操作的，神仙也可能出纰漏。

这事儿都让DBA背了，实在不妥。而且，应该最大限度的宽恕他才对。我几年前年招过一个应届生，入职没几个月，直接drop了一个库，吓得脸都白了，我默默的帮他恢复了数据，他则后来干劲十足，现在也成了业内大牛了。

相反，公司领导层对这个问题够不够重视，技术管理系统够不够完善，操作规范是不是健全才是要重视的问题。

任何一个操作，总有true or false的可能，这就像写程序，你不catch 异常，还老抱怨应用莫名气的挂了。资料库不像程序设计一样，它不仅仅是门技术，同时也是公司资产，这种有状态的资产，就是应该要建立完善的系统和规范才行，操作是不是合理，有没有经过验证，会不会影响业务，能不能导致性能问题，执行会不会出错，出错能不能回滚，回滚是不是及时，这些如果都能用技术或者自动来保障，那么这个悲剧就不会上演。

这样的事儿，如果没有以上的保障，以后肯定还会再发生，而且肯定不止一次。今天你讨论别人的时候，也许明天你就是被讨论的对象。

利益相关：极数云舟创始人，提供MySQL技术产品，其中Arkit产品是MySQL领域就健全的SQL审核和管控平台，可以避免以上问题发生。

题主好，贡献一则回答，来自上上签电子签约运维组的数据安全专家。

——————————————————

大家好，我从事资料库工作多年，下面是我的看法，希望可以帮到大家：

众所周知，DBA是高风险的职业。数据泄露了，你是被怀疑的对象；资料库宕机了，你是众人瞩目的焦点；数据丢失了，更是要被问责。DBA误操作导致数据丢失的情况确实是难辞其咎，但是在公司上下与DBA人员的共同努力下，风险是可以被控制和规避的。

一般说到保护数据安全的对策，大家很容易想到备份、容灾、恢复演练等保护措施，但是「上工治未病，不治已病」，预防才是王道！据统计，90%以上的生产事故是人为导致的，所以保护数据安全的重中之重，是尽可能减少人为操作。

这里我提几个具体防范手段，如下：

从公司管理层面1、上线操作流程化，这样可以避免随意上线操作，减少错误来源；2、上线操作自动化，减少人为操作的次数，减少人为操作导致错误的概率；3、制定安全操作规范，比如终端离席锁屏、避免GUI（图形化工具）方式操作生产库、许可权最小化等；

4、提供必要资金投入，包括人员（比如双人操作）、备份和容灾方面。

从DBA自身层面：

1、备份。备份重于一切，DBA主从推动备份恢复机制；2、恢复演练。 制定恢复演练验证数据备份的有效性，避免恢复时备份不可用；3、容灾。制定容灾策略，如从库、延迟从库、同城灾备、异地灾备等；4、许可权控制。 不要使用管理员操作，使用root操作是大忌； 5、操作习惯。 避免疲惫时操作，这是笔者多年的经验，因为疲惫时操作最容易出错；6、流程。所有线上操作流程化，操作有审批、有许可和授权，尽可能避免做画蛇添足的事。

如果有条件，最好做一下灾难演练，完善灾难恢复手册，做到手中有粮，心中不慌。除此之外，还有最最重要的一条： DBA要时刻对生产心存敬畏！

做到了如上几条，也就做到尽可能的保护数据了。DBA也不用每天如履薄冰，担心背锅了。

具体也可参考这个回答https://www.zhihu.com/question/56464092/answer/480680219

大家还有什么好建议也随时欢迎讨论。

最后欢迎大家关注上上签电子签约。我们是行业内唯一同时拥有ISO27001、ISO27018、公安部信息安全三级等保、工信部「可信云」四大资质认证的电子签约平台，具备银行级别的安全机制。签合同，上上签一下。

如果你问顺丰这次事故的处理，我觉得没什么问题啊，这和公司请个专职司机，自己失误撞死人的情形差不多，虽然公司会承担部分赔偿等损失，但此司机基本是没机会呆下去了。除非上面有人力保，或者是"以人为本"的公司文化，认为是公司已经损失了几百万给这个人做培训费，再炒掉连培训费都给别人了，（但这类公司基本是那种小公司，反正也请不到人；或者那种垄断、无欲无争，毫无压力之类的公司）

DBA就是本次事故负主要责任，这就是一个低级错误，并且造成"严重"损失，开除很正常。你看那封邮件抄送一堆group，就是这个影响不是自己一个人，或自己这个组能抗下来的，是影响了一大team人的KPI，总得给人家一个交代吧？不开你，除非运维的领导出来硬抗，但估计损失更大，及时止损更明智；另外，这个运维组今年的年终奖金等估计黄了，估计团队其他人也对他很有意见，后续合作也有点困难了。

唯一和之前有异常就是以往这种事情都是悄悄的进行，这次连真实姓名都流出来了，让此人以后比较难在这个行业混了；

－－－－－－－－－－－－－－－－

作为DBA应该如何保护自己？

我的回答是对工作要有敬畏之心。

生产环境执行变更类操作，这个操作风险极大，正常情况提前要写好变更方案，方案里面要写失败回滚方案，而且要在测试环境先进行测试通过后到正式环境实施，且还不论方案的层层审批。

从这个过程看，DBA不仅完全没有按照正规流程进行操作，而且职业敏感的度完全不够，涉及删除操作居然不仔细审查即执行，SQL操作弹出提示居然还能无视。这样如果不翻船天理难容。

这个事情dba是撇不开责任的，只是轻重而已，从保护自己同时保护公司数据资产的角度考虑，我觉得打铁还需自身硬，首先要对生产数据有敬畏，要克服好奇心和毛躁的一上来就操作的习惯，不要用生产数据作试验；其次，生产的变更在遵守规范的前提下，事前一定要做好测试，必须是真实的模拟，比如数据量、数据特点，还有使用的工具等，做到心中有数，要有回退的预案，不要把自己置于无路可退的境地；最后，要更多的磨炼技能，汲取前辈们得经验，为己所用，总有一些操作还是需要手工执行的，不可能全部自动化的。其他具体的细节技巧网上也可以很容易搜索到的。

顺丰这个事情DBA肯定有责任的，操作不够谨慎，职业敏感度不够，没保护好自己。

但是顺丰的管理、流程和技术控制上也都有责任，不能全推给DBA一个人来背锅。DBA这个工种太高危了，谁没有不小心出错的情况，别的岗位出个错没事，DBA一出错就开被出，也没见给DBA开的工资有多少绝对高度，看来DBA自己得给自己买一个很高的失业保险。

DBA自己应该尽可能的把一些可能会发生的情况预想一遍，做好防止的措施，避免有时候犯浑掉坑里。

顺丰这个恢复时间也有些长啊，估计是预案没错好，也没有做没有延迟从库，因为他这个动作备库也是会被删掉的，可能容灾库也会被删，只有延迟从库中还能快速全量的找回数据，这么长时间我怀疑顺丰没有延迟从库，恢复是从离线数据恢复的。

建议DBA把删这个能力忘了吧，绝对不删库，不就是浪费些存储资源嘛。真要删多叫一些人后面盯著，犯浑了好拉你一把。

大家也可以参考这个回答：

企业如何避免云服务/云平台故障给自身业务带来损失？?

www.zhihu.com图标

养成良好的习惯，先备份后修改，先select然后再update delete，不要盲目自信，虽然麻烦一点，但是保险啊！

大不了，恢复资料库，这是保底，在保底的基础上，再锦上添花，别把锦弄没了！

自己也有犯糊涂的时候，把公司4年的一个表一不小心没写条件给delete,首先冷静，我有昨天的资料库，在昨天的资料库基础中恢复这个表，然后增量部分，通过其他关联表，写游标补齐数据！即便退一步，没有补齐增量补分数据，起码损失是可控的！

1.打铁还需自身硬 DBA做任何资料库操作都要清楚该操作带来的后果，对线上操作抱有敬畏之心，操作时谨慎谨慎再谨慎，重大操作提前做好回滚方案，给自己留好退路，这也是对一个专业DBA综合素质的体现。

2.企业加强运维流程管理 操作要有审批流程，确保负责人员知晓，重大操作可双人操作或安排检查人员

3.积极推动运维自动化 减少操作复杂性，对高危操作进行提示或做许可权限制，减少操作人员出错几率

4.如果企业将资料库全部风险完全转嫁给DBA，那么应体现高风险高收益原则，这点应在工资中体现。

绝对不进行任何删库的操作

推荐阅读：
查看原文 >>
相关文章