遥想我刚开始工作，做的是一份令我感到十分厌恶的运维工作，为什么呢?因为所有事情几乎都要靠手动去执行，没有什么dashboard或自动化工具能分担工作负担（word load）。这让我一开始对运维工作的印象是消极的，同时也让我意识到运维开发是大有可为的。
那么今天就看看谷歌的SRE是怎么看待工作中这类繁琐、重复的工作。
定义
不仅是我不喜欢做的工作（the work I don't like to do）
和一般管理性工作或者grungy工作不同，这类工作是仁者见仁的，有些人甚至比较享受这种重复、完全手动的工作。那么toil到底是什么工作呢？这里有这么几个词
manual,repetitive,automatable,tatical,devoid,enduring value,linearly grows
- manual，不像是导航失控之后必须切换成手动控制，而是本可以通过一个script来解决，但仍要使用手动的方法（个人觉得这里应该加个前提:操作人员有脚本化的能力与意愿）
- repetitive 这里的重复是有一个前提，比如这件工作一个月执行两次，每次耗时5分钟，然后自动化可能需要1~2小时（并且可能还需要进行验证），那么可以不称这种工作是重复的
- automatable 这个词虽然含义是自动化，但注意，其实原文的意思是，如果一件工作，它不是以依赖人的判断（这里偏重经验），那么它就是automatable的。比如生产线上的机器人，它的工作结果是有图纸这种非人类经验判断为基准的，那么它就是可自动化的
-
tatical 这个解释，我觉得是SRE中对toil定义非常重要的一点，不同于什么机械重复这种耳熟能详的词汇，toil工作有一个特点，就是它是会打断你的工作流且让你必须做出及时回应的工作，而不是策略驱动的（strategy-driven，这里策略驱动的意思就是提前计划好的)
我觉得这里非常给人以启发，其实好的站点稳定性运维工作，最理想的状况就是变成类似windows的事务管理器那样，我可以设定好策略，我每小时、每天、每周都要做什么，我又能将突然的toil集中到一起进行临时性的处理 - no ending value
这个概念也很新颖，简单来说，如果这件工作对未来并没有好处，或者没有明显的好处，那么它也是toil。怎么理解呢？满足你对命令行敲命令的快感并不是好处，真正有意义的工作，需要能整个服务、项目的发展上，起到积极作用。
比如你突遇某偶发bug，花费若干小时替换了所有项目都会使用的一个中间件，这个中间件可以提升25%的请求鉴权效率，那么它就不是toil，因为它有长期意义。
再比如你把某数据库引擎的缺陷整理称文档并输出，这也不算是toil。
O(n) with service growth
随着服务规模的增长线性增长
这里还是没有把“共性”进行提取，将一些工作的成果进行“复用”
比如我新增服务之后，会自动下发任务按照配置好的模板部署监控服务，那么这一块就不是线性增长的（当然需要考虑，处理告警这块的开销也有做到非线性增长吗）
为何toil少了就好
谷歌SRE的标准是，toil工作不能超过SRE工程师50%的工作时间。其实从这个数字可以看出，即便是技术标杆的谷歌，toil工作也不少，不然也不可能定这个数字。
书中讲到，首先我们需要明白一点的是，这种工作是无法绝对杜绝的，这和技术没关系，也业务类型也没关系。我们需要做的就是守住这个红线，因为一旦超过这个数字，这类工作就会像缓存雪崩一样恶化，占比迅速增长到每个工程师每天所有时间都要处理这类工作。
工程
这小节我觉得应注意一下，我们很多岗位，很多title都带有工程师的字样，但是我们很多人并不理解什么是工程师。工程师脱胎于工程，而工程是需要人类判断的（human judgement），所谓工程能给你的提供的服务带来持续的提高（improvement），让这些服务能被策略所指引。它是非常需要创造性和创新性的。
我们将我们所有SRE（站点运维）活动归为四类：
1，软件工程
如编写自动化脚本，编写相关工具、框架，新增服务特性（service feature，就是版本变更点），增强服务的伸缩性和可靠性，使基础设施更加健壮
2，系统工程
如配置生产环境、修改配置、编写相关文档、构建系统负载均衡等
3，toil
上文的那些工作
4，overhead
管理型工作，和你负责的软件服务无直接关联的工作，比如HR paperwork， 小组、公司会议、个人评估、培训等
然后再次强调，toil不能超过总量的50%（这里感觉谷歌SRE形似我们的业务运维，但是相比业务运维，又有更多工程师的成分）
toil总是不好的吗？
直接答案：不是
