谷歌开发者趋势（谷歌SRE--前言）
谷歌开发者趋势（谷歌SRE--前言）最终，当然，更注重可靠性的软件和系统工程本质上是好的。但是，我们承认，较小的组织可能想知道他们如何才能最好地利用此处提供的体验：就像安全性一样，您越早关心可靠性，越好。这意味着，即使一个小型组织有许多紧迫的问题，并且您选择的软件可能与Google所选择的软件不同，但仍然值得尽早提供轻量级的可靠性支持，因为后期扩展结构的成本要低于后者。介绍一个不存在的。管理中包含许多关于培训，沟通和会议的最佳实践，我们发现这些最佳实践对我们很有效，其中许多最佳实践应立即由您的组织使用。我们还提供了一些指导性材料，包括对Google生产环境的描述以及我们一些内部软件与公开软件之间的映射，这些信息应有助于我们所说的话语化并使其更直接可用。最后，SRE专注于在我们的分布式计算系统上构建的运营服务，无论这些服务是行星级存储，为数亿用户提供的电子邮件，还是Google最初从事的网络搜索。以我们的名义使用的“网站”最初
软件工程与生孩子有一个共同点：分娩前的工作很痛苦而且很困难，但是分娩后的工作实际上是您花费大部分精力的地方。然而，尽管软件工程作为一门学科要花更多的时间讨论第一阶段，而不是第二阶段，尽管据估计，系统的总成本中有40％至90％是在出生后产生的。1一种流行的行业模型是错误的，这种行业模型认为已部署的可运行软件在生产中是“稳定的”，因此不需要软件工程师的注意。从这个角度来看，我们可以看到，如果软件工程倾向于将重点放在设计和构建软件系统上，那么必须有另一门学科来关注于软件对象的整个生命周期，从开始到部署，运行，完善和最终和平停用。该学科使用（并且需要使用）广泛的技能，但与其他类型的工程师有不同的关注点。今天，我们的答案是Google称其为站点可靠性工程。
那么，站点可靠性工程（SRE）到底是什么？我们承认这并不是我们所做工作的特别明确的名称-几乎每位Google的站点可靠性工程师都会被问到确切的含义，以及他们经常实际做什么。
首先，最重要的是，SRE是工程师。我们将计算机科学和工程学原理应用于计算系统的设计和开发：通常是大型分布式系统。有时，我们的任务是与产品开发人员一起为这些系统编写软件。有时，我们的任务是构建系统所需的所有其他组件，例如备份或负载平衡，理想情况下，以便它们可以在系统中重复使用；有时，我们的任务是弄清楚如何将现有解决方案应用于新问题。
接下来，我们关注系统可靠性。Google的24/7运营副总裁Ben Treynor Sloss是SRE的创始者，他声称可靠性是任何产品的最基本特征：如果没有人可以使用，那么系统就没有太大用处！由于可靠性2至关重要，因此SRE专注于寻找改进系统设计和操作的方法，以使其具有更高的可扩展性，可靠性和效率。但是，我们只在某个方向上花了点力气：当系统“足够可靠”时，我们将精力投入到添加功能或开发新产品上。3
最后，SRE专注于在我们的分布式计算系统上构建的运营服务，无论这些服务是行星级存储，为数亿用户提供的电子邮件，还是Google最初从事的网络搜索。以我们的名义使用的“网站”最初指的是SRE在维持google.com网站正常运行中的作用，尽管我们现在运行着更多的服务，其中许多本身都不是网站，从Bigtable之类的内部基础设施到外部开发人员的产品（例如作为Google Cloud Platform。
尽管我们已经将SRE表示为一门广泛的学科，但它在快速发展的Web服务世界中出现并不足为奇，并且也许源于我们基础设施的特殊性。同样，我们可以选择特别关注软件的所有部署后特性也不足为奇，可靠性是我们认为最重要的特性。4 Web服务的领域，既因为改进和更改服务器端软件的过程被相对包含，又因为变更管理本身与各种故障紧密地联系在一起，这是一种自然的平台，我们的方法可能由此而来。
尽管出现在Google以及更广泛的网络社区中，但我们认为该学科具有适用于其他社区和其他组织的课程。本书试图解释我们的工作方式：既使其他组织也可以利用我们所学的知识，也可以更好地定义角色和术语的含义。为此，我们对本书进行了整理，以便在可能的情况下将一般原则和更具体的实践分开，并在适合使用Google专有信息讨论特定主题的地方，我们相信读者会沉迷于此并且不会害怕对自己的环境得出有用的结论。
我们还提供了一些指导性材料，包括对Google生产环境的描述以及我们一些内部软件与公开软件之间的映射，这些信息应有助于我们所说的话语化并使其更直接可用。
最终，当然，更注重可靠性的软件和系统工程本质上是好的。但是，我们承认，较小的组织可能想知道他们如何才能最好地利用此处提供的体验：就像安全性一样，您越早关心可靠性，越好。这意味着，即使一个小型组织有许多紧迫的问题，并且您选择的软件可能与Google所选择的软件不同，但仍然值得尽早提供轻量级的可靠性支持，因为后期扩展结构的成本要低于后者。介绍一个不存在的。管理中包含许多关于培训，沟通和会议的最佳实践，我们发现这些最佳实践对我们很有效，其中许多最佳实践应立即由您的组织使用。
但是对于介于初创公司和跨国公司之间的规模，您的组织中可能已经有人在从事SRE工作，而不必将其称为该名称或被这样认可。开始提高组织可靠性的另一种方法是正式认可这项工作，或者找到这些人并培养他们的工作-予以奖励。他们是站在一种看待世界和另一种看待世界的方式之间的风口浪尖的人：就像牛顿，有时被人们称为不是世界上第一个物理学家，而是世界上最后一个炼金术士。
从历史的角度来看，谁会是第一个SRE？
我们想认为，玛格丽特·汉密尔顿（Margaret Hamilton）是麻省理工学院（MIT）借来的阿波罗（Apollo）项目的研究者，具有第一批SRE的所有重要特征。5用她自己的话说，“文化的一部分是向所有人和一切学习，包括从人们最不期望的中学到东西。”
一个很好的例子是，当她的小女儿劳伦（Lauren）有一天与她一起工作时，一些团队正在混合仿真计算机上运行任务场景。像小孩子一样，劳伦（Lauren）继续探索，她以一种意外的方式选择了DSKY键，导致“任务”坠毁，提醒团队注意如果真正的宇航员无意中选择了预发射程序P01，将会发生什么情况。在真正的任务中，在真正的中途。（在不经意间将P01发射到实际任务中将是一个主要问题，因为它会擦掉导航数据，并且计算机没有配备没有导航数据的飞行员的装备。）
出于SRE的直觉，玛格丽特提交了程序更改请求，以在机载飞行软件中添加特殊的错误检查代码，以防宇航员在飞行过程中偶然碰巧选择了P01。但是，NASA的“高层人士”认为此举是不必要的：当然，这永远不可能发生！因此，玛格丽特没有添加错误检查代码，而是更新了任务规格说明文件，将其表示为“在飞行中不要选择P01”。（显然，该更新使该项目的许多人都感到很有趣，他们多次被告知宇航员不会犯任何错误，毕竟他们受过完美训练。）
好吧，玛格丽特建议的防护措施只是在规格更新几天后才进行，直到下一次执行阿波罗8号任务的时候。在飞行的第四天的中途，宇航员吉姆·洛弗尔，威廉·安德斯和弗兰克·博尔曼在机上，吉姆·洛弗尔错误地选择了P01（圣诞节期间发生），这给所有相关人员造成了很大破坏。这是一个关键问题，因为在没有解决方法的情况下，没有导航数据意味着宇航员永远不会回家。值得庆幸的是，文档更新已明确指出了这种可能性，并且对于弄清楚如何上传可用数据和恢复任务非常宝贵，而没有太多时间可以花时间。
正如Margaret所说，“对如何操作系统的透彻了解还不足以防止人为错误，”不久后批准了向预启动程序P01添加错误检测和恢复软件的更改请求。
尽管阿波罗8号（Apollo 8）事件发生在几十年前，但前面的段落中有很多与今天的工程师生活直接相关，并且在将来仍将直接相关。因此，对于您要照顾的系统，您工作的团队或正在建立的组织，请牢记SRE方式：彻底和奉献，对准备和文档价值的信念以及对可能出什么问题，以及强烈的意愿去阻止它。欢迎来到我们的新兴专业！
如何读这本书
本书是由Google网站可靠性工程组织的成员和校友撰写的一系列论文。它更像是会议记录，而不是作者或少数作者的标准书。每章都应作为一个连贯整体的一部分来阅读，但是通过阅读您特别感兴趣的任何主题都可以得到很多帮助。（如果还有其他支持或告知文本的文章，我们会引用它们，以便您进行相应的跟进。）
尽管我们建议至少从“ SRE和拥抱风险” 的观点出发，至少从Google的生产环境章节开始，这些内容描述了Google的生产环境并概述了SRE如何应对风险，分别。（从许多方面来说，风险是我们职业的关键素质。）当然，从头到尾地阅读书本也是有用且可行的。我们的章节按主题进行分组，分为原则（Principles），实践（Practices）和管理（Management））。每篇文章都有一个简短的介绍，突出介绍了各个部分的内容，并引用了Google SRE发布的其他文章，其中更详细地介绍了特定主题。此外，本书的配套网站https://g.co/SREBook拥有许多有用的资源。
我们希望这至少对您而言对我们来说一样有用和有趣。
-编辑
本书中使用的约定本书使用以下印刷约定：
斜体
指示新的术语，URL，电子邮件地址，文件名和文件扩展名。
Constant width
用于程序清单，以及在段落中用于引用程序元素，例如变量或函数名称，数据库，数据类型，环境变量，语句和关键字。
Constant width bold
显示应由用户直接输入的命令或其他文本。
Constant width italic
显示应由用户提供的值或由上下文确定的值替换的文本。
小费
该元素表示提示或建议。
注意
此元素表示一般注释。
警告
此元素表示警告或注意。
使用代码示例补充材料可从https://g.co/SREBook获得。
这本书可以帮助您完成工作。通常，如果本书提供了示例代码，则可以在程序和文档中使用它。除非您要复制大部分代码，否则无需与我们联系以获取许可。例如，编写使用本书中若干代码段的程序无需许可。出售或分发O'Reilly书籍中的示例CD-ROM确实需要获得许可。引用本书并引用示例代码来回答问题无需许可。确实需要将本书中的大量示例代码合并到产品文档中。
我们感谢但不要求注明出处。出处通常包括标题，作者，出版者和ISBN。例如：“ 网站可靠性工程”，由Betsy Beyer，Chris Jones，Jennifer Petoff和Niall Richard Murphy（O'Reilly）编辑。版权所有2016 Google，Inc.，978-1-491-92912-4。”
如果您认为对代码示例的使用超出了合理使用范围或上述给出的许可范围，请随时通过permissions@oreilly.com与我们联系。
Safari®在线丛书注意
Safari联机丛书是一个按需数字图书馆，它以书籍和视频形式提供来自技术和商业领域的全球领先作者的专家内容。
技术专业人员，软件开发人员，网页设计师以及业务和创意专业人员将Safari联机丛书用作研究，解决问题，学习和认证培训的主要资源。
Safari联机丛书为企业，政府，教育和个人提供了一系列计划和价格。
会员可以在一个完全可搜索的数据库中访问O'Reilly Media，Prentice Hall Professional，Addison-Wesley Professional，Microsoft Press，Sams，Que，Peachpit Press，Focal Press，Cisco等出版商的成千上万本书，培训视频和预出版手稿，并在一个完全可搜索的数据库中Press，John Wiley＆Sons，Syngress，Morgan Kaufmann，IBM Redbooks，Packt，Adobe Press，FT Press，Apress，Manning，New Riders，McGraw-Hill，Jones＆Bartlett，Course Technology 等等。有关Safari的联机丛书的更多信息，请访问我们的在线。
如何联络我们请将有关本书的评论和问题告知出版商：
- O'Reilly Media，Inc.
- 1005 Gravenstein Highway North
- 塞巴斯托波尔，CA 95472
- 800-998-9938（在美国或加拿大）
- 707-829-0515（国际或本地）
- 707-829-0104（传真）
我们有一本书的网页，其中列出了勘误表，示例以及所有其他信息。您可以通过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. Reese，Michael O'Reilly，Steve Carstensen和Todd Underwood。这本书的赞助商是本·拉奇（Ben Lutch）和本·特雷诺·本（Ben Treynor Sloss）。他们对这个项目的信念以及分享我们对运行大规模服务所学到的知识对于使这本书成为现实至关重要。
我们要特别感谢; login：的编辑Rik Farrow 与我们合作，为通过USENIX进行预出版提供了许多帮助。
尽管在每一章中都特别感谢作者，但我们还是希望花些时间通过提供深思熟虑的输入，讨论和审阅来认识对每一章做出贡献的人。
冒险：安倍·拉海（Abe Rahey），本·特雷诺·斯洛斯（Ben Treynor Sloss），布莱恩·斯托勒（Brian Stoler），戴夫·奥康纳（Dave O'Connor），大卫·贝斯布雷斯，吉尔·阿尔维德雷斯（Jill Alvidrez），迈克·柯蒂斯（Mike Curtis），南希·张，塔米·塔米（Tammy Capistrant），汤姆·利蒙切利（Tom Limoncelli）
消除劳动：科迪·史密斯，乔治·萨德利尔，劳伦斯·伯兰德，马克·阿尔维德雷斯，帕特里克·斯塔伯格，彼得·达夫，皮姆·范·皮尔特，瑞安·安德森，萨布丽娜·农夫，塞思·海蒂奇
监视分布式系统：Mike Curtis，Jamie Wilkinson，Seth Hettich
发布工程：David Schnur，JT Goldstone，Marc Alvidrez，Marcus Lara-Reinhold，Noah Maxwell，Peter Dinges，Sumitran Raghunathan，Yutong Cho
简洁性：Ryan Anderson
来自时间序列数据的实用警报：Jules Anderson，Max Luebbe，Mikel Mcdaniel，Raul Vera，Seth Hettich
正在对呼叫：安德鲁Stribblehill，理查德·伍德伯里
有效的故障排除：查尔斯·斯蒂芬·冈恩，约翰·赫迪奇，彼得·努塔尔，罗伯·埃瓦舒克，萨姆·格林菲尔德
紧急响应：Jelena Oertel，Kripa Krishnan，Sergio Salvi，Tim Craig
处理事件：艾米·周，卡拉·盖瑟，格莱恩·谢林，希尔多·比斯玛，耶琳娜·厄特尔，佩里·洛里，符文·克里斯蒂安·维肯
事后文化：从失败中学习：丹·伍，希瑟·谢尔曼，贾里德·布里克，迈克·娄尔，史蒂潘·戴维多维奇，蒂姆·克雷格
跟踪停机：Andrew Stribblehill，Richard Woodbury
可靠性测试：Isaac Clerencia，Marc Alvidrez
SRE的软件工程：Ulric Longyear
前端的负载平衡：Debashish Chatterjee，Perry Lorier
数据中心中的负载平衡和处理超载章节：亚当·弗莱彻，克里斯托夫·普菲斯特尔，卢卡什·杰泽克，曼乔特·帕瓦，米查·里泽尔，诺亚·费德尔，帕维尔·赫尔曼，帕韦·祖泽尔斯基，佩里·罗里尔，拉尔夫·威登胡斯，都铎·伊奥·萨洛米耶，维托尔德·巴里鲁克
解决级联故障：Mike Curtis，Ryan Anderson
管理临界状态：可靠性的分布式共识：Ananth Shrinivas，Mike Burrows
具有Cron的分布式定期计划：Ben Fried，Derek Jackson，Gabe Krabbe，Laura Nolan，Seth Hettich
数据处理管道：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
数据完整性：您所读的内容是您所写的内容：Corey Vickrey，Dan Ardelean，Disney Luangsisongkham，Gordon Prioreschi，Kristina Bennett，Liang Lin，Michael Kelly，Sergey Ivanyuk
可靠的大规模产品发布：Vivek Rau
加速SRE随时待命：Melissa Binde，Perry Lorier，Preston Yoshioka
处理中断：Ben Lutch，Carla Geisser，Dzevad Trumic，John Turek，Matt Brown
嵌入SRE以从操作过载中恢复：Charles Stephen Gunn，Chris Heiser，Max Luebbe，Sam Greenfield
SRE中的交流与协作：Alex Kehlenbeck，Jeromy Carriere，Joel Becker，Sowmya Vijayaraghavan，Trevor Mattson-Hamilton
不断发展的SRE参与模型：Seth Hettich
从其他行业吸取的教训：阿德里安·希尔顿，布拉德·克拉托奇维尔，查尔斯·巴洛维，丹·谢里丹，埃迪·肯尼迪，埃里克·格罗斯，古斯·哈特曼，杰克逊·斯通，杰夫·史蒂文森，约翰·李，凯文·格雷尔，马特·托亚，迈克尔·海妮，迈克·多赫蒂，彼得·达尔，罗恩·海比
我们也感谢以下贡献者，他们提供了重要的材料，出色的审查工作，同意接受采访，提供了大量的专业知识或资源，或者对这项工作产生了其他出色的效果：
安倍·哈桑（Abe Hassan），亚当·罗戈斯基（Adam Rogoyski），亚历克斯·希达戈（Alex Hidalgo），阿玛亚·布克（Amaya Booker），安德鲁·菲克斯（Andrew Fikes），安德鲁·赫斯特（Andrew Hurst），阿里尔·高（Ariel Goh），阿什利·伦茨（Ashleigh Rentz），艾曼·霍里赫（Barclay Osborn），本·阿普尔顿，本·爱普顿（Ben Love），本·温斯洛（Bernhard Beck），比尔·杜安（Bill Duane），比尔·帕特里（Bill Patry），布莱尔·扎亚克，鲍勃·格鲁伯（Bob Gruber），布莱恩·古斯塔夫森（Brian Gustafson），布鲁斯·墨菲（Bruce Murphy），巴克·克莱（Buck Clay），塞德里克·塞利埃（Cedric Cellier），基奥·齐藤（Chiho Saito），克里斯·卡洛恩（Chris Carlon），克里斯托弗·哈恩（Christopher Hahn），克里斯·肯尼利（Chris Kennelly），克里斯·泰勒（Chris Taylor），Ciara Kamahele-Sanfratello，科林·菲普斯（Col Phipps），科尔姆·巴克利（Collm Buckley），克雷格·帕特森（Craig Paterson），丹尼尔·埃森布（Daniel Eisenbud）克莱因，丹尼尔·斯波豪威尔，丹·沃森，戴夫·菲利普斯，大卫·希克森，狄娜·贝瑟，多伦·迈尔，德米特里·费多鲁克，埃里克·格罗斯，埃里克·施洛克，菲利普·齐兹涅夫斯基，弗朗西斯·唐，加里·阿内森，乔治娜·威尔科克斯，格莱塔·巴特尔斯，古斯塔沃·弗朗科，哈拉德·瓦格纳，Healfdene Goguen，Hugo Santos，Hyrum Wright，Ian Gulliver，Jakub Turski，James Chivers，James O'Kane，James Youngman，Jan Monsch，Jason Parker-Burlingham，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，凯特·沃德，凯西·波利齐，卡特里娜·索斯泰克，肯·哈姆，柯克·罗素，克里帕·克里希南，拉里·格林菲尔德，莉亚·奥利维拉，卢卡·奇塔迪尼，卢卡斯·佩雷拉，马格努斯·林格曼，马赫什·帕莱卡，马可·帕格尼尼，马里奥·博尼利亚，马修·米尔斯，马修·门罗，马特D布朗，马特·普罗德，马克斯·萨尔顿斯托尔，米哈尔·雅斯奇克，米海·比沃尔，米莎·布鲁克曼，奥利维耶·奥萨尔迪，帕特里克·伯尼尔，皮埃尔·帕拉丁，罗伯·尚利，罗伯特·范·根特，罗里·沃德，芮章申，萨利姆·维吉，桑杰·格维瓦，莎拉·科蒂，肖恩·多沃德，肖恩·昆兰，肖恩·塞克里斯特，莎莉·特伦博·麦亨利，肖恩·莫里西，梁舜德，斯坦·杰德斯，斯特凡诺·拉塔里尼，史蒂芬·席里帕Tanya Reilly，Terry Bolt，Tim Chaplin，Toby Weingartner，Tom Black，Udi Meiri，Victor Terron，Vlad Grama，Wes Hertlein和Zoltan Egyed。
我们非常感谢从外部审阅者那里收到的周到和深入的反馈：安德鲁·方，比约恩·拉本斯坦，查尔斯·边界，戴维·布兰克·爱德曼，弗罗西·伊科诺穆，詹姆斯·梅克尔，乔什·莱德，马克·伯吉斯和拉斯·阿伯里。
我们要特别感谢最初的图书团队成员和同谋Cian Synnott，他在该项目完成之前离开了Google，但对它产生了深远的影响，还有玛格丽特·汉密尔顿（Margaret Hamilton），她如此亲切地允许我们在我们的项目中引用她的故事前言。此外，我们还要特别感谢Shylaja Nukala，她慷慨地奉献了她的技术作家的时间，并全心全意地支持他们的必要和宝贵的工作。
编辑还想亲自感谢以下人员：
贝茜·拜尔（Betsy Beyer）：感谢祖母（我的个人英雄），为他提供无休止的电话鼓舞和爆米花；向里巴，为我提供为深夜加油所需的运动裤。当然，除了这些SRE全明星阵容之外，他们的确是令人愉快的合作者。
克里斯·琼斯（Chris Jones）：对米歇尔（Michelle），表彰他使我免于公海犯罪的生活，以及她在意想不到的地方发现曼萨纳斯的超凡能力，以及多年来教我做工程技术的人。
詹妮弗·佩托夫（Jennifer Petoff）：感谢我的丈夫斯科特（Scott），在编写本书的两年过程中给予了极大的支持，并在我们的“甜点岛”上为编辑们提供了大量的糖。
Niall Murphy：对Léan，Oisín和Fiachra来说，多年来我比我有权期望的父亲和丈夫要充实得多，他们的耐心性大大超过了我。向Dermot转让。
1这些估算值之间有如此大的差异这一事实告诉您有关软件工程的学科知识，但请参见例如 [Gla02]了解更多详细信息。
2为了我们的目的，可靠性是按照 [Oco12]中的定义，“ [系统]在规定的条件下在规定的时间段内将执行所需功能而不会发生故障的概率”。
3我们关注的软件系统主要是网站和类似服务；我们不会讨论用于核电站，飞机，医疗设备或其他安全关键系统的软件所面临的可靠性问题。我们这样做，不过，比较与那些在其他行业中使用我们的方法与其他行业的经验教训。
4在这一点上，我们与行业术语DevOps不同，因为尽管我们确实将基础架构视为代码，但我们将可靠性作为主要重点。此外，我们非常注重消除操作的必要性-有关更多详细信息，请参见 Google的《自动化的演变》。
5除了这个伟大的故事以外，她还宣称要普及“软件工程”一词。
