Table of Contents

Optimize for MTTBTB (Mean Time to Back to Bed)

优化MTTBTB（回到床上的平均时间）

现在是半夜。你所选择的告警应用程序发出的响亮而独特的声音把你从睡梦中拽了出来，不久之后是一个电话，然后是一条信息：你不会想错过任何一个告警的！你会发现，你的工作并不轻松。

在被突然叫醒后做任何事情都不理想——头晕眼花，皮质醇水平飙升，甚至可能产生一些肾上腺素——更不用说在压力下调试复杂的系统了。然而，这就是许多人On-Call【1】的现实，因为很少有组织能够投资在所有团队中进行随日式的轮换，但运作的系统却需要24/7的可用性。

随着时间的推移，如果频率足够高，非工作时间的告警会成为压力和最终倦怠的来源。人力成本并非微不足道。解决办法的一部分是解决造成服务中断的原因，但我们必须承认，有些服务中断仍然会发生。了解到这一点，我们如何才能最好地支持值班人员，并减少持有告警机的心理和身体负担？

要考虑到用户进入一个没有多少初始上下文的情况。把一墙的文字（或评论）分解成单句的、简单的要点，看起来似乎有些过头了，但当你仍然处于睡梦中的时候，处理起来就容易多了(Breaking a wall of text (or comments) into single-sentence, simple bullet points may seem like overkill, but it is so much easier to process when still sleep-addled？？？？？)。清楚地标明任何棘手的、危险的或不可逆的步骤也有很大的作用。如果需要升级，提供一个明确的升级路径，包括联系细节和升级门槛。

第二，问，“这能让你更快回到床上(并待在那里)吗？” 这将重点放在缓解和退出标准上。在晚上，一个完整的全面的修复不应该是目标;相反，应该将重点放在缓解上，以便整个团队能够在第二天以更放松的眼光来看待它。

设置明确的期望值，说明什么时候事情被认为得到了缓解（但不一定是修复），并允许人们在他们认为安全的情况下尽快结束事件，这有助于减少值班人员盯着仪表盘不放和看管系统的倾向。提醒那些On-Call的人，熬夜是没有意义的——如果系统再此发生故障，无论如何他们都会再次被叫醒。

把这些联系在一起的是在白天练习的概念；第一次做某件事情的最糟糕的时间是在半夜，在事件发生时。如果我们不在紧急情况前检查事情，尽可能地消除问题，就会对值班人员（和我们自己）造成伤害。就像我们定期测试灭火器和烟雾警报器一样，我们也应该测试我们的工具和流程。

晚上被告警吵醒很糟糕，但看起来它不会很快消失，特别是考虑到我们可以通过小团队快速建立的系统的规模和复杂性。让人们思考人性的一面，可以帮助他们感同身受，并借鉴他们自己的经验。额外的好处是：如果它在凌晨3点对半睡半醒的人很有效，那么它对完全清醒的人可能会更有效。

我们如何构建本书的结构

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系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢

翻译不易，转载时请注明原文链接，谢谢

延伸阅读

1.on-call