序言
软件工程有的时候和养孩子类似：虽然生育的过程是痛苦和困难的，但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是，传统软件工程专业花费了很多精力讨论软件的开发过程，而不是其后的维护过程。有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。[1]行业内流行的一个说法是：一个系统如果已经开发完成，部署在生产环境上，那么它就是 “稳定的”，就不需要那么多工程师花费精力去优化、维护。我们认为这个说法是错误的。从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。这样一种职业必须具备非常广泛的技能，但是和其他职业的专注点都不同。Google 将这个职位称为站点可靠性工程师（SRE,Site Reliability Engineering）。
那么，站点可靠性工程师究竟代表着什么呢？的确，这个词语并不能够特别清晰地描述这个职位的意义。基本上每个 Google SRE都会被经常问到这个职位到底代表什么意思，以及他们的日常工作究竟是什么。
将这个词语展开来说：首先，也是最重要的一点，SRE 是工程师（engineer）。SRE 使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统。有的时候，SRE 和产品研发团队共同工作，其他时候我们需要开发这些系统的额外组件：例如备份系统和负载均衡系统等。理想情况下，同时推进这些组件在多个项目中复用。还有的时候，我们的任务是想出各种各样的办法用现有组件解决新的问题。
其次，SRE 的关注焦点在于可靠性。Ben Treynor Sloss,Google负责7×24运维的副总裁，SRE名称的发明者，宣称可靠性应该是任何产品设计中最基本的概念：任何一个系统如果没有人能够稳定地使用，就没有存在的意义。因为可靠性[2]是如此重要，因此SRE 专注于对其负责的软件系统架构设计、运维流程的不断优化，让这些大型软件系统运行得更可靠，扩展性更好，能更有效地利用资源。但是，SRE并不是无止境地追求完美：当一个系统已经 “足够可靠”的时候，SRE 通常将精力转而投入到研发新的功能和创造新的产品中。[3]
最后，SRE 的主要工作是运维在分布式集群管理系统上运行的具体业务服务（service）。不论是遍布全球的存储服务，还是亿万用户赖以工作的 E-mail 服务，还是 Google 最初的 Web 搜索服务。SRE 中的“S”最开始指代的就是google.com的运维服务，因为SRE的第一个工作就是维持网站的正常运转。随着时间的推移，SRE 逐渐接管了 Google 内部绝大部分产品系统，包括 Google Cloud Platform 这类开发者平台，也包括内部的一些非网站类的基础设施系统，例如 Bigtable。
虽然我们在这里将 SRE 的职位定义得比较宽泛，但是在这样一个互联网业务高速发展的时代，这个职位的出现毫不奇怪。同样，虽然在应用系统运营维护的过程中有数不清的重要环节需要关注，我们最关注的是“可靠性”这一点也不奇怪。[4]在Web服务领域里，对服务器端软件的优化和修改是相对可控的，变更管理与生产安全又结合得非常紧密，一种类似于 SRE 的职业早晚会在这个环境下诞生。
虽然 SRE 这个行业是在 Google 内部，从Web 社区中诞生的，但我们认为这个职业对其他团队和组织也有很多值得借鉴的地方。本书是对阐述SRE 发展过程的一次尝试：我们既希望将这些宝贵经验共享给其他相关行业，也希望能从其他行业中汲取知识，从而更好地定义各种角色和术语。为了这个目的，本书将通用的理论、设计理念和思想，与实际的应用工具介绍等分开。在某些需要结合Google内部信息讨论主题的时候，我们相信读者可以进行类比，将书中的理念与自己的实际环境相结合，以便得出更为有效的结论。
本书中也包含了一些对 Google 内部生产环境的介绍，将 Google 内部环境与外部常见的开源类软件相对应。这样可以让本书的一些设计理念与实践的结合度更强，应用起来更容易。
最后，我们当然希望社区内出现更多、更可靠的软件系统。我们知道，创业企业甚至中型企业经常对如何应用这些理念和技术感到困惑。可靠性就像安全性，越早关注越好。这就意味着一些小型创业公司，在应付日常面临的种种挑战时，也应该抽出一部分精力来面对可靠性这个话题。这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多。本书第4部分着重介绍了 SRE 团队如何进行内部培训、如何加强内部沟通等最佳实践，很多都可以直接拿来应用。
对中型企业来说，企业内部可能已经有这样的一组人在做着与SRE非常类似的工作。这些人可能并不叫 SRE 这个名字，甚至可能没有受到管理层的重视。在这样的企业中，提高可靠性最好的办法往往就是去认可这些人的工作，并配备足够的激励机制。在牛顿被世界正式认可为物理学家之前，他经常被称作是最后的炼金术师。而这些专注于可靠性的工程师们，正如当年的牛顿一样，是一个新时代的开拓者。
如果一定要为SRE寻找一个起源的话，谁才能够被称为世界上第一个SRE呢？
我们选择了 Margaret Hamilton,MIT 教授，参与了阿波罗登月计划的软件开发工作。她的工作具有现代SRE的一切特性。[5]用她自己的话来讲：“团队文化就是从一切经历中不断学习，包括来自那些我们最意想不到的地方的经历。”
在Apollo 7飞船研发期间的某一天，Margaret 带着她的小女儿 Lauren 一起来到公司。在 Margaret 忙着和组员们在大型计算机上运行飞行模拟测试的时候，她的小女儿偷偷地按下了控制台上的 DSKY 键。整个模拟程序出乎意料地崩溃了，导致整个火箭发射程序意外终止。Margaret 和组员调试后发现，原来Lauren 意外触发了 P01 这段子程序的执行，导致了整个模拟过程的失败。（该子程序是起飞前调试程序，执行时会删除现存的导航信息，如果在火箭飞行过程中执行这段程序，计算机将无法继续维持火箭航线，后果将是灾难性的。）
凭借着 SRE的直觉，Margaret 为项目组提交了一个软件改动，申请在飞行程序中增加一项特殊状态检查，以避免飞行员在飞行过程中意外触发P01程序的执行。但不幸的是，NASA 管理层认为，这项错误发生的可能性太小，根本不值得为此添加这项修改。于是Margaret 没有能够成功提交这项软件修改。她只能在火箭飞行手册中添加了一段文字，写道：“在飞行过程中，请勿触发P01程序。”（当时增加这段文字时，很多NASA工程师都认为这很好笑，认为Margaret 是小题大做，几乎所有人都认为宇航员经过如此长时间的专业训练，是绝对不会犯如此低级的错误的。）
几天后，在Apollo 8飞船执行下一项飞行任务时。宇航员 Jim Lovell、William Anders和Frank Borman 三人执行一个长达四天的飞行计划途中，Jim Lovell 意外地触发了 P01程序的执行。更巧的是，当天正好是美国圣诞节，大部分工程师都休假去了。可想而知，当时NASA的一片混乱状态。这次不是演习，而是人命关天的危急时刻，如果不能及时解决，三名宇航员将永远无法安全返回了。所幸，当时 Margaret 的飞行手册更新中恰恰提到了这种情形，并且提供了重新上传数据以及恢复执行的有效办法，在有限的时间内解决了问题，使任务可以继续进行。
Margaret 曾经说过：“无论对一个软件系统运行原理掌握得多么彻底，也不能阻止人犯意外错误。”在这次危机过后，Margaret 之前提交的修改申请很快就被批准了。
虽然Apollo 8的事故发生在几十年前，但是工程师们一定不会对此感到陌生，类似的场景总是在不断重演。希望读者以史为鉴，只有靠着对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。这就是SRE 最重要的理念！欢迎加入SRE的大家庭！
如何阅读本书
这本书是由一系列短文组成的，由Google SRE成员和前成员共同写就。相比之下，这本书更像是一本会议文集。本书的每一章都可以作为一个独立部分进行阅读，但是读者也可以根据自己的兴趣选择某些章节重点阅读。（如果本书中引用了某些额外文章，你可以在参考文献中找到。）
读者可以按照任何顺序阅读本书，但是我们推荐从第2章和第3章开始。这两章描述了Google的生产运行环境，以及SRE 是如何系统化认知与量化“风险”的（毕竟 “风险”是SRE最关注的要点）。读者当然也可以选择逐章阅读，本书逻辑上分为以下几个部分：理念性介绍（第Ⅱ部分）、最佳实践（第Ⅲ部分）和管理经验（第Ⅳ部分）。每一部分都配有简介，并且配有SRE成员以前发表的文章的引用地址。最后，本书配有网站https://g.co/SREBook，其中包括了一些有益读物，希望读者能从中获得阅读的乐趣。
本书的印刷约定
下面是本书中使用的字体约定：
斜体（Italic）
表示新术语、URL、E-mail 地址、文件名及文件扩展名。
等宽字体（Constant width）
用于嵌入一小段程序代码，也用于行内的一些编程术语、函数名、数据库名称、数据结构类型、环境变量和关键词等。
等宽加粗字体（Constant width bold）
表示命令或其他应该由用户输入的文本。
等宽斜体（Constant width italic）
表示应该替换为用户提供的值的文本。
这个图标表示提示或建议。
这个图标表示一般说明。
这个图标表示警告或注意。
中文版书中切口以“
”表示原书页码，便于读者与英文原版图书对照阅读，本书的索引中列的页码也为英文原版图书中的页码。
使用示例代码
补充材料可以到http://g.co/SREBook下载。
本书对你的工作有所帮助。一般来说，可以在你的程序或者文档中使用本书提供的示例代码。你不必联系我们获得许可，除非你要大量传播代码。例如，从书中抄几块代码编写程序不需要许可；销售或分销O'Reilly随书附带光盘上的示例代码则需要许可；引用本书中的示例代码回答问题不需要许可；将书中大量的示例代码附加到你的产品文档中则需要许可。
我们感谢但不要求注明出处。出处的格式一般包括标题、作者、出版商和ISBN。例如，“Site Reliability Engineering,edited by Betsy Beyer,Chris Jones,Jennifer Petoff,and Niall Richard Murphy（O'Reilly）.Copyright 2016 Google,Inc,978-1-491-92912-4.”。
如果你觉得示例代码的使用不合理或不符合以上的许可权限，请随时联系我们：permissions@oreilly.com。
permissions@oreilly.com
Safari Books Online
Safari Books Online（www.safaribooksonline.com）是一个按需出版的数字图书馆，出版各种专业的书籍和视频，它们由世界上技术和商业领域的优秀作者撰写。
技术人员、软件开发者、网页设计者及商业和创意专业人士都把Safari Books Online当作科研、问题解决、学习及认证训练的主要资源
Safari Books Online为组织、政府机构和个人提供了大量的产品组合和定价方案
Safari Books Online为组织、政府机构和个人提供了大量的产品组合和定价方案。订阅者可以从一个完全可搜索的数据库中获取成千上万的书籍、培训视频和尚未出版的手稿，这些出版商包括OReilly Media,Prentice Hall Professional,Addison-WesleyProfessional,Microsoft Press,Sams,Que,Peachpit Press,Focal Press,Cisco Press,JohnWiley & Sons,Syngress,Morgan Kaufmann,IBM Redbooks,Packt,Adobe Press,FTPress,Apress,Manning,New Riders,McGraw-Hill,Jones & Bartlett,Course Technology,以及其他数十家出版社。如想了解更多Safari Books Online的信息，请在线访问我们。
如何联系我们
请将对本书的评价和存在的问题通过如下地址告知出版者：
美国：
O'Reilly Media,Inc.
1005 Gravenstein Highway North
Sebastopol,CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C 座807 室（100035）
奥莱利技术咨询（北京）有限公司
O'Reilly 的每一本书都有专属网站，你可以在那里找到关干本书的相关信息，包括勘误列表、示例代码以及其他信息。本书的网站地址是：
http:/bit.ly/site-reliability-engineering
对干本书的评论和技术性的问题，请发送电子邮件到 ：
bookquestions@oreilly.com
关干我们的书籍、课程、会议和新闻的更多信息，请参阅我们的网站http://www.oreilly.com。
在Facebook上找到我们：http://facebook.com/oreilly
在Twitter上关注我们：http://twitter.com/oreillymedia
在YouTube上观看我们：http://www.youtube.com/oreillymedia
致谢
本书全靠作者们和技术作家们的不懈努力才得以面世。我们要特别感谢以下内部评审者，他们提供了非常有价值的反馈：Alex Matey、Dermot Duffy、JC van Winkel、John T。
Ben Lutch和Ben Treynor Sloss 是本书在Google内部的赞助者；他们对这项工作的认可和对分享我们运维大规模服务的认可是本书成书的关键条件。
我们特别致谢 Rik Farrow,;login：的编辑，他与我们的一些作者紧密合作，在USENIX上预发布了本书的一部分内容。
每章中都注明了本章的作者，我们在这里也想特别致谢一下为每一章提供了反馈、讨论以及评审的人。
第3章：Abe Rahey、Ben Treynor Sloss、Brian Stoler、Dave O'Connor、David Besbris、Jill Alvidrez、Mike Curtis、Nancy Chang、Tammy Capistrant、Tom Limoncelli
第5章：Cody Smith、George Sadlier、Laurence Berland、Marc Alvidrez、Patrick Stahlberg、Peter Duff、Pim van Pelt、Ryan Anderson、Sabrina Farmer、Seth Hettich
第6章：Mike Curtis、Jamie Wilkinson、Seth Hettich
第8章：David Schnur、JT Goldstone、Marc Alvidrez、Marcus Lara-Reinhold、Noah Maxwell、Peter Dinges、Sumitran Raghunathan、Yutong Cho
第9章：Ryan Anderson
第10章：Jules Anderson、Max Luebbe、Mikel Mcdaniel、Raul Vera、Seth Hettich
第11章：Andrew Stribblehill、Richard Woodbury
第12章：Charles Stephen Gunn、John Hedditch、Peter Nuttall、Rob Ewaschuk、Sam Greenfield
第13章：Jelena Oertel、Kripa Krishnan、Sergio Salvi、Tim Craig
第14章：Amy Zhou、Carla Geisser、Grainne Sheerin、Hildo Biersma、Jelena Oertel、Perry Lorier、Rune Kristian Viken
第15章：Dan Wu、Heather Sherman、Jared Brick、Mike Louer、Štěpán Davidovič、Tim Craig
第16章：Andrew Stribblehill、Richard Woodbury
第17章：Isaac Clerencia、Marc Alvidrez
第18章：Ulric Longyear
第19章：Debashish Chatterjee、Perry Lorier
第20章和第21章：Adam Fletcher、Christoph Pfisterer、Lukáš Ježek、Manjot Pahwa、Micha Riser、Noah Fiedel、Pavel Herrmann、Paweł Zuzelski、Perry Lorier、Ralf Wildenhues、Tudor-Ioan Salomie、Witold Baryluk
第22章：Mike Curtis、Ryan Anderson
第23章：Ananth Shrinivas、Mike Burrows
第24章：Ben Fried、Derek Jackson、Gabe Krabbe、Laura Nolan、Seth Hettich
第25章：Abdulrahman Salem、Alex Perry、Arnar Mar Hrafnkelsson、Dieter Pearcey、Dylan Curley、Eivind Eklund、Eric Veach、Graham Poulter、Ingvar Mattsson、John Looney、Ken Grant、Michelle Duffy、Mike Hochberg、Will Robinson
第26章：Corey Vickrey、Dan Ardelean、Disney Luangsisongkham、Gordon Prioreschi、Kristina Bennett、Liang Lin、Michael Kelly、Sergey Ivanyuk
第27章：Vivek Rau
第28章：Melissa Binde、Perry Lorier、Preston Yoshioka
第29章：Ben Lutch、Carla Geisser、Dzevad Trumic、John Turek、Matt Brown
第30章：Charles Stephen Gunn、Chris Heiser、Max Luebbe、Sam Greenfield
第31章：Alex Kehlenbeck、Jeromy Carriere、Joel Becker、Sowmya Vijayaraghavan、Trevor Mattson-Hamilton
第32章：Seth Hettich
第33章：Adrian Hilton、Brad Kratochvil、Charles Ballowe、Dan Sheridan、Eddie Kennedy、Erik Gross、Gus Hartmann、Jackson Stone、Jeff Stevenson、John Li、Kevin Greer、Matt Toia、Michael Haynie、Mike Doherty、Peter Dahl、Ron Heiby
我们对下列贡献者也表示诚挚的感谢，他们为本书提供了很多素材，仔细评审了每一章，参与了访谈部分，提供了意义重大的资源与专家意见，或者是在其他方面帮助了本书：
Abe Hassan、Adam Rogoyski、Alex Hidalgo、Amaya Booker、Andrew Fikes、Andrew Hurst、Ariel Goh、Ashleigh Rentz、Ayman Hourieh、Barclay Osborn、Ben Appleton、Ben Love、Ben Winslow、Bernhard Beck、Bill Duane、Bill Patry、Blair Zajac、Bob Gruber、Brian Gustafson、Bruce Murphy、Buck Clay、Cedric Cellier、Chiho Saito、Chris Carlon、Christopher Hahn、Chris Kennelly、Chris Taylor、Ciara KamaheleSanfratello、Colin Phipps、Colm Buckley、Craig Paterson、Daniel Eisenbud、Daniel V.Klein、Daniel Spoonhower、Dan Watson、Dave Phillips、David Hixson、Dina Betser、Doron Meyer、Dmitry Fedoruk、Eric Grosse、Eric Schrock、Filip Zyzniewski、Francis Tang、Gary Arneson、Georgina Wilcox、Gretta Bartels、Gustavo Franco、Harald Wagener、Healfdene Goguen、Hugo Santos、Hyrum Wright、Ian Gulliver、Jakub Turski、James Chivers、James O'Kane、James Youngman、Jan Monsch、Jason ParkerBurlingham、Jason Petsod、Jeffry McNeil、Jeff Dean、Jeff Peck、Jennifer Mace、Jerry Cen、Jess Frame、John Brady、John Gunderman、John Kochmar、John Tobin、Jordyn Buchanan、Joseph Bironas、Julio Merino、Julius Plenz、Kate Ward、Kathy Polizzi、Katrina Sostek、Kenn Hamm、Kirk Russell、Kripa Krishnan、Larry Greenfield、Lea Oliveira、Luca Cittadini、Lucas Pereira、Magnus Ringman、Mahesh Palekar、Marco Paganini、Mario Bonilla、Mathew Mills、Mathew Monroe、Matt D.Brown、Matt Proud、Max Saltonstall、Michal Jaszczyk、Mihai Bivol、Misha Brukman、Olivier Oansaldi、Patrick Bernier、Pierre Palatin、Rob Shanley、Robert van Gent、Rory Ward、Rui ZhangShen、Salim Virji、Sanjay Ghemawat、Sarah Coty、Sean Dorward、Sean Quinlan、Sean Sechrest、Shari Trumbo-McHenry、Shawn Morrissey、Shun-Tak Leung、Stan Jedrus、Stefano Lattarini、Steven Schirripa、Tanya Reilly、Terry Bolt、Tim Chaplin、Toby Weingartner、Tom Black、Udi Meiri、Victor Terron、Vlad Grama、Wes Hertlein、and Zoltan Egyed.
我们非常感谢外部评审者提供的深度反馈：Andrew Fong、Björn Rabenstein、Charles Border、David Blank-Edelman、Frossie Economou、James Meickle、Josh Ryder、Mark Burgess、Russ Allbery。
我们同时特别感谢Cian Synnott，本书的创始团队成员。他在本书成书前离开了Google，但是对本书成书有深远的影响。以及Margaret Hamilton，感谢她允许我们在序言中引用了她的故事。另外，我们还特别感谢Shylaja Nukala，感谢她和她的科技作者们对本书的大力支持，她们的努力是不可或缺的。
本书的编辑们还希望亲自感谢以下人员。
Betsy Beyer：感谢我的祖母（我的个人英雄），她无数次在电话中鼓励我。以及Riba，她帮助我度过了数个无眠的夜晚。同时，当然还要感谢所有参与的SRE，与他们协作无比愉快。
Chris Jones：感谢Michelle，她阻止了我加入海盗这一职业，同时也感谢她在出乎意料的地方找到苹果的能力（玩笑话），同时感谢这些年来所有教授我软件工程学的人。
Jennifer Petoff：感谢我的丈夫Scott，感谢他在我写作本书的两年时间内的大力支持，以及感谢他保障了本书编辑们在“沙漠绿洲”中的充足的糖分供应。
Niall Murphy：感谢 Léan、Oisín和Fiachra，感谢他们这些年来对我的抱怨给予的极高容忍度。感谢Dermot，感谢他提供的内部调动机会。
[1]在这些预测中数据变动的幅度这么大，本身就说明软件工程不是一个非常注重精确性的职业（具体细节参见文献［Gla02］）。
[2]在我们的讨论中，可靠性（reliability）是指某个系统能够在指定环境下，成功持续执行某个功能指定的时间的概率（参见文献[Oco12]中的定义）。
[4]在这里，我们故意与行业内流行的词语 DevOps进行区分。虽然我们认同基础设施即代码的理念，但我们主要关注的是可靠性。同时，我们也更倾向于将运维的需要直接消除，具体细节参见第7章。