Table of Contents

Why I Hate Our Playbooks

为什么我讨厌我们的运行手册

SRE[1]中的剧本（也称为运行手册）是文档的集合，旨在帮助on-call[2]人员解决问题。有许多风格的运行手册，但我遇到的大多数都有相同的反模式。

首先，它们可能包含太多的细节，使它们难以维护和创建大型文档，从而使查找特定信息变得复杂。这通常是由于害怕遗漏任何东西而造成的。这种运行手册的例子是那些在on-call的所有权转移过程中写的，或作为on-call的人的连续日志。

假设任何运行手册是绝对完整的是不可行的，所以重要的是期望它成为一个工具，不能填补SRE的全部角色。团队入职培训所涵盖的内容是有用的基准，可作为假定知识的基础而将其详细程度排除在外。它还有助于替换细节，比如如何找到一个工作的链接，以加快数据搜索，而不需要回忆无数的小事实。一个需要考虑的特殊情况是为基础设施服务的用户和客户编写的运行手册，而不是为服务所有者编写的运行手册，因为后者需要非常不同程度的背景知识。注意事项和不直观的含义很容易对用户造成意外伤害。

如果细节太少，可能会发生相反的情况。对文档的善意需求，但是没有动机花费时间使其有用，导致空模板。太少的细节实际上比能够看到没有文档存在浪费更多的时间，所以提交时需要最低限度的可行性。在最好的情况下，一个空文档充其量是没有用的，但在最坏的情况下，它可能会形成一种忽略运行手册的模式(即使它们已经更新)，因为调用者已经内部认为它们没有用。

这听起来有悖常理，但运行手册不应该由该主题的专家编写。对于非常熟悉一个系统的人来说，通常很难识别只有他们知道的背景和微妙之处，所以他们更适合成为信息来源和审查者。

最后一个反模式是过于规范化。任何可以描述解决具体情况的确切步骤的运行手册都应该是一个自动化的脚本。一个告警应该意味着系统不能自我修复，因为自动化比人类在完全枚举的重复性任务方面要快得多、好得多。我们将复杂的反应升级给人类，而不是快速反应。

如果on-call人员习惯于遵循一个脚本行事，新奇的事件也变得非常难以处理，这是一个问题，因为他们是SRE的理想环境，在我们持续的任务中，将自己的工作自动化了。重要的是要认识到，运行手册有一个生命周期：

┌->  1 Identify issue  
|    2 Debug  
|    3 Add alerts  
|    4 Write documentation  
|┌>  5 Automate resolution  
|└-  6 Update documentation  
└--- 7 Have a different problem

我们经常被卡在第4项上。规范性的运行手册并不是应该被删除的失败品(Prescriptive playbooks aren’t a failure that should be deleted)，而是一个自动化和迭代的机会。

我们如何构建本书的结构

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.Site Reliability Engineering-中文
   Site Reliability Engineering-英文

2.on-call