97 Things Every SRE Should Know-97
Table of Contents
Incidents: A Window into Gaps
事故：了解差距的窗口
事故迫使我们面对现实，即我们的系统并不总是像我们所期望的那样表现。这是一种不舒服的感觉，我们希望有信心，这种情况不会再发生。为了在事故发生后重拾这种信心，我们努力确定系统损坏的原因，但我们可以从事故中学到更多，而不仅仅是如何防止重蹈覆辙。我们可以找出组织内部存在的一系列差距——我们可以潜在地解决这些差距。
我们可以识别的一种差距是工具差距，当我们看到工程师在使用操作工具时遇到困难。例如，当工程师在事故中努力理解工具的反馈时，或者当他们在使用工具进行生产变更时出错时，我们可以识别出来。特别是，每当我们注意到一个变通方法，有人以错误的方式执行一项任务，这就是存在工具差距的线索。关于工具差距的信息应该被反馈给这些操作工具的所有者。
另一种差距是业务专长差距。这是指工程师缺少有效完成工作所需的重要操作技能。也许仪表盘上的某张图总是错的，因为创建它的工程师并不完全了解指标查询语言。直到事件发生后，才有人注意到。由于我们的系统在不断地发生变化，操作上的专业知识差距会随着时间的推移而形成。你在配置自动扩缩容时使用的策略可能是去年推荐的方法，但现在已经过时了。
最后，当一个团队没有足够的资源来处理他们的工作量时，就会出现资源缺口。担心资源缺口有两个原因。一个是延伸系统定律:每个系统最终都会被推到它的极限。想象一个正在满负荷运行的独立团队，并接收了额外的员工。当他们雇佣新员工时，他们会有一些空闲时间。然而，不可避免的是，团队将继续承担更多的工作，直到他们再次满负荷运行。
资源缺口的另一个挑战是流畅性法则。这是一种现象，当一个熟练的工程师可以优雅地处理一些超负荷的工作时，他们没有任何迹象表明他们正在超负荷工作（“我做得很好！”），直到他们完全不堪重负。当工程师感到需要在不同的任务之间切换以完成所有的工作时，你就可以看到流畅性法则的作用，例如监控一个复杂的部署，回应内部支持请求，以及做开发工作。这种超负荷的工作既增加了错误的风险，也增加了团队倦怠(burnout)【1】的风险。倦怠会导致团队成员离开，进一步增加团队的负担。我们越早发现一个有超负荷风险的团队，组织解决这个问题的成本就越低。
一个组织内部的每个人对整个系统的运作方式只有部分了解。每当事件发生时，我们就有机会了解事件所暴露的差距。通过强调这些差距，我们可以开始为未来做准备。
我们如何构建本书的结构
SRE虽然涉及复杂的技术系统，但归根结底是一种文化实践。文化是人的产物，这启发我们根据你在组织中的SRE数量来组织本书的各个部分–你具体处理什么，你的一天是怎样的，取决于有多少个SRE工程师。我们将本书的文章分为 “SRE新手” 、0-1个SRE、1-10个SRE、10-100个SRE和 “SRE的未来 ”。
读者如果想找寻先从哪里开始的指导，可以直接跳到最适用于自己的部分；但是，你仍然会发现阅读那些目前并不适用于你日常的部分的文章的价值。
在0到1个SRE时，还没有人被指定为SRE，或者你已经找到了你的第一个SRE，这个角色看起来几乎是孤独的。
在1到10名SRE时，你正在组建一个团队，有知识共享和分工的能力。
在10到100个SRE时，你已经成为一个组织，你需要思考的不仅仅是你所从事的系统，还需要思考如何组织这么多SRE。
“SRE新手” 涵盖了基础性的话题（尽管并不详尽！），对于那些刚刚开始SRE之旅的人来说是很有帮助的，即使是最有经验的SRE，也是一种复习。 “SRE的未来” 包含了一些文章，这些文章探讨了SRE潜在的发展方向，或者是（目前）坐拥时代潮流。
没有必要按照任何特定的顺序阅读本书。你可以从头到尾读一遍。或者，如果你对某个特定的主题感到好奇，可以翻到索引，在那里你可以找到关于该主题的所有文章。把它作为参考指南，或者是灵感的来源–可以在需要的时候提供一个震撼。或者，也许可以建立一个阅读俱乐部，每周一次挑选一篇文章与同事讨论。这就是散文集的魅力所在。我们希望你和我们一样喜欢阅读它们。
结语
SRE系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢
翻译不易，转载时请注明原文链接，谢谢