我们的工作中不可避免的会出现琐事，公司不同、岗位不同，琐事的数量和种类也不尽相同。只要是正常人，都会除之而后快。这次看看Google SRE如何kill toil。
SRE怎么定义琐事
在Google SRE的概念里，琐事是指：运维中手动性的、重复的，可以被自动化的，战术性，没有持久价值的工作。同时，琐事还会与服务呈线性关系增长。
还是举个粟子好懂点：比如每天手工查看100台服务器的日志磁盘配额有没有写满。这事是手工操作；是每天或周重复做；是可以用定时脚本自动完成的；战术性在这件事上体现不出来，感觉战术性跟琐事关系不大，可以略过；这事做完后并不能长治久安，所以没有持久价值；最后，随着业务量增加，服务器会增长到200、300、400，这个检查工作也会同比增加，所以是线性增长关系。
怎么干掉它们
SRE的公开目标是保持每个SRE的工作时间中琐事的比例低于50%。怎么做到：
- on-call制度。SRE把工作分为日常运维工作（琐事）和工程工作。日常工作实行on-call制度。比如一个轮换周期内，一个SRE会有一周时间主on-call和一周时间副on-call。因一个6个人的轮值周期中，每个SRE都会有2周时间on-call做日常运维工作，4周时间做工程工作。那么他们的琐事占比就会是2/6，也就是33%。如果是8人轮值，就是2/8，也就是25%。这种轮班制度天生就控制了处理琐事的比例。
- 工程工作制度。用工程工作塞满剩余的时间，并持续减少或控制琐事的数量。
- 工程工作是新鲜的、本质上需要主观创造的工作。它符合长期战略，会对服务进行长久性的改善工作。着重通过设计来解决问题，解决方案的通用性、可复用性体现其价值。这种工作是根本上解决服务对象增加，而团队规模保持不变，甚至减少的办法。
- 主要工作包括：
软件工程：编写或修改工具，改善服务的可靠性。如：开发自动化框架，开发监控系统；
系统工程：配置环境或运维工具，参与研发架构设计和生产环境咨询等工作，能一次性产生持久的改进。如：配置负载均衡、配置自动化规则、帮助服务产品增强可靠性机制。
- 保持警惕的检查机制。如果发现一个团队的工程时间比例大幅低于50%，那么这个团队要退一步来找出问题所在。
运维组织可以对照以上的方法，调整自己的工作安排，希望运维苦工也有机会转身成为攻城狮。
回头谁能留意下SRE有没有解决开会太多的问题，大公司病害死人啊~~
