97 Things Every SRE Should Know-25
Table of Contents
With Incident Response, Start Small
事件响应，从小事做起
你的事件响应计划很有可能看起来像下面这样。
- 有人被呼叫（可能是你！）。
- ???
- 修复
在许多情况下，这就是自己制定的计划。随着您的公司和系统的发展，包括操作人员的数量、服务人员的数量或其复杂性，该计划不再适合。作为SRE[1]或运维团队的一员，你可以留意以下一些迹象。
- 你不知道如何启动一个事件。
- 你不知道如何或何时让更多人参与进来。
- 你不知道是启动电话、会议桥还是使用聊天。
- 没有统一的方式通知那些可能受到事件影响的人。
- 在应对突发事件时，不清楚谁在做什么。
事故的本质是一个令人惊讶的事件，是一项认知上的困难任务。如果不能回答这些问题，就会给事件带来更多的不确定性，并可能付出难以置信的代价。响应者没有尝试直接调查和解决事件的谜团，而是试图通过弄清如何从头开始协调，而不是攻击问题。其结果是响应者注意力分散，停机时间延长。
采取措施改变这种模式可能很困难。可能会觉得找不到时间或空间来学习或制定新的计划，特别是如果最近发生了许多事件。幸运的是，可以从小事做起。如何从“凭感觉飞行”转变为“在框架内操作”呢? 采取一些小步骤，要理解的是，在处理复杂的，不可预测的事情时，计划无法说明所有内容。你永远不知道会发生什么样的事件，因为你无法预测未来，所以投资于事件响应框架有助于将焦点从许多需要在当下做出的小决定转移到事件本身的奥秘上。
在与各种组织中的许多团队合作后，我发现一个非常好的起点是以三种角色来思考：事件经理、专家/操作者和通讯员。如果你是被呼叫的那个人，在你回答的那一刻，你就戴上了所有这些帽子。每当你找不到人来填补这个角色，你就去填补。除了事件经理，你可以有任何数量的其他有意义的角色；通常，这只适用于专家/操作者的角色，但有些人喜欢把内部和外部沟通分开。
一旦你让其他人担任专家/操作者的角色，你的重点应该主要转移到跟踪正在发生的事情。要知道，这对一个人来说是一个很大的要求，尤其是当他们还在担任多个角色的时候。你会关注一些事情，比如谁在做什么，响应是否似乎卡住，以及谁可能因为疲劳而需要更换。
我承认，这种工作方式需要练习。我建议团队在不涉及太多技术的情况下一起练习，比如使用一些桌面练习。这也是你在值班(on call)时可以在心理上练习的东西。继续问自己：“我现在扮演的是什么角色？”
关于事件响应框架的最重要部分是它的存在。 它必须存在于一个人的头脑之外。 它必须以一种可以被他人看到和实践的形式存在。 很快，小的步骤将带来巨大的成果。
我们如何构建本书的结构
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系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