Table of Contents

Complex: The Most Overloaded Word in Technology

复杂：技术中最超负荷的词汇

软件工程师和系统工程师都把 “复杂” 这个词作为一个特定的艺术术语。软件工程师在几个方面使用它，区别于系统的含义。软件工程师和系统工程师（SRE【1】、生产工程师、系统管理员、DevOps从业者等）是重叠在一起工作的群体。我们都需要了解在任何特定的时间使用的意思，以便我们能清楚地交流。

然而，这并没有告诉我们软件工程师的复杂性是什么意思。从根本上说，复杂性是指那些使软件难以完全理解和正确推理的东西。Moseley和Marks的论文《Out of the Tar Pit》讨论了复杂性的几个来源。最大的，也是最难处理的，是状态。状态影响着程序的控制流，但一个软件可能处于的潜在状态的数量随着变量数量的增加而呈指数级增长。

复杂性的其他主要来源是纯粹的代码量，以及程序与复杂的物理结构不同，不能被视觉检查的事实。程序的心理模型必须从源代码中构建。当然，这可能更容易或更难，取决于代码的结构。

系统工程师往往对复杂性有一个完全不同的想法，源于系统理论。复杂系统具有特殊的特征：多个相互作用的部分，系统状态（即某种记忆），以及反馈回路。它们显示出突发现象，具有非线性关系（一个部分的小变化会导致整个系统行为的大偏差），并倾向于容易出现连带故障或恶性循环。复杂系统的行为无法被可靠地预测。

所有计算系统都是复杂系统。即使一个系统运行在一台单独的物理机器上，你仍然在处理多个软件的相互作用，所有这些软件本身就可能是复杂的系统，运行在复杂的硬件上。每个正在运行的程序可能有多个控制线程、状态、与操作系统和其他程序的互动–即使不是明确的，也是通过共享资源。

这种系统理论对复杂性的定义是系统管理员、SRE和DevOps从业者经常使用的。另一方面，软件工程师主要从代码结构、模块之间的相互作用和代码库中的相互依赖性来考虑。软件工程师的主要关注点是在不引入错误的情况下进行正确的修改的难度。系统工程师最关心的是生产中部署的软件的稳定性。

这就是为什么，当你要求软件工程师把促进简单性作为他们工作描述的一部分时，他们会寻找机会来分离关注点，减少代码库中的耦合性，以重构众所周知的设计模式，在模块之间创建更好的定义的交互，并删除未使用的代码。当你要求系统工程师做同样的事情时，他们通常会寻找方法来控制系统的极端行为（例如，使用负载削减和断路器）或使系统的元素更加统一。

我们在这里讨论的两种复杂性是完全不同的，但它们确实也有一个主要的共同点：软件复杂性和系统复杂性都使理解和预测行为的任务变得不可能。

我们如何构建本书的结构

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

2.Fred Brooks
Brooks, F. P. “No Silver Bullet.” Essence and Accident in Software Engineering. Proc. IFIP Tenth World Computing Conference, (1986), 1069–1076.