我们先回顾一下SRE的定义:SRE就是用软件工程的思维和方法论,通过设计、构建自动化工具完成以前由运维工程师手动操作的任务。所以,SRE要把更多的时间花费在长期项目研发上而非日常运维中的琐事。
琐事就是运维服务中手动性的,重复性的,可以被自动化的,战术性的,没有持久价值的工作。而且,琐事与服务呈线性关系的增长。琐事具有以下特点:
手动性:例如收到磁盘目录满告警,运维人员手动清理日志。
重复性:如果某件事是第一次做,甚至第二次做,都不算琐事。琐事就是不停反复做的工作,如果你正在解决一个新出现的问题或者寻求一种新的解决办法,不算琐事。清理磁盘目录不太可能是一次性的,因此我们需要反复去处理它。
可以被自动化:如果软件程序可以和运维人员一样能够很好地完成某个任务,或者通过某种设计变更来彻底消除运维人员手动、重复的处理某项工作。
战术性的:琐事是突然出现的、应对式的工作,而非策略驱动和主动安排的。比如处理日常告警,我们可能永远无法完全消除这种类型的工作,但我们必须继续努力减少它。
没有持久价值:如果在你完成某项任务之后,服务状态没有改变,这项任务就很可能是琐事。如果这项任务会给服务带来永久性的改进,它就不是琐事。
与服务同步线性增长:如果在工作中所涉及的任务与服务的大小、流量或用户数量呈线性增长关系,那这项任务可能属于琐事。
对运维团队来说,琐事不可避免。运维不可避免地需要处理部署、升级、重启、告警处理等工作,这其中又包含很多上面所说的琐事,如果不加以控制,琐事会变得越来越多,以至于迅速占据我们每个人100%的时间!每日疲于奔命忙于救火,就无法将更多的力量投入到扩大服务规模的工程工作上去,或者是进行下一代的服务的架构设计。
SRE中的E是Engineering。中文可以翻译为“工程工作”,SRE就是通过工程工作来减少琐事。
工程工作通常是有创新性和创造性的,着重通过设计来解决问题,解决方案越通用越好。例如,编写自动化脚本,创造工具或框架,增加可扩展性和可靠性的服务功能,或修改基础设施代码以使其更稳健。工程工作有助于使该团队或是整个SRE组织在维持同等人员配备的情况下接手更大或者更多的服务。