Table of Contents

You Don’t Know for Sure Until It Runs in Production

在生产环境中运行之前，你无法确定。

在生产环境中测试的想法通常会有两种反应。有时，你会得到热情的赞美。其他时候，你可能会得到震惊的、不赞成的目光。

是什么解释了这种分歧？这是工程中最有趣的悖论之一。我们经常把生产环境看成是像纸牌屋一样的脆弱的生态系统，需要小心翼翼地对待，戴上丝绸手套，或用掩体装备。同时，我们梦想着可观察的系统和平静的、没有告警的夜晚。

剧透一下，你不可能两全其美。那么，我们如何弥补这一差距呢？

首先，我们必须正视这样一个神话：在任何情况下，bug都不应该出现在生产环境中。把已发布的代码看作是一个实验的想法在某种程度上意味着它没有完成，或者说是不合格的，而且在交付时进行迭代在某种程度上是不好的。

你可能会觉得由于缺乏良好的工具，无法在生产环境中进行测试。最勇敢的组织试图在内部构建工具，如果没有一个统一的运行生产实验的标准，这通常意味着在专题工作会议之间剩下一点时间内把一些Bash脚本拼凑起来，或者，更糟糕的是，把它变成一个“运维问题”。

然而，这远不是一个全有或全无的方法，它是可以从根本上改变开发者体验的一些小事情的集合，其中一些你可能已经在做了!

带有功能切换[1]，允许在不改变代码的情况下修改系统行为。

有一些工具可以安全地访问生产数据，或者从命令行与应用程序交互。不管你喜欢还是讨厌Rails，控制台对于调试来说是非常棒的，许多框架和语言都可以从这本书中学习。

有一些库可以通过在运行新的代码路径的同时运行旧的代码路径，比较结果甚至性能，来帮助重构和迁移遗留系统。

还有就是可观察性，或者说严重依赖事件和分布式跟踪，而不是传统的固定指标。换句话说，利用代码来制作一个关于系统的故事，而不是提供固定的信息，并让它回答动态的、复杂的问题。

然而，这不仅仅是关于工具的问题；这也是一个开始将初始生产代码视为实验的机会。把它想成是第一个测试你的煎锅温度是否合适的薄饼。你可以随时为下一次调整。想象一下思维方式的转变，我们将进行观察并得出结论，以更好地了解我们的系统在现实环境中的工作方式以及大规模变更的影响。它涉及到在较小的迭代中交付，这增加了尽早发现真正糟糕的边缘情况的可能性，并快速地减轻它们，使生产环境变得不那么可怕和不可改变的。

通过为你的系统和你刚刚做出的改变提供急需的信心，生产转变为一种创造性和信任的途径。这也意味着晚上可以睡得更好，因为你知道你的代码遇到未知的错误的风险更低，而这些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.feature flaging

特性切换或称功能切换，英语：feature toggle[1]、feature switch、feature flag、feature flipper或conditional feature等。它是软件开发中的一种技术，是替代维护多个源代码分支（也称特性分支）的一种方案，这使特性在完成并正式发布前也可以得到测试。特性切换是在运行期间隐藏、启用或禁用特定功能。例如在开发过程中，开发人员可以启用功能以进行测试，而其他用户不会被启用该功能和受到它的影响。[2]

持续发布和持续交付为开发人员提供了有关其代码的快速反馈，而这要求尽早地集成其代码更改。特性分支为此过程引入了一个旁路。[3]特性切换是实现持续交付的一项重要技术。

这种技术使开发人员得以发布包含未完成功能的产品版本。这些未完成的功能被隐藏或被禁用，因此不会出现在用户界面中。这使软件可以发布很多次小的增量版本，而无需承担不断分支与合并的成本。特性切换使软件集成的周期得以更短。[4]项目团队可以使用特性切换来加速开发过程，因为产品中可以包含默认不启用的未完成代码。