恐怕"删库跑路"这种操作大家都耳熟能详了，大家还记得年初微盟员工凭一己之力，删除自家公司数据库，累计市值蒸发超 30 亿港元的事情吗......

老板惹怒程序员有多可怕?

近日，某公司因奖金没到位，程序员愤而报复，修改华为云 obs 对象存储服务代码，导致平台大范围崩溃。

而这位“一时冲动”的程序员也收获了 5 个月的刑期。看到这里，网友也忍不住吐槽道：兄弟，不讲武德，付出代价了吧~

事情还要从今年 4 月份说起：

被告人王某(以下简称：王某)所在的公司项目是一个同城生活服务平台，主要是满足晋城消费者线上、线下的吃、喝、玩、乐、购服务。

2020 年 3 月 22 日，该公司某平台被晋城市商务局选为晋城市同城生活服务平台，受晋城市商务局委托向消费者发放电子消费劵。

2019 年 12 月，时任公司技术部的刘经理交给王某一个任务：开发 obs 代码，如果开发成功公司会有奖励。

在开发过程中王某负责写代码，另一位同事则负责做前段代码工作。开发完毕经过测试没有问题，就开始在公司运行。

王某心想，这下奖金稳了。可是，万万没想到，公司却层层设卡不想给奖金。

王某可忍不了：既然我能开发出来，也能毁了他。说干就干。2020 年 4 月 13 日 11 点左右，王某就开始实施“报复”。

通过 winscp 软件使用 root 账户(超级管理员账户)登录至华为云服务器的 FTP，将本地的 PHP 代码替换了华为云服务器 PHP 代码，导致了用户从 Web 服务器直接下载未缓存的图片，高峰期会导致下载缓慢或卡死。

WinSCP 是一个 Windows 环境下使用 SSH 的开源图形化 SFTP 客户端。同时支持 SCP 协议。它的主要功能就是在本地与远程计算机间安全的复制文件。

WinSCP 可以执行所有基本的文件操作，例如下载和上传。同时允许为文件和目录重命名、改变属性、建立符号链接和快捷方式。

果不其然，14 日 8 点至 9 点 30 分左右，当该平台向用户代发 76 万元的电子消费劵的时候，有用户打电话反应称平台打不开，随后晋城市商务局的工作人员也打电话问平台打不开的事情，该公司的副总侯某就和技术部的人员紧急排查平台服务器运行的各项指标，后来又联系彭某协助排查问题。

经过彭某排查，发现华为云 obs 对象存储服务代码被修改过，然后侯某给彭某发了备份代码让彭某帮助替换，到了 9 时 30 分许平台恢复正常运行。

截止发现，造成该平台的 15 万会员无法进入平台领取电子消费劵。

删除一时爽，事后火葬场

今年 9 月，该公司正式将其告上法庭。

根据侯某的证词，这个代码是王某和另一位同事共同开发。王某本来公司应聘的岗位就是搞开发，公司也照常给他发工资和奖金。

但这次开发的华为云 obs 对象存储服务代码的时候公司没有承诺给他奖金，是王某自己想着公司会给他发奖金，所以他向公司要求的时候被拒绝了，就心怀怨恨修改了这个代码。

报案人常某的证词也说明了这一点，他表示：obs 对象存储服务代码是王某二次开发的，公司对开发是有奖励制度的，但公司没有承诺王某开发 obs 代码成功后的奖励。

被告人王某也在供述中证实了，自己确实是因为公司没有兑现奖金而进行的报复，虽然根据侯某、常某的证词来看，公司并未对王某研发的项目承诺奖金：

2020 年 4 月 13 日 11 点多， 因公司领导没有兑现对我的奖励，我就产生了报复公司的想法。

因为某平台 obs 对象存储服务代码是我再次开发的，所以我就想通过修改 obs 对象存储服务代码让消费者在高峰期无法正常进入和使用平台，给平台的名誉和运营造成损失。

然后我就在公司的办公室用公司给我配发的电脑，通过 winscp 软件使用 root 账户(超级管理员账户)登录至华为云服务器的 FTP，将本地的 php 代码替换了华为云服务器 php 代码，导致了用户从 web 服务器直接下载未缓存的图片，高峰期会导致下载缓慢或卡死。

当时操作完我就下班走了。14 日 8 点至 9 点 30 分左右，因为我修改了平台 obs 对象存储服务代码，所以导致平台无法正常使用，让平台的 15 万会员无法进入平台领取电子消费劵。

最终，山西省晋城市城区人民法院对此案作出判决：

