软件工程有的时候和养孩子类似∶虽然生育的过程是痛苦和困难的，但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是，传统软件工程专业花费了很多精力讨论软件的开发过程，而不是其后的维护过程。有统计显示，一个软件系统的40%~90% 的花销其实是花在开发建设完成之后不断维护过程中的。行业内流行的一个说法是∶一个系统如果已经开发完成，部署在生产环境上，那么它就是"稳定的"，就不需要那么多工程师花费精力去优化、维护。我们认为这个说法是错误的。从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。这样一种职业必须具备非常广泛的技能，但是和其他职业的专注点都不同。Google 将这个职位称为站点可靠性工程师（SRE，Site Reliability Engineering）。

那么，站点可靠性工程师究竟代表着什么呢?的确，这个词语并不能够特别清晰地描述这个职位的意义。基本上每个 Google SRE 都会被经常问到这个职位到底代表什么意思，以及他们的日常工作究竟是什么。

将这个词语展开来说∶首先，也是最重要的一点，SRE 是工程师（engineer）。SRE 使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统。有的时候，SRE 和产品研发团队共同工作，其他时候我们需要开发这些系统的额外组件∶例如备份系统和负载均衡系统等。理想情况下，同时推进这些组件在多个项目中复用。还有的时候，我们的任务是想出各种各样的办法用现有组件解决新的问题。

其次，SRE的关注焦点在于可靠性。Ben Treynor Sloss，Google负责7×24运维的副总裁，SRE 名称的发明者，宣称可靠性应该是任何产品设计中最基本的概念∶任何一个系统如果没有人能够稳定地使用，就没有存在的意义。因为可靠性是如此重要，因此 SRE专注于对其负责的软件系统架构设计、运维流程的不断优化，让这些大型软件系统运行得更可靠，扩展性更好，能更有效地利用资源。但是，SRE并不是无止境地追求完美∶当一个系统已经"足够可靠"的时候，SRE 通常将精力转而投入到研发新的功能和创造新的产品中。

最后，SRE 的主要工作是运维在分布式集群管理系统上运行的具体业务服务（service）。不论是遍布全球的存储服务，还是亿万用户赖以工作的 E-mail 服务，还是 Google 最初的 Web搜索服务。SRE 中的"S"最开始指代的就是 google.com的运维服务，因为 SRE 的第一个工作就是维持网站的正常运转。随着时间的推移，SRE 逐渐接管了Google 内部绝大部分产品系统，包括 Google Cloud Platform 这类开发者平台，也包括内部的一些非网站类的基础设施系统，例如 Bigtable。

虽然我们在这里将 SRE 的职位定义得比较宽泛，但是在这样一个互联网业务高速发展的时代，这个职位的出现毫不奇怪。同样，虽然在应用系统运营维护的过程中有数不清的重要环节需要关注，我们最关注的是"可靠性"这一点也不奇怪。在 Web 服务领域里，对服务器端软件的优化和修改是相对可控的，变更管理与生产安全又结合得非常紧密，一种类似于 SRE 的职业早晚会在这个环境下诞生。

虽然 SRE 这个行业是在 Google 内部，从Web 社区中诞生的，但我们认为这个职业对其他团队和组织也有很多值得借鉴的地方。本书是对阐述SRE 发展过程的一次尝试∶我们既希望将这些宝贵经验共享给其他相关行业，也希望能从其他行业中汲取知识，从而更好地定义各种角色和术语。为了这个目的，本书将通用的理论、设计理念和思想，与实际的应用工具介绍等分开。在某些需要结合 Google内部信息讨论主题的时候，我们相信读者可以进行类比，将书中的理念与自己的实际环境相结合，以便得出更为有效的结论。

本书中也包含了一些对 Google 内部生产环境的介绍，将 Google 内部环境与外部常见的开源类软件相对应。这样可以让本书的一些设计理念与实践的结合度更强，应用起来更容易。

