Table of Contents

Test Your Disaster Plan

测试你的灾难计划

系统失败。这很好。网站可靠性是一门专门从事预测和减轻故障的学科。我们建立可观察、可反省、可恢复的系统，限制故障的爆炸半径。我们为失败而设计。

失败规划通常包括后备计划、通过我们的代码的替代路径，以及当我们的常规机制失败时我们将使用的系统或流程。例如，一个客户可能会重试一个失败的请求，希望下次能找到一个更健康的副本。一个领导者选举的系统可能会把领导权从一个没有反应的服务器上移开。后备计划有时涉及到人类；每当我们呼唤一个值班人员【1】或采取一些行动来应对故障时，我们都在执行一个后备计划。

我们的常规途径一直在使用。我们知道它们在工作，当它们失败时我们也会注意到。我们的许多后备计划也是运行良好的，运行如此频繁，以至于我们会发现它们是否有问题。那么，那些不常运行的路径呢？如果我们只在紧急情况下使用它们，我们可能不会发现它们不工作，直到我们真的需要它们。

这个问题的一个极端说明是一个行业的经典：缓慢腐烂的灾难恢复站点。一个团队预计他们的主站点会发生大规模故障，并在另一个地区或另一个数据中心建立了一个系统的副本。他们配置他们的部署管道以推送到两个区域，设置数据复制，并称其为良好——直到灾难来袭，第一次需要故障转移区域。现在，在凌晨3点，在所有人员的努力下，团队发现了指向旧区域的硬编码DNS名称、被遗忘的密码、被注释的复制策略，以及过于临时的修复，无法复制到DR（灾难恢复）站点，当然，这些修复现在是重要的基础设施。

我们需要在我们还能修复它们的时候发现这些问题。这意味着测试我们的后备计划。这些测试中有些是模拟的。许多组织开展游戏日，当他们练习应对典型的灾难场景时，有时会用测试数据重现这些场景。团队可以通过当地的 “不幸之轮 “演习来测试自己的反应，对可能发生的故障进行详细的角色扮演，这样团队就必须去寻找真正的日志、图表、配置，甚至是同事的电话号码——他们在真实事件中可能需要的一切。

灾难的角色扮演可以帮助我们发现计划中不起作用的部分，或者我们不太理解的部分。他们也能建立肌肉记忆，减少恐慌。想想建筑消防演习是如何训练我们平静地走到会议区而不惊慌失措的。

模拟灾难是有帮助的，但如果我们能使回退计划成为我们正常操作的一部分，那就更好了。当你第一次故障转移到DR（灾难恢复）站点时，故意绕过你的缓存，或者用防火墙关闭一个服务的副本来测试其冗余度。这将是非常可怕的。你可能会破坏一些东西。但是破坏的最好时机是在你观察它的时候，并且可以快速回滚。每次都会变得容易一些。

与所有的可靠性一样，测试回退计划的优先级应该与它对企业的重要性成正比。如果失败的最坏结果是一些团队需要做额外的工作，也许这是一个可以接受的风险。如果后备计划是你和你的业务结束之间的唯一障碍，那就要非常认真地对待它。

灾难计划只有在发挥作用时才能保证你的安全。确定你的后备计划，并进行试验。确保它们在你需要的时候已经准备好了。

我们如何构建本书的结构

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