Table of Contents

Sometimes the Fix Is the Problem

有时候解决问题才是问题所在

如果更简单的系统故障更少，恢复速度更快，为什么事件审查如此注重增加修复，而不是删除组件和代码？当我们应该减少错误的表面积和提高操作员的可理解性时，我们却倾向于添加验证、健康性检查、流量转移和同步–所有这些都会增加复杂性。即使只是修复bug，最终也会增加额外的代码和复杂性。

复杂性通常被认为是可靠性的好处超过了未来事件的风险。归根结底，某些复杂性对于业务功能是必要的，正如某些复杂性对于可靠性是必要的一样。但是，我们有多少次专注于试图消除过度的复杂性呢?

事件回顾是确定和消除有害复杂性的绝佳机会。有时这可能是增加bug表面积的代码，有时可能是使系统更难理解并导致事件响应更慢的东西。在这两种情况下，如果我们能证明它促成了事件的发生，并且它对可靠性或业务功能没有必要，那么它就应该被认为是有害的复杂性并被删除。

事件给了我们缩小和注意有害复杂性的空间。如果一个bug导致了一个事件，我们可以扪心自问，系统的某些方面是否使测试变得困难或者难以注意到一个bug的存在。也许它就藏在一些并发的代码中。通过进一步缩小，我们可以询问：几乎总是复杂的并发代码提供的功能是否有必要。记住要问一些棘手的问题，比如并发性提供的性能优势是否真的是系统功能的需要。

同样，为了分析一个缓慢的事件响应，我们可以问一下系统中是否有什么东西让操作者感到困惑或误解。也许很难说出某项配置何时被动态更新。现在是时候问问这种复杂性提供的功能是否有必要。例如，能否在不牺牲功能的情况下将配置变成静态的？最重要的是，不要忘了考虑这种复杂性是否导致了过去的事件!

不完美的简单系统通常比复杂的系统要好。不变的数据结构允许程序员和操作人员避免跟踪状态变化，而且通常不会注意到性能上的影响。轮询的效率比基于推送的管道(pipelines)低，速度也慢，但可以避免困难的并发模式。维护一个零停机时间的系统所需的工具可能相当复杂，比常规维护窗口要复杂得多。动态配置可以是快速的、不费力的，但静态配置服务并强制重启是非常容易理解的。即使只是拥有较少的配置选项，操作员也更有可能更准确地猜测系统的当前状态。

每当我们为系统增加功能时，都会带来一些复杂性。然而，并非所有的复杂性都不利于可靠性。有些是必要的。因为我们并不能总是判断我们所增加的复杂性是否会妨碍我们未来的可靠性，所以事件回顾是讨论它所扮演的角色的最佳时机。最后，这总是一种权衡。但我保证，只要稍加搜索，你就会在下一次的事件回顾中发现很多有害的复杂性。

我们如何构建本书的结构

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系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢

翻译不易，转载时请注明原文链接，谢谢