暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 不小心误删了数据库，是跑路还是？| IDCF

不小心误删了数据库，是跑路还是？| IDCF

DevOps 2021-09-15
2512

警告：本文含有大量rm-rf/、删库等字眼，阅读完本文后，请自行保持警惕，由于大脑惯性或好奇心产生的危险操作，与本平台无关（这是一份一本正经的警告，请认真对待）

再次警告（怕你觉得不够正经，再强调一下）！《刑法》第二百八十六条：违反国家规定，对计算机信息系统功能进行删除、修改、增加、干扰，造成计算机信息系统不能正常运行，后果严重的，处五年以下有期徒刑或者拘役；后果特别严重的，处五年以上有期徒刑。

有资深人士对此条法规援引了相关司法解释：“删库跑路”如果造成10台以上系统不能正常运行就可以判刑，如果影响50台以上则至少判5年。


---警告结束，以下为正文--- 


那些年删过的库



事情是酱婶儿的~ 前两天，脉脉上爆出一条消息，字节跳动的一位实习生，把公司所有lite的模型都删了。lite模型就是公司内几乎所有GB大小以下的机器学习模型，还加了 skip trash （删除文件时临时禁用回收）操作，导致被删除模型无法被恢复。 

字节内部全公司通报，列入P0事故等级，有字节员工在脉脉说，一晚上连着3个事故，加班到凌晨三点。（心疼一下字节的同学，更心疼那个搞事的实习生）

那么为什么一个实习生就能有删库的权限呢？在知乎上有个网友给出了一份看起来是知晓内幕的回答：“该实习生清理HDFS上的目录，发现一个目录最近更新时间是3月份，就以为这个目录不用了，多方求证之后得到了这个目录已经没用的结果，管理员给子目录加了保护，但实习生直接删除的是hdfs，还加了skip trash，然后删掉了……” 

事情就是这么个事情，删了库那就看能不能恢复，但我比较好奇的是，一个误操作删了库，这个实习生后面该咋混？要不要跑路？

从网上看了看，大家的关注点也放在了这个实习生的未来出路上，并且分成了几种观点流派，几乎都在祝福，看完大家的观点，突然觉得这个实习生给字节立功了，也许能在上市的时候一起去敲钟。

  • 观点一：给字节的权限管理敲响了警钟，有利于团队规范化。
  • 观点二：非主观故意的，就不会被开除。
  • 观点三：权限逻辑需要有高层监督，这个锅应该由高层或部门经理来背。
“删库跑路”是流传在程序员界的一句“豪言壮语”，本以为没人会这么做，但在写这篇文章之前，特意去搜了搜，没想到这样的事件还真是不少，有为了报复公司故意删除的，也有的是像字节这位实习生搞不清状况误删，还有的就纯粹是因为手滑给删除了。
知乎上有一个“不小心删除公司数据，会怎么样”的问题，被浏览六百多万次，有554个回答，大多数是在分享自己删除数据库的经历，当然，基本上都是误删。
不查不知道，一查吓一跳，误删数据库的事件时常发生，其中也不乏一些事故产生了比较大的影响：
  • 2017年6月，一家荷兰海牙的云主机商 verelox.com，一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容。最终导致 Verelox 暂时将网络下线，并且丢失的数据大概率恢复不了了。 
  • 2018年9月，思科一名离职员工在未经授权下，有意连接到思科在 AWS 上的系统，删除了 456 台虚拟机。据了解，这些虚拟机主要用于交付视频会议、视频消息收发、文件共享等服务。根据检察官的说明，Ramesh 的行为导致超过 16000 个 WebEx Teams 账户被异常关闭，持续时间达两个星期。思科方面共计损失 240 万美元（约合 1650 万人民币），其中包括对问题进行修复所支付的约 140 万美元人力成本和超过 100 万美元的客户退款损失。
  • 2015年5月28日上午11时，携程网突然陷入瘫痪。携程回应称携程部分服务器遭不明攻击，在此次故障中全部遭受物理删除，且备份数据也无法使用。但在5月29日，携程发布官方情况说明称，此次事件是由于员工错误操作，删除了生产服务器上的执行代码导致。
  • 2020年2月，FCoin宣布销毁团队用友的7亿枚FT，在系统维护公告中提到：由于团队关键人员失联，以及部分系统和数据严重受损，导致无法按计划及时恢复。 
  • 2017年9月，某IT大厂技术工程师帮助广西某运营商进行扩容割接（即增加系统容量）时，不小心将HSS设备里面的用户数据格式化删除，导致该运营商近80万用户数据丢失。
