最近刷爆朋友圈的一张图，广大DBA玩的不亦乐乎。删库与跑路，一时成为业内的热门话题，并由此派生出很多“创意删”，“经典跑“等。
很快，这场游戏被玩坏了。
而结局并不是“他妈的我管你是谁”。
而是
。。
。。
据新华社北京8月20日电 ，北京一软件工程师徐某离职后因公司未能如期结清工资，便利用其在所设计的网站中安插的后门文件将网站源代码全部删除。记者20日从北京市丰台区人民法院获悉，徐某破坏计算机信息系统罪成立，获刑五年。
删库容易跑路难。一个没有删过库的DBA的人生是不完美的，然而当删库成为DBA体验刺激甚至报复的工具，此时插翅也难逃法网恢恢。
所以不论是作为数据库的守护者 DBA，还是其他的运维人员，一定要遵循职业道德不断加强自我修养：
作数据的保护者，而不是窥探者、窃取者和破坏者；
理智和情感分离，以成熟成职业，不以情绪行偏颇。
当删库成为一种时尚
- 6月初，位于荷兰海牙的一家云主机商 verelox.com， 一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容，带来了巨大的损失。
- 而若操作者具有较高级别的权限，数据库面临的灾难则是巨大的。Lucchese前IT主管，在离职的时候收集了IT部门所有职工的用户名和密码然后伪装成一台办公室打印机创建了一个密码账号，并在其办公室内使用该账号进行了一系列的违规操作，给企业带来了严重的损失。Venzor后来被捕，并面临最高达10年的监禁生活以及25万美元的罚款。
- 在刚刚过去的7月，花旗银行的前员工伦农·雷·布朗，通过非法执行命令，删除了花旗银行的内部网络上10只核心路由器上的配置文件。结果引起的故障导致全国110个分行无法正常使用网络和电话系统，占到花旗银行所有分支机构总数的约90%。
我们总结了今年来比较有名的删库事件：
我们是谁
我们是谁？
DBA
我们做什么？
数据运维
数据运维的核心是什么？
保障数据的安全
作为广大DBA的一员，我们扮演神圣的角色，我们希望做用户最忠实的后盾，在任何疑难问题和故障面前，能够骄傲地说，有我在！
DBA是一个高危的行业，接触并保护企业最核心的数据资产，我们不是数据的破坏者，而是数据的保卫者！用双手，托起企业的核心。
然而现实中，一次次删库事件的发生让我们心痛，到底发生了什么。今天，我们来谈一谈那些删库背后的故事。
我为什么要删库
从上半年的各类惨绝人寰的删库事件中，我们总结了以下原因：
1、硬件因素
服务器质量不能支撑业务的增长
2、环境因素
意外断电等原因导致系统暴毙
3、人为因素
3.1 错误操作，DBA误敲命令
3.2 恶意删除，由于DBA个人情绪
前面的三种原因在现实中总是很难避免，谨慎操作与有效备份是不二之选。最后一个原因，也就是人为恶意删除，当然是我们今天最想谈的原因。
这个世界上有两种关系是无法调和的。
一种是婆媳关系。
第二种是老板与员工的关系。
身份不同导致立场和利益的冲突，总有不满意的员工和不满意的老板。谁对谁错其实很难判断，确定的是，在发生类似故障的企业，员工与领导之间缺少有效的沟通。但是，无论如何，这些都构不成员工恶意删库的理由。
作为一个DBA，就像是企业系统的主治医生，最重要的不是技术有多强，针缝得有多好，而是用心守护你的系统，保护数据与系统的安全，不让它受伤。这是道德的规范，也是法律的约束。是每一个DBA都应该坚持并践行的理念。
在任何情况下，都应该牢牢记得，我们是数据的保护者！
保持职业道德，做数据库最值得信赖的男朋友！（既然大家都没有女朋友，有个人爱也是好的）
删库谁来拯救我
对于企业来说，如何幸存于类似事故？
以下是我们的一些思路，与大家商榷。
首先，要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制，但是这套备份机制能否真实奏效是需要检验的。我接触过某大型企业，投入巨资兴建的灾备中心，从未正式切换过，这样的灾备在故障来临时也很难有人拍板去进行切换，所以备份的有效、容灾手段的有效是必须确保的。注意，备份的恢复速度必须足够的考虑到，磁带的低效备份关键时刻会害死人。
其次，要有完善的故障处理策略和流程。对于不同系统，在关键时刻要优先确保什么，是要订立规则的，有了规则才能照章办事，不走错方向，不无辜背锅。几年前某国内金融系统出现数据坏块，同样选择了带病修复，最终没能解决问题，同样选择了回档承担了数据损失。
再次，要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案，从业务端同样要有对应的预案，以便应急时同步处理，区别对待。很多时候，有了业务上的应急、降级服务方案，技术层面的处理就能够从容许多。
最后，要有能够快速协同的团队资源。很多时候严重的故障，需要较大规模的专业团队协作处理，原厂商和第三方在其中都承载着重要的角色，所以关键时刻，要能够获得内外部快速及时的支持，尤其是在绵延数天的高强度工作中。
然而，计划总是赶不上变化，故障来临时就像爱情，总是防不胜防。
我们之前对于各类故障做过一个分析，列举如下：
都是真实的案例，种种小疏忽，导致大事件：
- 服务器找不到了
某次客户找我们恢复数据库，说某个数据库出现故障，原本以为不再需要了，现在还需要其中的数据，可能是时间太久远了，工程师到现场后，客户说服务器找不到了，就算了。
三个月后，客户来电说，服务器找到了，我们又去帮用户恢复了数据。
- 服务器搬走了
某次客户数据库故障，检查发现，是RAC的某个节点服务器被搬走了，以为不用了，郁闷的是，断电还导致了ASM磁盘头损坏，还好11g修复ASM磁盘头很简单，迅速帮助用户恢复了数据库运行，再搬回服务器，加入节点。
- 磁盘搬走了
也是今年的某个客户，新上线服务器，客户找了一块以为不用的磁盘，强制拉过来格式化，发现另外一个业务库应声倒下了。
- DBA走了
最近提到过的一个客户，因为把DBA解雇掉了，结果，DBA偷偷上来把整个库给删除掉了，业务挂了很久很久。
- 网线拔了
这是2015的案例，在业务高峰，新上一个交换机，网络运维把生产数据库的网线拔了，影响业务10分钟。这是金融业务，据说客户的人都跑到机房，机房满员。
- 磁盘故障
这也是2015年的新案例，客户的存储工程师划分给数据库ASM的磁盘小于请求容量，数据库文件扩展时越界产生了故障，金融客户的大事故，这是队友埋的坑。
- 发电厂搬走了！
因此，还是要苦口婆心地说，备份重于一切。预防和检测少不了。有效备份让你的数据更安全。（Bethune智能诊断平台，帮助你检测系统安全及备份有效性。https://bethune.enmotech.com）
文章来自微信公众号：数据和云
本文链接：https://www.yunweipai.com/22284.html
网友评论comments