被告人王某作为山西某网络科技有限公司的精通计算机技术的专业人员，为了泄愤报复，私自修改计算机信息系统应用程序中存储服务代码，造成了为用户提供服务的计算机信息系统不能正常运行的严重后果，其行为侵犯了计算机信息系统的安全，构成破坏计算机信息系统罪。

依照《中华人民共和国刑法》第二百八十六条、第七十二条第一款、第六十七条第三款之规定，法院判决如下：被告人王某犯破坏计算机信息系统罪，判处拘役五个月，缓刑六个月。

删库风险大，为什么程序员要接连掉“坑”?

删库跑路被抓的例子太多了，想必就不用再多解释了。

但是让人非常不解的是，这些程序员们明知删库的风险，一旦被抓到，不仅可能吃牢饭，还有可能终身失去饭碗，为什么他们还是一直在危险的边缘试探呢?

我能想到的第一个原因可能是法律对删库跑路的犯罪行为界定还不是很明晰。于是，我查找了一下关于破坏计算机信息系统罪的解释。

根据《中华人民共和国刑法》第二百八十六条：

违反国家规定，对计算机信息系统功能进行删除、修改、增加、干扰，造成计算机信息系统不能正常运行，后果严重的，处五年以下有期徒刑或者拘役;后果特别严重的，处五年以上有期徒刑。

违反国家规定，对计算机信息系统中存储、处理或者传输的数据和应用程序进行删除、修改、增加的操作，后果严重的，依照前款的规定处罚。

故意制作、传播计算机病毒等破坏性程序，影响计算机系统正常运行，后果严重的，依照第一款的规定处罚。

也就是说，删库跑路这操作最多也不过五年以上有期徒刑。此前，微盟员工凭借一己之力让微盟一夜之间蒸发 30 亿港元不过也才获刑 6 年。而今天故事的主角也仅仅是获刑 5 个月。惩罚力度低确实是一个促使因素。

那么，除此之外呢?想必还要从程序员自身去找。

曾经听过一个关于程序员这个职业的“真理”：程序员是一个需要随时 996 和随时准备好进 ICU 的职业，并且还要面对三十未立，头发先罢工的现实困境，在外人看来，这个职业虽然辛苦，但是高薪啊，可实际上，高薪的只是一部分人，大部分程序员依旧在基层苦苦敲代码。

早上爆出一条数据安全的大新闻，微盟被删库了.......大家先来看看新闻：

很震惊！很震撼！吓得我赶紧召集全公司服务端小伙伴Review了我们所有的安全部署！！！

彻底检查完之后，我放心了，我们即便被删库也可以快速恢复！

解决完隐忧之后，作为一个在业内安全大厂360工作五年的伪安全人士，今天跟广大做技术的小伙伴聊聊数据库安全那点事：

公告透露出两个重大信息！我们来看看：

第一，恢复时间长，公告是这么说的：「和您一样，我们度过了漫长的36小时，我们预计此次故障还会持续一段」。

那么为什么需要这么久的时间来恢复？

以我的经验推测，一定是生产环境的主备数据库都被删库了！并且大概率应该是做了rm -rf类型的极端操作。不用怀疑就是传说中的删库跑路！当然影响是产生了，人肯定跑不了！

大家可能要问了，那数据库恢复下不就好了吗？没这么简单！

第二，更重要的信息！大家看看这句：「犯罪嫌疑人乃微盟研发中心运维部核心工作人员贺某」。原来是内部人员！

那为什么一个普通运维人员有如此大能量？

很简单，不少互联网的运维人员基本都会有root权限。基本就是公司业务上帝级别的存在。

说实话，我做管理这么多年，对运维岗位工作人员一直是格外尊敬彬彬有礼。当然如果是大厂可以在安全方面做的更完善，数据库操作权限分层分级，就很难出现这种情况。

现实是很多中小公司，运维就那么几个人，甚至一个人。对这样的公司来说，责备团队没做好权限管理就是正确的废话。

（公众号回复 666，带你入圈）

除了微盟这次安全事故，关于删库跑路，一直是互联网的黑传说。

IT界有一个老梗，某论坛的数据库管理员抱怨自己老板一直虐待他，结果他一气之下就删库跑路了……

再假设一种情况，如果在服务器维护的时候不小心执行了 rm -rf 命令……现在整台服务器被删光了肿么办？？？

对于中小公司来说，想把权限做完善做复杂，基本没有可能！想依赖运维人员本身素质和心理状态，那就是靠天吃饭！

中小公司防删库真正的答案是：做好备份！做好最小程度权限管理！

先来看看一个标准的数据库架构图：

从上图中大家可以分析一下关键点：

主库：对应线上实时的业务，如果出现故障，整个系统和网站的访问将受到影响。从库：一般用于查询和主从切换。

