如果用一个词语来描述 Google 的历史，那就是不断地"扩大规模"（scaling up）。Google的成长经历，是计算机行业中数一数二的成功故事，标志着整个社会向 IT 为中心的商业模式的转变。Google 很早就开始实践 IT 与商业模式的结合，也是向社区推广DevOps 理念的先行者。本书就是由来自公司各个部门，切身参与甚至主导了整个行业转型实践的人写成的。

Google 是在一个系统运维工程师行业转型的阶段发展壮大的。Google 的发展史就像是对传统的系统运维理念发出的革命宣言∶我们无法按照传统方式运维 Google 系统，必须要思考一种新的模式，但是同时我们也没有时间等待其他人验证和支持我们的理论。在Principles of Network and System Administration（参见文献【bur99】）一书的介绍中，我提出了一种观点∶系统运维本质上是人与计算机共同参与的一项系统性工程。当时的一些评论者对这种观点表示了强烈的反对∶"这个行业还远远没有成熟到可以称为一项工程"。在那时，我甚至对整个运维行业产生了怀疑，认为这个行业在个人英雄主义与神秘色彩中已经永久地迷失了自己，无法前进。但是，这时 Google 诞生了，Google 的高速发展将我的预言变成了现实。我之前的定义变成了一个具体的词语∶SRE，站点可靠性工程师。我的几个朋友切身参与了这个新职业的创立，用软件工程理念和自动化工具定义了这个行业。一开始，他们显得很神秘，Google 公司内的体验和整个行业也格格不入，Google 太特殊了! 随着时间的推移，公司内外交流逐渐增多。这本书的目标就是将 SRE 的一些思考和实践带给整个行业，以促进交流。

在本书中，我们不仅仅展示了 Google 是如何建设维护其富有传奇色彩的大型计算集群的。更重要的是，我们展示了在建设过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。IT 行业大多自我封闭，交流过少，很多从业人员都或多或少地受教条主义的限制。如果Google 工程师团队能克服这个惯性，保持开放的精神，那么我们也能够一起和他们面对 IT 行业内最尖端的挑战。

这本书由一群有共同目标的 Google 工程师写就的短文组成。本书的作者们聚集在同一个公司旗下，为了同一个目标努力，本身就是一件很特别的事情。在本书的各个章节之间经常能看到软件系统的共同点，以及工作模式上的共通之处。我们经常可以从多个角度分析不同的决策选择，了解他们是如何一起解决公司内部多种利益冲突的。这些文章并不是严谨的学术研究论文，而是这些人的切身经历。虽然本书的作者们有着不同的工作目标、写作风格，以及技术背景，但是他们都尝试着去真诚地描述自己遇到的问题和解决的经历。这和 IT 行业内的普遍文风截然不同，风格迥异。有些作者会宣称∶"不要做A，只有做B才是正确的。"另一些作者会更谨慎，行文更富有哲学性。这其实恰恰代表了整个 IT 行业内不同个性融合的现状。而我们作为读者，作为观察者，并不了解整个Google 的历史，也没有参与到具体的决策过程中，无法全面了解当事人所面临的纠缠不清的挑战，只能带着谦逊的态度远远旁观。在阅读本书的过程中，相信读者一定会产生出许多疑问∶"他们当时为什么没有选择X?""如果他们选择了Y，结果会是怎样?""如果多年之后回头再看，这个选择会是正确的吗?"这些问题，恰恰是阅读本书的最大收获，│因为我们第一次有机会将自己的经历、选择和本书陈列的决策逻辑相互对应，从中发现不足和缺陷。

这本书的成书过程也堪称奇迹。今天，我们能感受到整个行业都在鼓吹厚颜无耻的"代码拿来主义"（just show me the code）。开源软件社区内部正在形成一种"不要问我问题"的风气，过于强调平等却忽略领域专家的意见。Google 是行业内为数不多的，愿意投入精英力量钻研本质问题的公司，而且这些公司精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件，用来链接日益庞杂的软件、人和海量的数据。这本书中没有万能药，没有什么东西能解决一切问题，但是这恰恰是本书的宗旨∶相比最后的软件结果、架构设计而言，真实的设计过程、作者本身的思考经历更有价值。实现细节永远只是短暂存在的，但是文档化的设计过程却是无价之宝。有机会了解到这些设计的内幕真是太难得了!

这本书，归根到底，记录了 Google 这个公司的成长经历。书中的很多故事都是由相互重叠的故事组成的，这恰恰说明了扩展一个计算机系统，要比简单按照书本上的标准架构放大困难得多。一个公司的成长，意味着整个公司商业模式和工作模式的扩展，而不是简单的资源扩张。仅此一点，这本书就物超所值了。

自省，是一个在 IT 行业内部并不流行的词语。我们不断重复发明各种系统。很多年以来，只有 USENIXLISA大会IT运维管理社区以及其他几个专注于操作系统的会议会讨论一些 IT 基础设施的设计和实现。很多年后的今天，IT行业已经天翻地覆，但是本书仍然弥足珍贵∶它详细记录了Google 迈过分水岭时期的全过程。很显然，这些经历没有办法完全复制，也许只能被模仿，但是却可以启发读者，指引未来。本书作者们表现出了极大的真诚，显示了谦逊的风格，以及极强的凝聚力、领导力。这些文章记录了作者们的希望、担忧、成功与失败的经历。我向这些作者们和编者们的勇气致敬，正是这种坦率，让我们能够作为旁观者和后来人，从前人的经历中学习到最宝贵的知识。

Mark Burgess
In Search of Certainty 一书作者
Oslo，2016年3月

