序言
从删库到跑路，别人做了一辈子不敢干的事儿。。。不敢想也不敢做更不敢当。
小手冰凉，整天嘴里叽叽喳喳的哒哒哒，一个女孩子，怎么可以打打杀杀的呢？
长的漂亮，别人可能会多看你几眼，但是。。。你要是删库了，能高看一眼。。。是个狠人，狠起来连自己都能打。。。
纵深防御
1 运维负载
运维面临着很多压力，也有很多的挑战，东西总是要坏的，这就是生活。
运维，都希望自己在on call的时候，不会收到告警，然而现实却不是，垃圾系统遍地开花，还美其名曰，高端架构，高并发，高性能。。。一点都不可靠。
其实都一样，无论是开发，还是运维，都是逐步演进的，变得越来越复杂，变得越来越庞大。
运维压力来自于几个方面：出现故障时的恢复时间，毕竟SLA在哪放着；运维琐事一大堆，有的是开会，有的各种垃圾警报，误报的，多报的，少报的；还有各种故障报告需要写；还有各种技术需要去学习，去提高；还有各种不同的人需要去交流沟通，需要推进问题的解决。
关注运维，关注琐事，减少琐事的时间，将主要的时间，精力放在自己感兴趣的地方，放在有挑战的地方，从而，每天最多只能处理一个紧急事件，而对于普通的工单类型的问题，可以花费几天，而最重要的是，一天的时间占比，其中应该有部分时间用来提高自己的技术技能，或者是用来自动化的时间，这是一个持久的工程。
当发现负载很高的时候，应该适当的减少琐事，将一些优先级较低的事情放在后面慢慢处理，而不是再次去追寻速度，当负载很低的时候，那就可以搞事情了，各种演练，容灾演练，备份恢复演练等，提高生产环境的感知力。毕竟过多的负载容易没脑子，CPU队列一直在排队；而负载过低容易造成生产环境生疏，所以演练也是锻炼的一个过程。
梦想是好的，现实是996，007，运维负载，开发负载，测试负载，现实就是一个压测环境。。。扛得住就抗，扛不住就是平庸的员工啦。。。反抗呢？反抗就是251咯，就不是兄弟咯。。。
2 数据库监控
数据库有各种各样的监控指标，各种各样的备份系统，其中的原则是，早发现，早恢复，对于数据完整性来说，只要丢失了部分的数据，那么就有可能数据库无法启动，也有可能是巨大的业务损失，但是要是在用户发现之前就解决了，那么数据库的可用性就是百分百。
上云的时候，各种云都吹牛逼，说数据可靠性能达到多少个9，但是他们没说，在极端情况下能保证多少。
除了数据库的基本监控之外，那么还可以添加数据库的备份监控，最简单的方式就是监控数据库的备份文件是否存在，假如设定的阀值为3份，一旦检测发现少于三，那么此时立刻触发备份，并发送告警；一旦发现只有一份的时候，那么此时立刻将备份远程传输到分布式存储中，并触发备份和告警。
这样监控就完了么。。。还要继续，备份不是为了存档，而是为了恢复，所以呢，可以在数据库层面，做一个自动化测试任务，此任务的主要目的就是为了检查备份是否可用，自动创建一个数据库，自动将备份进行恢复，如果发现无法恢复，那么可能以前的备份都是无效的，发送告警，并重新进行备份。
备份只是一种手段，所谓的三副本也只是一种手段，真正的目的是为了当数据库出现问题的时候及时的将数据进行恢复。
raid就一定可靠么，如果硬件没做好监控，raid坏了一块你没发现，坏了两块。。。那就比较凉快了。
在这个层面上，其实多做演练，确保熟悉流程，并确保备份可用，也是一种防止误删的一种手段。
3 回收站
当我们一不小心删除一个文件的时候，文件都会进入到回收站，清理回收站之后，文件才会被真正的删除。
其实对于云平台来说也是一样的，对于最终用户来说，删除一个东西，进入云平台的回收站里面，用户删除是自己有权限的，而对于回收站里面的清空则是一个云平台的权限，回收站的最大功能就是保证了如果用户误删除了，那么还是可以直接恢复的。
一个云平台好不好，可以从这个方面来进行判断，保护了多少用户的误操作，无论是极端的操作，还是一些普通的错误操作。这才是关键。吹牛逼的时候，大家都可以，都能，都会。。。一旦真正发生了故障，我不行，我不可以，是你自己操作的。。。摔锅三连。。
对于任何事情来说，都是从三个方面来进行保障一个系统的正常运转，那就是人，系统，制度。
制度就是关注运维负载，系统就是云平台，保障的底线，很多风险都是平台扛着，无论是可靠性，可用性，高性能都是经过事实的验证的，而制度则是各种应急演练流程，各种备份策略，各种告警监控优化，三个方面缺一不可。
思考和解决问题的方法很关键，首先。。。我们的认知要同步，不然都会痛不欲生。。。
长的漂亮，别人可能会多看你几眼。。。然而你要是删库了。。。别人才会高看你一眼。。。别人家的运维都是很个性的。。。哎，我比较平庸。。。
自动化做的越来越好，那么运维也会越来越少。。。珍惜运维，快绝种了。
防御永远不是最佳策略，最佳策略是进攻。。。所以呢，没事删库演练演练，毕竟黑天鹅事件偶尔会发生，没有碰到只不过是幸存者而已，现实是。。。手抖心慌慌。。。哪只手删的剁哪只。。。