最后，我们当然希望社区内出现更多、更可靠的软件系统。我们知道，创业企业甚至中型企业经常对如何应用这些理念和技术感到困惑。可靠性就像安全性，越早关注越好。这就意味着一些小型创业公司，在应付日常面临的种种挑战时，也应该抽出一部分精力来面对可靠性这个话题。这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多。本书第4部分着重介绍了 SRE 团队如何进行内部培训、如何加强内部沟通等最佳实践，很多都可以直接拿来应用。

对中型企业来说，企业内部可能已经有这样的一组人在做着与SRE非常类似的工作。这些人可能并不叫 SRE 这个名字，甚至可能没有受到管理层的重视。在这样的企业中，提高可靠性最好的办法往往就是去认可这些人的工作，并配备足够的激励机制。在牛顿被世界正式认可为物理学家之前，他经常被称作是最后的炼金术师。而这些专注于可靠性的工程师们，正如当年的牛顿一样，是一个新时代的开拓者。

如果一定要为 SRE 寻找一个起源的话，谁才能够被称为世界上第一个 SRE呢?

我们选择了Margaret Hamilton，MIT 教授，参与了阿波罗登月计划的软件开发工作。她的工作具有现代 SRE的一切特性。用她自己的话来讲∶"团队文化就是从一切经历中不断学习，包括来自那些我们最意想不到的地方的经历。"

在Apollo7飞船研发期间的某一天，Margaret 带着她的小女儿 Lauren 一起来到公司。在 Margaret 忙着和组员们在大型计算机上运行飞行模拟测试的时候，她的小女儿偷偷地按下了控制台上的 DSKY 键。整个模拟程序出乎意料地崩溃了，导致整个火箭发射程序意外终止。Margaret和组员调试后发现，原来Lauren 意外触发了PO1 这段子程序的执行，导致了整个模拟过程的失败。（该子程序是起飞前调试程序，执行时会删除现存的导航信息，如果在火箭飞行过程中执行这段程序，计算机将无法继续维持火箭航线，后果将是灾难性的。）

凭借着 SRE 的直觉，Margaret 为项目组提交了一个软件改动，申请在飞行程序中增加一项特殊状态检查，以避免飞行员在飞行过程中意外触发 PO1 程序的执行。但不幸的是，NASA管理层认为，这项错误发生的可能性太小，根本不值得为此添加这项修改。于是Margaret 没有能够成功提交这项软件修改。她只能在火箭飞行手册中添加了一段文字，写道∶"在飞行过程中，请勿触发 P01程序。"（当时增加这段文字时，很多 NASA 工程师都认为这很好笑，认为 Margaret 是小题大做，几乎所有人都认为宇航员经过如此长时间的专业训练，是绝对不会犯如此低级的错误的。）

几天后，在 Apollo 8飞船执行下一项飞行任务时。宇航员 Jim Lovell、William Anders 和Frank Borman 三人执行一个长达四天的飞行计划途中，Jim Lovell 意外地触发了P01 程序的执行。更巧的是，当天正好是美国圣诞节，大部分工程师都休假去了。可想而知，当时NASA的一片混乱状态。这次不是演习，而是人命关天的危急时刻，如果不能及时解决，三名宇航员将永远无法安全返回了。所幸，当时 Margaret 的飞行手册更新中恰恰提到了这种情形，并且提供了重新上传数据以及恢复执行的有效办法，在有限的时间内解决了问题，使任务可以继续进行。

Margaret 曾经说过∶"无论对一个软件系统运行原理掌握得多么彻底，也不能阻止人犯意外错误。"在这次危机过后，Margaret 之前提交的修改申请很快就被批准了。

虽然 Apollo 8的事故发生在几十年前，但是工程师们一定不会对此感到陌生，类似的场景总是在不断重演。希望读者以史为鉴，只有靠着对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。这就是 SRE 最重要的理念! 欢迎加入 SRE 的大家庭!

