Google SRE如何杀死琐事(toil)

我们的工作中不可避免的会出现琐事,公司不同、岗位不同,琐事的数量和种类也不尽相同。只要是正常人,都会除之而后快。这次看看Google SRE如何kill toil。

SRE怎么定义琐事

在Google SRE的概念里,琐事是指:运维中手动性的、重复的,可以被自动化的,战术性,没有持久价值的工作。同时,琐事还会与服务呈线性关系增长。
还是举个粟子好懂点:比如每天手工查看100台服务器的日志磁盘配额有没有写满。这事是手工操作;是每天或周重复做;是可以用定时脚本自动完成的;战术性在这件事上体现不出来,感觉战术性跟琐事关系不大,可以略过;这事做完后并不能长治久安,所以没有持久价值;最后,随着业务量增加,服务器会增长到200、300、400,这个检查工作也会同比增加,所以是线性增长关系。

怎么干掉它们

SRE的公开目标是保持每个SRE的工作时间中琐事的比例低于50%。怎么做到:

  1. on-call制度。SRE把工作分为日常运维工作(琐事)和工程工作。日常工作实行on-call制度。比如一个轮换周期内,一个SRE会有一周时间主on-call和一周时间副on-call。因一个6个人的轮值周期中,每个SRE都会有2周时间on-call做日常运维工作,4周时间做工程工作。那么他们的琐事占比就会是2/6,也就是33%。如果是8人轮值,就是2/8,也就是25%。这种轮班制度天生就控制了处理琐事的比例。
  2. 工程工作制度。用工程工作塞满剩余的时间,并持续减少或控制琐事的数量。
  • 工程工作是新鲜的、本质上需要主观创造的工作。它符合长期战略,会对服务进行长久性的改善工作。着重通过设计来解决问题,解决方案的通用性、可复用性体现其价值。这种工作是根本上解决服务对象增加,而团队规模保持不变,甚至减少的办法。
  • 主要工作包括:

软件工程:编写或修改工具,改善服务的可靠性。如:开发自动化框架,开发监控系统;
系统工程:配置环境或运维工具,参与研发架构设计和生产环境咨询等工作,能一次性产生持久的改进。如:配置负载均衡、配置自动化规则、帮助服务产品增强可靠性机制。

  1. 保持警惕的检查机制。如果发现一个团队的工程时间比例大幅低于50%,那么这个团队要退一步来找出问题所在。
    运维组织可以对照以上的方法,调整自己的工作安排,希望运维苦工也有机会转身成为攻城狮。
    回头谁能留意下SRE有没有解决开会太多的问题,大公司病害死人啊~~
点赞