那么，误删了数据库，都会被怎么处理呢？这个就看各公司的制度、处理规则、事件影响，最主要的，是得看程序员是故意的还是无意的。
  • 亚马逊曾经在2012年出过误删数据库的事，亚马逊事后发表了言辞恳切的声明，而且当初干这事的哥们仍然在亚马逊工作（不知道出去了是不是不好找工作）。 
  • 之前顺丰也发生过一次这样的事件，运维背锅，发生后被辞退了。顺丰一名运维工程师在误删数据库以后被开除了。根据微博内容显示，顺丰运维工程师在收到变更需求后，按照操作流程要求，登陆生产数据库跳转机，通过 navicat-mysql 客户端管理工具，连入 SHIVA-OMCS 的 RUSS 库进行操作。但在操作过程中，该工程师错选了 RUSS 数据库，打算删除执行的 sql，在选定删除时，因其操作不严谨，光标回跳到 RUSS 库的实例上，在未看清所选内容的情况下，便通过 delete 执行删除。同时，他忽略了弹窗提示，直接回车，导致 RUSS 库被删除。因运维工作人员不严谨的操作，导致 OMCS 运营监控管控系统发生故障，该系统上临时车线上发车功能无法使用并持续了约 590 分钟。同比 9 月 5 日的 929 条临时车需求，此次故障对业务运营产生了严重的负面影响。
也有一些删库事件，是恶意而为，这种情况下，一般都受到了法律的惩罚：
  • 2018 年，韩冰利用其担任链家公司数据库管理员并掌握公司财务系统 root 权限的便利，登录公司财务系统服务器删除了财务数据及相关应用程序，致使公司财务系统无法登录。链家公司为恢复数据及重新构建财务系统花费 18 万元。北京市第一中级人民法院发布《韩冰破坏计算机信息系统二审刑事裁定书》。前链家公司数据库管理员韩冰因恶意删除公司 9TB 数据，犯破坏计算机信息系统罪，判处 7 年有期徒刑。 
  • 2020 年 2 月 23 日 18 时 56 分许，贺某酒后因生活不如意、无力偿还网贷等个人原因，在其暂住地上海市宝山区逸仙路XXX弄XXX号XXX室，通过电脑连接公司 VPN、登录公司服务器后执行删除任务，将微盟服务器内数据全部删除，导致微盟自 2020 年 2 月 23 日 19 时起瘫痪，300 余万用户（其中付费用户 7 万余户）无法正常使用该公司 SaaS 产品，经抢修于 3 月 3 日 9 时恢复运营（故障时间 8 天 14 个小时）。截至 2020 年 4 月 30 日，造成微盟公司支付恢复数据服务费、商户赔付费及员工加班报酬等经济损失共计人民币 2260 余万元。贺某被判处有期徒刑6年，没收作案工具笔记本电脑一台。 
  • 2020年10月，某程序员因劳动纠纷，离职后想要删库讨薪，利用漏洞通过公司网站运行model-test-1.php、model-test-2.php的程序，使用rm指令删除了云服务器中的用户行为日志文件和优化APP模型算法文件，并删除用户上传的图片和模型文件，最终被判处有期徒刑十一个月。
在此，小柒再次提醒您：道路千万条，安全第一条，删库进铁窗，亲人两行泪。

误删数据库是跑路还是？