如果用一个词语来描述 Google 的历史，那就是不断地"扩大规模"（scaling up）。Google的成长经历，是计算机行业中数一数二的成功故事，标志着整个社会向 IT 为中心的商业模式的转变。Google 很早就开始实践 IT 与商业模式的结合，也是向社区推广DevOps 理念的先行者。本书就是由来自公司各个部门，切身参与甚至主导了整个行业转型实践的人写成的。

Google 是在一个系统运维工程师行业转型的阶段发展壮大的。Google 的发展史就像是对传统的系统运维理念发出的革命宣言∶我们无法按照传统方式运维 Google 系统，必须要思考一种新的模式，但是同时我们也没有时间等待其他人验证和支持我们的理论。在Principles of Network and System Administration（参见文献【bur99】）一书的介绍中，我提出了一种观点∶系统运维本质上是人与计算机共同参与的一项系统性工程。当时的一些评论者对这种观点表示了强烈的反对∶"这个行业还远远没有成熟到可以称为一项工程"。在那时，我甚至对整个运维行业产生了怀疑，认为这个行业在个人英雄主义与神秘色彩中已经永久地迷失了自己，无法前进。但是，这时 Google 诞生了，Google 的高速发展将我的预言变成了现实。我之前的定义变成了一个具体的词语∶SRE，站点可靠性工程师。我的几个朋友切身参与了这个新职业的创立，用软件工程理念和自动化工具定义了这个行业。一开始，他们显得很神秘，Google 公司内的体验和整个行业也格格不入，Google 太特殊了! 随着时间的推移，公司内外交流逐渐增多。这本书的目标就是将 SRE 的一些思考和实践带给整个行业，以促进交流。

在本书中，我们不仅仅展示了 Google 是如何建设维护其富有传奇色彩的大型计算集群的。更重要的是，我们展示了在建设过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。IT 行业大多自我封闭，交流过少，很多从业人员都或多或少地受教条主义的限制。如果Google 工程师团队能克服这个惯性，保持开放的精神，那么我们也能够一起和他们面对 IT 行业内最尖端的挑战。

这本书由一群有共同目标的 Google 工程师写就的短文组成。本书的作者们聚集在同一个公司旗下，为了同一个目标努力，本身就是一件很特别的事情。在本书的各个章节之间经常能看到软件系统的共同点，以及工作模式上的共通之处。我们经常可以从多个角度分析不同的决策选择，了解他们是如何一起解决公司内部多种利益冲突的。这些文章并不是严谨的学术研究论文，而是这些人的切身经历。虽然本书的作者们有着不同的工作目标、写作风格，以及技术背景，但是他们都尝试着去真诚地描述自己遇到的问题和解决的经历。这和 IT 行业内的普遍文风截然不同，风格迥异。有些作者会宣称∶"不要做A，只有做B才是正确的。"另一些作者会更谨慎，行文更富有哲学性。这其实恰恰代表了整个 IT 行业内不同个性融合的现状。而我们作为读者，作为观察者，并不了解整个Google 的历史，也没有参与到具体的决策过程中，无法全面了解当事人所面临的纠缠不清的挑战，只能带着谦逊的态度远远旁观。在阅读本书的过程中，相信读者一定会产生出许多疑问∶"他们当时为什么没有选择X?""如果他们选择了Y，结果会是怎样?""如果多年之后回头再看，这个选择会是正确的吗?"这些问题，恰恰是阅读本书的最大收获，│因为我们第一次有机会将自己的经历、选择和本书陈列的决策逻辑相互对应，从中发现不足和缺陷。

这本书的成书过程也堪称奇迹。今天，我们能感受到整个行业都在鼓吹厚颜无耻的"代码拿来主义"（just show me the code）。开源软件社区内部正在形成一种"不要问我问题"的风气，过于强调平等却忽略领域专家的意见。Google 是行业内为数不多的，愿意投入精英力量钻研本质问题的公司，而且这些公司精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件，用来链接日益庞杂的软件、人和海量的数据。这本书中没有万能药，没有什么东西能解决一切问题，但是这恰恰是本书的宗旨∶相比最后的软件结果、架构设计而言，真实的设计过程、作者本身的思考经历更有价值。实现细节永远只是短暂存在的，但是文档化的设计过程却是无价之宝。有机会了解到这些设计的内幕真是太难得了!

这本书，归根到底，记录了 Google 这个公司的成长经历。书中的很多故事都是由相互重叠的故事组成的，这恰恰说明了扩展一个计算机系统，要比简单按照书本上的标准架构放大困难得多。一个公司的成长，意味着整个公司商业模式和工作模式的扩展，而不是简单的资源扩张。仅此一点，这本书就物超所值了。

自省，是一个在 IT 行业内部并不流行的词语。我们不断重复发明各种系统。很多年以来，只有 USENIXLISA大会IT运维管理社区以及其他几个专注于操作系统的会议会讨论一些 IT 基础设施的设计和实现。很多年后的今天，IT行业已经天翻地覆，但是本书仍然弥足珍贵∶它详细记录了Google 迈过分水岭时期的全过程。很显然，这些经历没有办法完全复制，也许只能被模仿，但是却可以启发读者，指引未来。本书作者们表现出了极大的真诚，显示了谦逊的风格，以及极强的凝聚力、领导力。这些文章记录了作者们的希望、担忧、成功与失败的经历。我向这些作者们和编者们的勇气致敬，正是这种坦率，让我们能够作为旁观者和后来人，从前人的经历中学习到最宝贵的知识。

Mark Burgess
In Search of Certainty 一书作者
Oslo，2016年3月