如何彻底杜绝磁盘报警

作者：焦振清
时间：2017-12-04

---

说起磁盘报警，相信大家都是一副不屑的眼神，这种事情，还需要专门写一篇文章？哥们你是闲的慌吧。大家不屑的原因是：磁盘报警没什么了不起，只要服务进入稳定状态，各种磁盘报警都经历一次，查漏补缺，以后磁盘报警就很少了，偶尔半夜来几条，也无伤大雅，搞运维嘛，还能没报警呀。那么这种思路违反了一个原则：同样的错误不能犯两次！并且处理问题太过被动，让问题挨个半夜找上门来，也太辛苦了。所以，我和团队的同学提出一个问题，磁盘报警，能否通过一种机制，彻底消除呢，即使无法消除，是否也可以做到，一个季度最多一次磁盘报警？这个问题的背后，是我们做事情的价值观：一次性的投入，持续彻底的解决某一类问题，我们愿意为这种工作做足够多的投入。

具体到磁盘报警上，一个季度最多一次磁盘报警，不论什么原因！那么我们就要分析，有哪些可能会导致磁盘报警呢？我先简单列举一些，后续慢慢完善补充

• 服务相关的
  • log：业务日志将磁盘打满
  • data：业务数据将磁盘打满
  • bin：进程coredump文件将磁盘打满
  • conf：业务配置文件的历史版本将磁盘打满
• 运维系统相关的
  • 部署系统：在磁盘上做历史部署包的备份
  • 传输系统：在磁盘上做传输时的冗余副本
  • 备份系统：在磁盘上做打包
• 基础架构相关的
  • 各类agent：类似于服务相关的，bin/conf/data/log都可能导致问题
• 操作系统相关的
  • /var/log/下的系统日志
  • /tmp下的临时文件
  • 删除的文件还被引用导致空间未释放
• 人员操作相关的
  • 拷贝日志到临时目录处理完毕后未删除

可能还会有其他的一些原因导致的磁盘异常，需要不断的更新完善，但是当大家把磁盘打满的原因从服务日志扩展到多个方面且逐渐形成磁盘清理标准化策略，并通过Puppet工具推送到全部机器上的时候，磁盘报警数量就可以得到有效的控制，这个时候，相信，没有人会说，磁盘清理这种事情不值一提。

其实，走到这里，问题还远远没有结束，具备BAT自动化运维能力的公司毕竟少数，很多公司事实上还处于小米加步枪的阶段，那么即使有了一个足够好的磁盘清理插件，距离没有磁盘报警，还有很多的路要走，比如下面的问题：

• 如何确保磁盘清理脚本能够100%覆盖所有机器而不会有任何遗漏
• 如果确保磁盘清理脚本的更新版本能够100%覆盖所有机器而不会有任何遗漏
• 如果确保新扩容的机器能够立即部署了磁盘清理脚本
• 磁盘清理脚本在单机上以何种方式定期运行，谁来保证这种定期运行机制的有效性
• 如何确保磁盘脚本不会做坏事，比方说将线上需要的东西给删除掉了
• 如何确保磁盘清理脚本在清理文件的时候不会产生瞬时的大IO导致业务受损
• 如果例行的机制确实没有拦截到报警，报警发生后是否可以通过自动化的方式进行处理
• 如何避免磁盘清理脚本因IO问题而卡死导致机器上出现无数个类似的进程
• 脚本依赖的命令在删除文件场景下有没有最佳实践避免踩坑的行为（资源问题为主）

为了解决上面的问题，可能需要建立puppet来进行机器状态的维持，对监控系统新增异常自动回调的能力，需要统一的机器管理系统，等等之类的基础架构建设和完善工作。因此，再次回顾我们的目标：一个季度至多一次磁盘报警，想要达成这个目标，可能远飞我们想象的那么简单。相信，在基础架构的逐步完善，人员意识的逐步提升，Aiops的不断介入，今后的运维工作会越来越好！