软件工程有的时候和养孩子类似∶虽然生育的过程是痛苦和困难的，但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是，传统软件工程专业花费了很多精力讨论软件的开发过程，而不是其后的维护过程。有统计显示，一个软件系统的40%~90% 的花销其实是花在开发建设完成之后不断维护过程中的。行业内流行的一个说法是∶一个系统如果已经开发完成，部署在生产环境上，那么它就是"稳定的"，就不需要那么多工程师花费精力去优化、维护。我们认为这个说法是错误的。从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。这样一种职业必须具备非常广泛的技能，但是和其他职业的专注点都不同。Google 将这个职位称为站点可靠性工程师（SRE，Site Reliability Engineering）。

那么，站点可靠性工程师究竟代表着什么呢?的确，这个词语并不能够特别清晰地描述这个职位的意义。基本上每个 Google SRE 都会被经常问到这个职位到底代表什么意思，以及他们的日常工作究竟是什么。

将这个词语展开来说∶首先，也是最重要的一点，SRE 是工程师（engineer）。SRE 使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统。有的时候，SRE 和产品研发团队共同工作，其他时候我们需要开发这些系统的额外组件∶例如备份系统和负载均衡系统等。理想情况下，同时推进这些组件在多个项目中复用。还有的时候，我们的任务是想出各种各样的办法用现有组件解决新的问题。

其次，SRE的关注焦点在于可靠性。Ben Treynor Sloss，Google负责7×24运维的副总裁，SRE 名称的发明者，宣称可靠性应该是任何产品设计中最基本的概念∶任何一个系统如果没有人能够稳定地使用，就没有存在的意义。因为可靠性是如此重要，因此 SRE专注于对其负责的软件系统架构设计、运维流程的不断优化，让这些大型软件系统运行得更可靠，扩展性更好，能更有效地利用资源。但是，SRE并不是无止境地追求完美∶当一个系统已经"足够可靠"的时候，SRE 通常将精力转而投入到研发新的功能和创造新的产品中。

最后，SRE 的主要工作是运维在分布式集群管理系统上运行的具体业务服务（service）。不论是遍布全球的存储服务，还是亿万用户赖以工作的 E-mail 服务，还是 Google 最初的 Web搜索服务。SRE 中的"S"最开始指代的就是 google.com的运维服务，因为 SRE 的第一个工作就是维持网站的正常运转。随着时间的推移，SRE 逐渐接管了Google 内部绝大部分产品系统，包括 Google Cloud Platform 这类开发者平台，也包括内部的一些非网站类的基础设施系统，例如 Bigtable。

虽然我们在这里将 SRE 的职位定义得比较宽泛，但是在这样一个互联网业务高速发展的时代，这个职位的出现毫不奇怪。同样，虽然在应用系统运营维护的过程中有数不清的重要环节需要关注，我们最关注的是"可靠性"这一点也不奇怪。在 Web 服务领域里，对服务器端软件的优化和修改是相对可控的，变更管理与生产安全又结合得非常紧密，一种类似于 SRE 的职业早晚会在这个环境下诞生。

虽然 SRE 这个行业是在 Google 内部，从Web 社区中诞生的，但我们认为这个职业对其他团队和组织也有很多值得借鉴的地方。本书是对阐述SRE 发展过程的一次尝试∶我们既希望将这些宝贵经验共享给其他相关行业，也希望能从其他行业中汲取知识，从而更好地定义各种角色和术语。为了这个目的，本书将通用的理论、设计理念和思想，与实际的应用工具介绍等分开。在某些需要结合 Google内部信息讨论主题的时候，我们相信读者可以进行类比，将书中的理念与自己的实际环境相结合，以便得出更为有效的结论。

本书中也包含了一些对 Google 内部生产环境的介绍，将 Google 内部环境与外部常见的开源类软件相对应。这样可以让本书的一些设计理念与实践的结合度更强，应用起来更容易。

