小结
这一章反复重申的主题是：软件的简单性是可靠性的前提条件。当我们考虑如何简化一个给定的任务的每一步时，我们并不是在偷懒。相反，我们是在明确实际上要完成的任务是什么，以及如何更容易地做到。我们对新功能说“不”的时候，不是在限制创新，是在保持环境整洁，以免分心。这样我们可以持续关注创新，并且可以进行真正的工程工作。
[1]本节的一个早期版本出现在；login：的文章中（2015年8月，第40期，第4章）。
[2]被称为“bang/bang”控制，更多信息请参见https://en.wikipedia.org/wiki/Bang–bang control。
[3]在讨论SLA的大部分时候，实际上是在讨论SLO。如果某个人说道“违反SLA”，实际是指没有达到SLO，真实的“违反SLA”可能会触发一次违反合约的法律诉讼！
[4]如果SRE团队无法说服研发团队接受任何一个SLO，那么这个产品可能压根不需要SRE团队的支持。
[5]Failure Injection（参见文献[Ben12]）是另外一个方法，也可以用来调节用户的预期。
[6]我们使用Andy Grove 在 Intel首创的 Objectives and Key Results系统。
[7]Google 员工每周要写一个短小的无固定格式的工作总结，称为“Snippets”。
[9]有时候也称为“垃圾警报”，因为很少有人会去关注他们，这些警报也不会触发任何操作。
[10]如果1%的请求需要10倍的平均时间，这就意味着其他请求大概只需要平均值的一半。除非有统计延迟的分布情况证明，大多数请求都接近平均值这个假设一般是不成立的。
[11]关于警报过多的“狼来了”效应，请参见Applying Cardiac Alarm Management Techniques to Your OnCall（文献[Hol14]）。
[13]对于那些已经明确地理解自动化价值的读者，可以直接跳到本章后面的“自动化对Google SRE 的价值”一节。然而，请注意，我们的描述包含一些阅读本章其他部分可能有用的细微差别。
[14]在构建自动化系统的过程中获得的专业知识本身也有价值；工程师可以在构建自动化的过程中更深刻地理解现有流程，之后可以更快速地自动化新的流程。
[15]可观看XKCD动画：http://xkcd.com/1205/。
[16]参考例子，http://blog.engineyard.com/2014/pets-vs-cattle。
[17]当然，不是每个需要管理的系统都提供了可调用管理API——这要求我们必须采用某种工具，例如执行CLI，或者执行自动化的网站单击。
[20]具体细节请参看https://en.wikipedia.org/wiki/Air_France_Flight_447。
[22]这是定期演习的另外一个不错的理由；参看第28章的“故障处理分角色演习”一节。
[23]Google的全部源代码存放于一个单独的代码仓库中（参见文献[Pot16]）。
[24]Blaze的开源版本为Bazel，可参见网站上的“Bazel Faq”,http://bazel.io/faq.html。
[25]一般来说，复杂系统都是这样的，可参见文献[Per99]和[Coo00]。