Q1：SLO是运维和开发共同制定的吗？
是的，在定义服务级别目标的时候建议和研发团队共同制定，同样的错误预算也是由双方共同使用，1减去SLO得到错误预算。
Q2:如何定义琐事（Toil）？
1、手动性
2、重复性
3、可以被自动化
4、战术性（突然）
5、没有持久价值 与服务同步线性增长
Q3: 为什么琐事越少越好？
1、琐事不加以控制会越来越多，保持每个SRE的工作时间中琐事比例低于50%。
2、琐事最大来源就是“中断性工作”，第29章就是“处理中断性工作"。
Q4: 琐事繁多是不是一定不好？
1、快速胜利感，降低压力，带来满足感，一定数量的琐事是不可避免的；
2、琐事繁多的危害：
2.1 职业停滞
2.2 士气低落
2.3 造成误解
2.4 进展缓慢
2.5 开创先例
2.6 促进摩擦产生
2.7 违反承诺
Q5：举例运维和开发共同使用错误预算的场景：
SRE中错误预算是运维和开发共同需要完成的目标，当错误预算剩余特别少时，可采用限制发布的方式：
1.“一刀切”的方式。比如有5个发布分别是12345，12相对来说发布风险以及中断的可能性很小，那么选择至发布12，345不发布；
2.“快/慢发布”。同样有5个发布分别是123445，可以选择先发布12，345延缓发布;
限制发布后开发团队反而会要求发布的代码质量，来满足双方制定的SLO &错误预算的要求，而不是运维单方面去支撑。
通过阅读《SRE：Google运维解密》，学友们可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢？在《SRE：Google运维解密》中，Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存的软件系统。通过阅读《SRE：Google运维解密》，读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。
任何一个想要创建、扩展大规模集成系统的人都应该阅读《SRE：Google运维解密》。《SRE：Google运维解密》针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。