最后，我们当然希望社区内出现更多、更可靠的软件系统。我们知道，创业企业甚至中型企业经常对如何应用这些理念和技术感到困惑。可靠性就像安全性，越早关注越好。这就意味着一些小型创业公司，在应付日常面临的种种挑战时，也应该抽出一部分精力来面对可靠性这个话题。这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多。本书第4部分着重介绍了 SRE 团队如何进行内部培训、如何加强内部沟通等最佳实践，很多都可以直接拿来应用。

对中型企业来说，企业内部可能已经有这样的一组人在做着与SRE非常类似的工作。这些人可能并不叫 SRE 这个名字，甚至可能没有受到管理层的重视。在这样的企业中，提高可靠性最好的办法往往就是去认可这些人的工作，并配备足够的激励机制。在牛顿被世界正式认可为物理学家之前，他经常被称作是最后的炼金术师。而这些专注于可靠性的工程师们，正如当年的牛顿一样，是一个新时代的开拓者。

如果一定要为 SRE 寻找一个起源的话，谁才能够被称为世界上第一个 SRE呢?

我们选择了Margaret Hamilton，MIT 教授，参与了阿波罗登月计划的软件开发工作。她的工作具有现代 SRE的一切特性。用她自己的话来讲∶"团队文化就是从一切经历中不断学习，包括来自那些我们最意想不到的地方的经历。"

在Apollo7飞船研发期间的某一天，Margaret 带着她的小女儿 Lauren 一起来到公司。在 Margaret 忙着和组员们在大型计算机上运行飞行模拟测试的时候，她的小女儿偷偷地按下了控制台上的 DSKY 键。整个模拟程序出乎意料地崩溃了，导致整个火箭发射程序意外终止。Margaret和组员调试后发现，原来Lauren 意外触发了PO1 这段子程序的执行，导致了整个模拟过程的失败。（该子程序是起飞前调试程序，执行时会删除现存的导航信息，如果在火箭飞行过程中执行这段程序，计算机将无法继续维持火箭航线，后果将是灾难性的。）

凭借着 SRE 的直觉，Margaret 为项目组提交了一个软件改动，申请在飞行程序中增加一项特殊状态检查，以避免飞行员在飞行过程中意外触发 PO1 程序的执行。但不幸的是，NASA管理层认为，这项错误发生的可能性太小，根本不值得为此添加这项修改。于是Margaret 没有能够成功提交这项软件修改。她只能在火箭飞行手册中添加了一段文字，写道∶"在飞行过程中，请勿触发 P01程序。"（当时增加这段文字时，很多 NASA 工程师都认为这很好笑，认为 Margaret 是小题大做，几乎所有人都认为宇航员经过如此长时间的专业训练，是绝对不会犯如此低级的错误的。）

几天后，在 Apollo 8飞船执行下一项飞行任务时。宇航员 Jim Lovell、William Anders 和Frank Borman 三人执行一个长达四天的飞行计划途中，Jim Lovell 意外地触发了P01 程序的执行。更巧的是，当天正好是美国圣诞节，大部分工程师都休假去了。可想而知，当时NASA的一片混乱状态。这次不是演习，而是人命关天的危急时刻，如果不能及时解决，三名宇航员将永远无法安全返回了。所幸，当时 Margaret 的飞行手册更新中恰恰提到了这种情形，并且提供了重新上传数据以及恢复执行的有效办法，在有限的时间内解决了问题，使任务可以继续进行。

Margaret 曾经说过∶"无论对一个软件系统运行原理掌握得多么彻底，也不能阻止人犯意外错误。"在这次危机过后，Margaret 之前提交的修改申请很快就被批准了。

虽然 Apollo 8的事故发生在几十年前，但是工程师们一定不会对此感到陌生，类似的场景总是在不断重演。希望读者以史为鉴，只有靠着对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。这就是 SRE 最重要的理念! 欢迎加入 SRE 的大家庭!