备份数据：备份方式常用全量备份和增量备份的方式。备份的策略包括跨机器、跨机房、跨区备份。数据是企业第一生产力，数据备份尤其重要。

数据备份问题也有2个层次。最低层次的，有些公司压根就没有做备份，那出问题一定很麻烦，只能从磁盘做恢复，这个过程非常漫长！

不做数据备份的公司，长点心吧！特别是CTO或者技术负责人，淘汰的就是您这种呐！

高点层次的，有备份但只有全量备份没有增量备份。全量备份当然不能天天做，每个公司有自己的策略，可能是一个月一次也可能是一周一次。如果是这种情况，那这中间的一个月或者一周的增量数据还得从磁盘做恢复，一样很慢！

微盟虽然不是大厂，也算有一定规模了，备份肯定是做了。根据公告的信息，恢复需要这么久，我推断要么是全量是很久前做的，增量数据丢失了，要么是删除者做了极端操作都给干掉了！

2.做好最小程度权限管理

BAT级别的权限管理，咱就不谈了，其实咱也不懂。懂了也没资源做。我谈谈中小厂怎么做好最小程度权限管理。

数据库操作权限和备份权限分离

DBA负责日常主从库的管理和维护。运维负责备份数据的保存。采用全量和增量备份的方式。

如果DBA抽风删除主库，主从同步，则重库数据被删除。业务系统受到影响，运维能马上收到业务报警，运维同事接管数据库，进行备份恢复。

权限申请、权限审批和操作执行分离

控制DBA人员的操作权限，开发人员做数据库表的删除或修改操作的申请。技术主管或负责人审批，生成审批密码。DBA根据密码登录特定服务器，进行相关的操作。

关掉DBA操作数据库终端权限，通过Yearning等审计平台执行数据库命令，高风险命令直接拒绝执行，并发出报警。技术总监或CTO确认没问题之后，才能执行。

以上三点，用最小资源去做，完全可行。如果还做不到，那就采用云解决方案，基本上用好云的方案，问题不大。

技术管理这件事，不能完全依赖人。看公告怎么说的：「因个人工作、生活等原因」。具体什么原因咱也不知道，反正人是不可控的！

技术管理要有抓手！合理结合公司资源做一些限制是很有必要的！

虽然没经历过删库跑路的情况，但是身边的程序员update语句不加where条件的情况发生过2次。

第一次，所在的公司是自建机房，由DBA团队管理数据库集群。某程序员把所有账户的积分字段改了，当时直接吓尿了。

当即停止账户操作的所有业务，DBA全量回复0点的数据，再找到Binlog的update语句的执行点，重放Binlog。检查数据恢复正常，重启开始账户相关的业务。耗时五个小时。

这五小时在老板的狂风暴雨中，你知道我是怎么度过的吗？太艰难了！

第二次，所在的公司使用云服务，数据库使用RDS。某程序员把跟进记录表的用户留言字段全部更改了，导致主从延时报警，销售人员没办法看用户留言的真实数据。

事情发生后，停止该表的业务，DBA通过云服务的工具直接恢复到发生问题前1秒的数据，从发现问题到解决问题也就是5分钟。

以上两个案例与删库跑路类似，都是数据丢失或数据污染之后的解决办法。但是处理起来，耗时不同。关键点在备份上！

给个建议！自建机房的方式需要有完备的dba和运维团队，对技术要求高，中小厂商没能力自建机房的，云方案还是要用起来。另外要关注云提供厂商提供的全套解决方案，千万别只把云方案当服务器使用。

微盟这次事故，我估计就没有采用云数据库，而是把云方案当服务器在用。云方案真正的价值在于容灾、快速扩容、紧急救火。这些能力中小公司要建立起来，不是说不可能而是难度极大。业务高速跑起来，压根没时间没资源去弄！

如果微盟用的是云数据库，云数据库一般都会保留binlog日志，先全量恢复再重放增量。这个恢复速度非常快，不会需要36小时还没弄完，产生这么大损失！

当然微盟也是受害者，说实话中国互联网发展太快，往往即便很努力也没法在很多方面考虑周全。好的是，有了云方案让一些中小公司的确会更高速的发展。看看公告：云厂商也在积极的帮助微盟做数据恢复！

技术人一定是保护用户数据的最后防线。最近几年，由于技术人员无意或者有意造成的事故不计其数。如果代码对世界的影响不大，那么这也许就不成问题。

打个比方，如果你写了一个危害几个人的代码，影响是极为有限的。但是如果你在拥有几亿用户的平台上做同样的事情，结果一定是惨烈的！

技术人一定要遵守职业道德底线，同时关注IT安全，尤其是技术管理者。希望我们一起让技术世界更安全更精彩！