对于节假日，难得的节假日，尤其是出门有好几个数据库告警，还要处理那些告警，实在是太烦人了，于是又想到了一些方法来杜绝和尽可能避免这种情况。一般来说，有这样几种策略：1）节假日提前降低报警阈值，提前应对一波；提前处理问题比紧急解决问题要好得多。3）多人备份，通常这种情况比较棘手，得背着电脑跑来跑去，还要注意电脑的供电情况。当然，网络中也有一些机制可以借鉴，一般有两种：1）对于一些平时可控的处理问题，可以提前设置周期性任务进行处理。比如数据库的binlog增长很快，可以设置周期性的任务来清理，一般是自定义的，本地化程度高。2）对于一些可预见的问题，可以设置处理动作脚本会周期性扫描，一旦发现问题就会触发处理机制，所以这种模式通常会遇到告警/告警恢复的周期性交替。当然，这些策略都不是最好的策略。毕竟，它们还不够通用。有时问题不同，需要区别对待。比如磁盘告警，如果磁盘告警在80%，那么问题不是那么紧急，处理机制最好先处理磁盘空间。如果达到90%，还有磁盘空间清理和提升空间。如果非常有限，需要清理数据库日志等，如果问题的紧迫性不断增加，会逐渐升级，需要接入业务逻辑，从一些日志表的数据入手。大多数情况下，可以通过清理系统空间和binlog来减缓问题的进一步升级，所以能够缓冲几个小时的情况非常少见。移动端的接入也是在和开发同事深入沟通后集成的。这是一套长期稳定运行的功能模块，我们在这方面比较晚。对于磁盘告警在移动端的处理，我定义处理流程如下：告警触发后，可以在移动端处理各个处理动作，在后端调用相应的API和脚本,并返回相应的数据参数。在整个流程中，告警类别的定义和处理流程的安排是比较核心的步骤。拆分下来，最细粒度的就是每个处理动作的定义。后续基本上可以安心出门了，接到临时报警后，心也就平静了。无论如何，这是自我修复的良好开端。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