在研发团队的日常工作中，失误是无法避免的事情，误删数据库是否就一定要等于跑路呢？其实，只要你不是主动故意地想要搞破坏，而真的是工作失误的话，这些“错误”在DevOps的文化中是被允许的，并且在一定程度上，这更有利于组织、文化和系统的进化。
首先，我们应该抱着宽容的态度来看待类似的事情发生，在很多成熟企业的工程文化中，错误代表着组织或系统存在的缺陷，通过犯错发现了这个缺陷，让整个团队得到了成长，这是值得被鼓励的事。
在Facebook有一个非常有名的故事。Ben是一名年轻的夏季实习生，在一次测试中，他触发了漏洞，导致网站停止服务整整30分钟。然而，他并没有被当做“背锅实习生”开除，而是成为了全职员工，类似的事情也被称为 “Ben测试”——对于那些想法很好、执行不好的测试，公司允许员工继续下去。 
Etsy有一个传统，鼓励人们把自己犯的错误写下来，并通过公开的邮件广而告之，“这是我犯的错，你不要再犯哦~”这被称之为 Just Culture，基于一个理念，即免责会让人们更有责任心，并同时愿意承认错误，从而让自己以及他人从自己的错误中吸取教训。
Etsy还有一个好玩的举动，公司每年会颁发一个年度大奖，一件真的三只袖子的毛衣（不知道什么典故，看起来不是说“三只手”），这一毛衣，颁发给造成最大意外失误的员工，而不是造成最坏结果的，这是在提醒员工，事物真正发生的情况，往往与预期的情况大相径庭。这同时也表明了公司的态度，犯错不是什么应该觉得羞耻的事情，Etsy的员工反而会因收到这一毛衣而开心，因为他无意中犯得错误，给了所有Etsy员工一个成长的机会。
DevOps倡导快速实验、试错、迭代的工程理念，在黑客文化中，我们要不断探索，想要让团队具备黑客文化，就要让员工去探索他们认为值得探索的领域，而不是用高压手段来控制员工，约束他们的创意。
其次，在发生“错误”后，我们该以什么样的态度来发现错误、修正错误？并不是找到这个人，去处罚他，而是要挖掘错误背后的真实原因，并改正它。 
Gitlab的一位系统管理员在给线上数据库做负载均衡工作时，遭受了DDoS攻击。在阻止了攻击之后，运维人员发现了数据库不同步的问题，便开始修复，在修复过程中，错误地在生产环境上执行了数据库目录删除命令，导致300GB数据被删除，Gitlab被迫下线。在恢复的过程中，他们发现只有db1.staging的数据库可以用于恢复，而其它的5种备份机制都不可用。db1.staging 是6小时前的数据，而且传输速率有限，导致恢复进程缓慢， Gitlab 最终丢掉了差不多6个小时的数据。有趣的是，这名员工没有被开除，而是被迫看“10小时的彩虹猫”，以示惩罚！
在发生这个事故后，公司试图通过根源分析（5 Why分析法）来挖掘真实问题：
  • 为什么Gitlab.com会宕机？——因为主服务器上数据库目录下的主数据库被人为错误地删除了。本来是要删备份服务器上的数据库的，结果不小心删成了主服务器上的数据库。
  • 为什么数据库目录被删除了？——因为数据库备份过程停掉了，要求重启或重新构建备份服务器。因此就要求PostgreSQL数据库目录必须为空。这一清空操作系统不能自动完成，必须手动，而且在运维文档里也没有明确说明。
  • 为什么备份过程会停止？——是因为数据库的一次异常负载峰值造成了数据库备份进程停止工作。这很可能是因为主服务器的WAL段在备份之前就被删除而造成的。
  • 为什么数据库会出现负载突然上升的情况？——这一现象是由于两个事件同时发生造成的：spam数量的增多，以及后台进程企图删除一个GitLab员工数据以及相关的数据。
  • 为什么GitLab员工数据会被删除？——被删除的员工账号被举报滥用。我们当前用来处理这类举报的系统太忽视报告和细节，因此对该员工信息产生了误删。 
所以，发生这个事故的真实原因是处理举报的系统忽视了报告和细节，产生误删所导致的，应该去优化处理举报的系统。这是正确处理删库事故的值得借鉴的方法。
最后，认真对待每一次系统故障，让故障来驱动系统的进步。 
Netflix刚发生的一次大规模服务中断，坦率地说，这是由一个低级错误引发的，而造成事故的这名工程师过去18个月中曾经让Netflix宕机两次，然而他并不会被开除，相反的，Netflix认为，在过去18个月中，他大幅改进了运维和自动化的程度，进步不是以千米，而是光年衡量，“他的工作成果，使我们每天能安全的进行部署”。
DevOps必须允许这种创新，并接受因此带来的风险，在生产环境中会遇到更多失败，但这也是驱动组织升级、文化践行和系统迭代演进的助推剂。
在2014年DevOps现状报告中有这样一句话，“高效能DevOps组织会更频繁的发生失败和错误，这不但是可以接受的，更是组织所需要的”。 
“一切杀不死你的都使你更强大”，运维团队的使命是为企业提供质量、效率、成本、安全的技术支持，为业务的健康发展保驾护航，一旦出现“事故”，运维往往无法免责，要想不成为“背锅侠”，我们就更应该在日常工作中充分利用DevOps的容错特性，以及DevSecOps、混沌工程等方法和技术构建反脆弱的系统。
更多精彩文章


《玩转创新设计思维/Design Thinking》工作坊将于7月18日在北京开课，了解详情及报名直接扫描下图二维码，现在报名有优惠哦👇

更多课程内容👉35岁熬到研发管理，一周后，我想辞职！| IDCF

数据库
文章转载自DevOps，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论