如果系统正常运转中需要人工干预,应该将此视为一种 Bug。
"正常"的定义会随系统的进步而不断改变。
—Carla Geisser,Google SRE
SRE 要把更多的时间花费在长期项目研发上而非日常运维中。因为术语日常运维可能会被误解,我们在这里使用一个专门的词语——琐事(toil)。
琐事不仅仅代表"我不喜欢做的工作"。它也不能简单地等同于行政杂务加上其他脏活累活。每个人满意和喜欢的工作类型是不同的,有的人很喜欢手工的、重复性的工作。同时,一些管理类杂务是必须做的,不应该被归类为琐事∶这些是流程开销(overhead)。流程开销通常是指那些和运维产品服务不直接相关的工作,包括团队会议、目标的建立和评估、每周总结以及人力资源的书面工作等。而脏活累活通常具有长期价值,这些也不能算作琐事。例如,为服务清理警报规则或降低噪声率可能是一件繁重的工作,但这些不是琐事。
到底什么是琐事?琐事就是运维服务中手动性的,重复性的,可以被自动化的,战术性,没有持久价值的工作。而且,琐事与服务呈线性关系的增长。并不是每件琐事都有以上全部特性,但是,每件琐事都满足下列一个或多个属性∶
手动性
例如手动运行脚本以便自动执行一些任务。运行一个脚本可能比手动执行脚本中的每一步要快,但具体运行脚本所花费的手动的时间(而非脚本所需要的运行时间)应该被认为是琐事。
重复性的
如果某件事是第一次做,甚至第二次做,都不应该算作琐事。琐事就是不停反复做的工作。如果你正在解决一个新出现的问题或者寻求一种新的解决办法,不算作琐事。
可以被自动化的
如果计算机可以和人类一样能够很好地完成某个任务,或者通过某种设计变更来彻底消除对某项任务的需求,这项任务就是琐事。如果主观判断是必需的,那么很大程度上这项任务不属于琐事。
战术性的
琐事是突然出现的、应对式的工作,而非策略驱动和主动安排的。处理紧急警报是琐事。我们可能永远无法完全消除这种类型的工作,但我们必须继续努力减少它。
没有持久价值
如果在你完成某项任务之后,服务状态没有改变,这项任务就很可能是琐事。如果这项任务会给服务带来永久性的改进,它就不是琐事。一些繁重的工作——比如挖掘遗留代码和配置并且将它们清理出去也不是琐事。
与服务同步线性增长
如果在工作中所涉及的任务与服务的大小、流量或用户数量呈线性增长关系,那这项任务可能属于琐事。一个良好管理和设计的服务应该至少可以应对一个数量级的增长,而不需要某些一次性工作(例如增加资源)之外的额外工作。
|