这是学习笔记的第 1793篇文章
这两天在琢磨一个报警问题的时候，把一些问题想明白之后，突然可以做得看起来高大上许多，其中一个发力点就是故障自愈。
以前去提这个概念感觉很遥远，但是实际上任何一个问题往深了琢磨，都是解决思路和方法，在解决问题的过程中，选择最通用，最贴近当前问题的方案肯定会优先考虑。
在以前的工作中，就经常碰到磁盘空间不足的警告，当然从不同的维度都能得到不同的结论和解决方法，但是相对来说，这个问题的解决思路其实很清晰。
一旦发生了磁盘空间的问题，那么这个问题一定是很严重的，直接关系到业务的可持续访问。
如果这个工作前置一些，那就是阈值的处理，如果阈值为80%，那么有时候报警信息是80.5%，80.1%这种情况，在大周末的时间专门去处理这类的问题，其实是很没有成就感的。
在之前的处理中，如果是在节假日之前，我们会把阈值调低一些，把问题提前修复，这是一种临时解决方案，还有一类方案，那就是故障自愈。如果问题发生了，我们有完善的预案，这也是一种相对可持续的方案，对于我们工作来说，我把问题的修复分为主动和被动，从主动的角度来说，我们可以通过指定的入口来查看系统自动优化了多少次，提前避免了多少故障修复，对于我们的工作而言，也是很有成就感的，从被动的角度来说，我们可以通过短信，微信之类的渠道获得报警信息，但是很快得到了自动解决，通过即时通信软件告诉你搞定了，对于我们的工作来说，是极有成就感的。
在这些问题之外，有些特别的问题是不能自动解决了，这个需要人工介入，在人工介入之前，借助故障自愈也能够让这个处理的紧急度可以缓和许多。
前前后后我设计了两版针对磁盘空间自动修复的方案，把这些信息都汇总起来，也就是一个故障自愈的雏形了。
初步的设计思路就是创建一个预留文件，占用空间的1%~2%，如果发生了故障的时候，可以把这个空间释放出来，尽快响应业务需求。
在这个基础之上，再继续做空间和资源的平衡和分析，能解决的可以提前处理，解决不了的则做一个初版的分析，在分析基础之上，如果能够再进一步沉淀，就可以逐步的实现故障自愈的解决方法了。
从可持续的角度来说，其实希望这个预留文件的初始化是一个周期性任务调度的结果，而不是通过人为的控制和操作。所以借助于周期性调度，和事件触发方式，相信能够基本解决这一类通用的问题。
