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