Table of Contents

Move Fast to Unbreak Things

快速行动以打破困境

作为SRE[1]，我们认为我们的工作是平衡速度和可靠性。我们知道部署到生产环境中的每个更改，无论是代码还是配置，都有一定的风险，会导致服务中断或其他服务降级。当故障发生时，我们的直接反应是更加谨慎，放慢生产变化的速度。

然后事情还是发生了。尽管我们做出了努力，但仍然有中断。我们的直觉是错误的。现在事情更有可能发生故障，正是因为我们放慢了速度。当一架飞机在半空中失速时，自然反应可能是拉起，拉离地面。正确的答案是将飞机的机头朝下，增加发动机的动力。这就产生了升力。有时，正确的做法与我们的直觉所告诉我们的相反。

你的开发组织是一个水龙头。它以某种恒定的速度产生变化(无论是功能开发、bug还是架构工作)。另外，这些变化进入生产的速度也是一样的。生产流速率由你的部署节奏、质量保证过程的速度、任何批准要求等等决定。

如果你放慢了这个节奏，不管是通过明确的冻结，还是通过增加审查、人工检查或变更批准程序来隐含地放慢，会发生什么？你会积累更多的积压变更，等待部署。生产环境看起来越来越不象你的测试环境。每一个额外的变化都会增加出错的几率。

随着风险的增加，不可避免地，你部署的时候还是会出问题。你会怎么做？第一个明显的答案是回滚。这是一个很好的答案。然而，如果您已经为一批更改进行了部署，你必须回滚所有的变更：bug修复，功能，和所有的更改。其中一些与bug一起部署的变更可能是你的用户的关键需求。

假设你没有回滚，你可以减轻紧迫的关注，然后要解决这个问题。这个修复现在需要通过所有的测试、审查和你引入的控制，从而延迟了缓解措施。

一旦来自开发组织的变更流与进入生产的变更流相匹配，系统的心理模型和实际系统之间的差距就会缩小。事情变得更容易发现和修复。

可靠性的关键是使系统迅速改善的能力。任何减缓变化的东西都会减缓你做这件事的能力。

我们如何构建本书的结构

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-english