AiFault是我们AIoT SRE团队研发的插件化智能应用运维中台，旨在用DevOps思想和工具化思维，系统全面的解决应用运维的各种问题，目标是能够承载一套完整的运维体系，最终实现一站式智能运维。
这个也是AiFault上的一个插件，我们团队内部叫“清道夫sweeper”项目。
截止此刻落笔，共接入2000+台服务器，累计自动清理硬盘3万+次，累计自动清理空间5PB+，还在继续接入中。
一、DevOps背景
“刚改的计划任务，怎么大半夜的硬盘又告警了，大.爷的！！”
“@某某开发，硬盘满了，哪些日志你还要用，尽快回复我...”
“刚才有一波突增流量，磁盘告警了，@某某SRE尽快清理一下！！”
“大 .爷的，新到的几台服务器硬盘容量小，这是不是得做单独的计划任务？？”
“最近流量上涨，硬盘频繁告警，@某某开发是不是可以缩短一下日志存储时间，我改下计划任务？”
“最近查bug，需要延长日志保留时间，@某某SRE请评估下硬盘空间，看看能延长多久，帮忙改一下！！”
………………….
类似上述硬盘告警的处理层出不穷，每天都会在不同时间出现，每次还都需要放下手头的事情第一优先级处理，属于典型的繁琐重复、技术含量不高且不得不处理的常规运维事务。
终于有一天，某开发leader找过来：“为什么昨天有个硬盘告警你们没处理，这个不是应该SRE第一时间处理么？？上次的清理脚本因为SRE工作交接还是我们开发帮忙写的！！”
了解后，当天值班的SRE确实有苦衷，但这并不能成为没处理的理由，工作职责就是工作职责。
我是个要脸面的人，这事儿脸上真是挂不住了，它也成了压死骆驼的最后一根稻草，心想：“硬盘告警处理绝不能走老路搞下去了，必须使用新思路、新方法，一来当前的方式没什么技术含量，团队同学处理的疲乏无味，二来计划任务的方法不科学，策略调整和告警处理太依赖人的干预，而且随着流量的变化要经常调整。”
而且自始至终，我都不认为是值班SRE不负责任，而是处理方式本身弊端太多，没有系统彻底的通过技术解决问题，老虎都有打盹的时候，何况是人呢？
二、思考设计
仔细分析，当前做法的核心弊端是按时间周期清理（日志、core文件等），保存时间是根据过去日志大小SRE粗略计算的，因为很多场景都会造成日志量的变化，所以计划任务是很不准的，要么存储空间不够、要么存储空间浪费。
所以如果有一种方法，可以实时监控硬盘容量，并根据存储空间的剩余情况自动按照设定好的规则清理，这个问题是不是就解决了呢？
另外，服务器存储也是一种资源，是不是也需要将这个资源管理起来，以便于了解目前硬盘的使用情况，比如说有没有浪费？
想到这已经有初步方案了，而且是可行的，因为出发点是为了解决一类问题，所以必须找到这个项目的负责人后，组织大家脑暴一次，收集所有一线SRE从用户角度的需求。
业务是miot的，考虑后佳豪（李佳豪，智商很高极其聪明的一个SRE，Dev能力极强）是最佳的项目人选，我把想法和他沟通后，一拍即合，没想到佳豪异常兴奋，我记得当时原话是“这么做真的很有意思，我愿意做！！”。
三、脑暴评审
我们进一步沟通了能想到细节，然后佳豪很快拿出了一个技术方案（智商高真的很可怕），并确定用go语言编写，因为go发布的是二进制不依赖机器环境，可以最小成本最大效率的部署应用，并且把用户操作的配置文件先设计了出来，紧接着组织了一次脑暴。
脑暴的效果非常好，用一句话概括就是“天下苦秦久矣”。大家都想彻底的把这个问题解决掉，因此很快达成了一定要做的共识，并现场建言献策，将各自的需求和经验痛快淋漓的表达了一番。还是群众的力量厉害，很多我和佳豪讨论时没有想到的点，在这次脑暴会上丰富并清晰了起来。
- 清理要设置高低水位，高水位开始清理，清理到低水位结束；
- 清理要设置策略优先级，并支持正则匹配，优先清理优先级最高的日志；
- 清理方式要支持rm、echo；
- 清理时要支持最小保留时间，不能把日志都清了；
- core文件清理时，只保留最近一个core文件，无需配置；
- 可以支持二分法清理，有些日志是按大小切割，而不是按时间；
- 有些文件和文件夹不能清理的，要支持设置白名单；
- 配置文件用yaml，一个产品线一个策略，接入部署系统统一管理；
- 清理的过程要详细记录日志；
- 工具清理的次数、空间大小等核心指标要在aifault上分产品线计算展示出来；
- 工具本身的性能问题要做好监控、告警；
- 后期配置文件要支持aifault的下发，云配；
- ...................
四、建设成效
截止此刻落笔，共接入2000+台服务器，累计自动清理硬盘3万+次，累计自动清理空间5PB+，接入后再也不用维护计划任务了，硬盘告警清零、硬盘清理计划任务清零，真正解放了生产力，业务还在继续接入中。
上图统计了小爱产品线接入sweeper的服务器近30天硬盘清理情况，平均每天自动清理200次左右，如果用传统的计划任务管理，每个抖动的点，基本意味着要人工参与，现在完全自动处理，访问量小的时候自动多存几天，访问量大的时候自动少存几天。
再看1月2日这个点，刚好在元旦假期中，这天中午小爱南方机房出了一个故障，客户端大量重试导致服务器访问量突增，有些服务出core了，磁盘用量迅速增长，放到之前，处理完故障后，得马上清理一次硬盘，然后还要调整计划任务，服务器用了sweeper后，我们完全不用考虑硬盘的处理，全过程自动化，是真香！！！