摘要:在IT行业,程序员们经常相互开玩笑说,大不了我们“删库跑路”,显然这只是一句IT界的玩笑话,基本上也没有人会这样干。然而,近期微盟就遭遇内部员工“删库跑路”事件,服务出现故障,大面积服务集群无响应,系统很难再短时间内恢复。那么,为什么系统被程序员“删库跑路”,就很难恢复,背后的真实原因?
![812c51a52196c77c039ed8569292f470.png](https://i-blog.csdnimg.cn/blog_migrate/d5f679f9cc0afe89bd49244e123b77e1.jpeg)
在IT行业圈中,“删库跑路”往往是IT圈内人相互调侃的一个段子,而这也正是因为删库这一错误实在太低级,在高学历、高技术能力的IT行业人员中才能成为一个梗。毕竟这一行为直接违反了我国《刑法》的第286条,也就是破坏计算机信息系统罪。所以大家都只当玩笑话,没人敢在系统中键入“rm -rf / ”这一命令。
![fd3ee01f016032f7ebdf1f6957a6ae7f.png](https://i-blog.csdnimg.cn/blog_migrate/6b9004e8b19bd567f04ada64c4b30954.jpeg)
然而,在2月25日,微盟官方发布《自愿公告SaaS业务生产环境和数据遭到破坏》,称2月23日晚7点,收到系统监控报警,服务出现故障,大面积服务器群无相应。微盟表示,本次SaaS业务数据系遭一员工“人为破坏”,而在SaaS 生产环境和数据遭到破坏后,微盟当前已暂时无法向客户提供 SaaS 产品服务。 其实,在IT历史上此类事件其实不在少数,2015年5月28日中午11时左右,携程官网和APP同时崩溃,一时之间,携程数据库被物理删除的说法在网上盛传,直到深夜23:29,携程才逐渐恢复。第二天,携程发布官方解释,称是由于运维员工的错误操作,删除了生产服务器上的执行代码导致,最终的详细报告官方并没有公布。
![b3e02bfef7de124d2dddb30b013fc1b7.png](https://i-blog.csdnimg.cn/blog_migrate/91d057d68135982f54ccdd3bee69b3a7.jpeg)
另一个著名的事件是2017年2月,GitLab数据库也出现了误删,当时由于遭受DDoS攻击造成staging数据库(db2.staging)落后生产数据库(db1.cluster)4GB的数据,并且staging数据库由于PostgreSQL的问题处于hang状态,在试图修复这个问题的过程中造成了删错库的误操作,最终造成很多项目代码不同程度的丢失。 IT圈子外的人可能很难理解,感觉不就是重装一下系统嘛,数据库不是都应该有备份嘛,直接恢复一下不就行了嘛,其实事情远远要比你想的复杂得多。那么,为什么系统被程序员“删库跑路”,就很难恢复,背后的真实原因? 很多时候,人常常会有一个认知上的偏差,对于一个自己没有切身参与过的领域,我们会不自觉地对难度产生错误的判断。这种所谓的迷之自信,是很难克服的。
![93c97dec64cee2de02e6aa1418a6938d.png](https://i-blog.csdnimg.cn/blog_migrate/312ae62ab8a3a508ca9872964958c18f.jpeg)
熟悉现代软件架构和运维的同学一定知道,现在软件的架构以及部署是极其复杂的,尤其在微服务大行其道的当下,每个微服务本身就是一个集群,微服务和微服务之间还有各种依赖关系,同时每个微服务都有可能会和数据库打交道,光理清楚这些服务之间的依赖和配置就够大家受的了,几乎涉及整体架构的全局梳理,比重新开发一套系统还麻烦。这才是系统被程序员“删库跑路”后,就很难恢复的真正原因。你觉得呢?