新書推薦：
《
自我囚禁的人：完美主义的心理成因与自我松绑（破除你对完美主义的迷思，尝试打破自我评价过低与焦虑的恶性循环）
》
售價：NT$
301.0
《
周易
》
售價：NT$
203.0
《
东南亚的传统与发展
》
售價：NT$
306.0
《
乾隆制造
》
售價：NT$
398.0
《
资治通鉴臣光曰辑存 资治通鉴目录（司马光全集）（全二册）
》
售價：NT$
1316.0
《
明代社会变迁时期生活质量研究
》
售價：NT$
1367.0
《
律令国家与隋唐文明
》
售價：NT$
332.0
《
紫云村（史杰鹏笔下大唐小吏的生死逃亡，新历史主义小说见微之作，附赠5张与小说内容高度契合的宣纸彩插）
》
售價：NT$
449.0
|
| 編輯推薦： |
√ 超级畅销书，Amazon主站排名*，打标#1 Best Seller
√ 运维高烧不退，谷歌神书问世，继续为这一热潮推波助澜
√ 本书解密全球*神秘*让人仰望的技术岗位——谷歌SRE
√ 未出先火，本书原著问世时各大社区火爆异常、人气爆棚
|
| 內容簡介： |
|
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢？在本书中，Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存*的软件系统。通过阅读本书，读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。任何一个想要创建、扩展大规模集成系统的人都应该阅读本书。本书针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。
|
| 關於作者： |
Besty Beyer 是Google 纽约负责SRE 的一名技术文档作家。她之前曾为遍布全球的Google 数据中心与Mountain View 硬件运维团队编写文档。在搬到纽约之前，Betsy 是Stanford 技术性写作课程的讲师。她曾经学习国际关系与英文文学，并在Stanford 和Tulane 获得学历。Chris Jones 是Google App Engine 的一名SRE。Google App Engine 是一个PaaS 服务，每天处理超过280 亿个请求。他的办公室在旧金山，他之前的工作包括Google 广告统计、数据仓库，以及用户支持系统的维护。在之前，Chris 曾经在学校IT 行业任职，同时参与过竞选数据分析，以及一些BSD 内核的修改。他有计算机工程、经济学，以及技术政策学的学位。同时他也是一名有执照的职业工程师。Jennifer Petoff 是Google SRE 团队的一名项目经理，工作地点在都柏林，爱尔兰。她曾经负责管理大型全球项目，包括：科学研究、工程、人力资源，以及广告等。Jennifer在加入Google 之前，曾在化工行业任职八年。她具有Stanford 大学的化学博士与学士学位，同时她还拥有Rochester 大学的心理学学位。Niall Murphy 是Google 爱尔兰团队广告SRE 的负责人。他拥有20 年互联网行业经验，目前是INEX（爱尔兰网络互联枢纽）的主席。他曾经写作以及参与写作很多科技文章与书籍，包括O’Reilly 出版的IPv6 Network Administration，以及很多RFC。他目前在参与书写爱尔兰互联网发展史。他拥有计算机科学、数学，以及诗歌学的学历（他当时一定是想错了！）。他目前与妻子和两个儿子居住在都柏林。
孙宇聪，前Google SRE（2007-2015），山景城总部，曾参与构建运维Youtube 全球CDN网络，2008年奥运会直播项目，构建维护海量视频编码传输系统。后参与Google内部云平台运维工作，负责运维全球百万级别服务器集群，以及Borg、Omega等大规模集群理系统。2015年加入Coding，任CTO一职。回国后，积极推动国内容器化运维架构升级。目前是开放运维联盟之应用运维规范制定组，高可用运维规范制定者。
|
| 目錄：
|
目录
前言 ................ xxxi
序言 ............... xxxv
第Ⅰ部分 概览
第1 章 介绍..... 2
系统管理员模式 ... 2
Google 的解决之道：SRE ...................... 4
SRE 方法论 .......... 6
确保长期关注研发工作 ................... 6
在保障服务SLO 的前提下化迭代速度 ....................... 7
监控系统 ......................................... 8
应急事件处理 .................................. 8
变更管理 ...... 9
需求预测和容量规划 ....................... 9
资源部署 .... 10
效率与性能. 10
小结 ................... 10
第2 章 Google 生产环境：SRE 视角...... 11
硬件 ................... 11
管理物理服务器的系统管理软件 .......... 13
管理物理服务器 ............................ 13
存储 ............ 14
网络 ............ 15
其他系统软件 .... 16
分布式锁服务 ................................ 16
监控与警报系统 ............................ 16
软件基础设施 .... 17
研发环境 ............ 17
莎士比亚搜索：一个示范服务 ............. 18
用户请求的处理过程 ..................... 18
任务和数据的组织方式 ................. 19
第Ⅱ部分 指导思想
第3 章 拥抱风险................................ 23
管理风险 ............ 23
度量服务的风险 . 24
服务的风险容忍度 ................................ 25
辨别消费者服务的风险容忍度 ...... 26
基础设施服务的风险容忍度 ......... 28
使用错误预算的目的 ............................ 30
错误预算的构建过程 ..................... 31
好处 ............ 32
第4 章 服务质量目标........................... 34
服务质量术语 .... 34
指标 ............ 34
目标 ............ 35
协议 ............ 36
指标在实践中的应用 ............................ 37
运维人员和终用户各关心什么 .. 37
指标的收集. 37
汇总 ............ 38
指标的标准化 ................................ 39
目标在实践中的应用 ............................ 39
目标的定义. 40
目标的选择. 40
控制手段 .... 42
SLO 可以建立用户预期 ................ 42
协议在实践中的应用 ............................ 43
第5 章 减少琐事................................ 44
琐事的定义 ........ 44
为什么琐事越少越好 ............................ 45
什么算作工程工作 ................................ 46
琐事繁多是不是一定不好 ..................... 47
小结 ................... 48
第6 章 分布式系统的监控..................... 49
术语定义 ............ 49
为什么要监控 .... 50
对监控系统设置合理预期 ..................... 51
现象与原因 ........ 52
黑盒监控与白盒监控 ............................ 53
4 个黄金指标 ..... 53
关于长尾问题 .... 54
度量指标时采用合适的精度 ................. 55
简化，直到不能再简化......................... 55
将上述理念整合起来 ............................ 56
监控系统的长期维护 ............................ 57
Bigtable SRE ：警报过多的案例 ... 57
Gmail ：可预知的、可脚本化的人工干预 ........................ 58
长跑 ............ 59
小结 ................... 59
第7 章 Google 的自动化系统的演进...... 60
自动化的价值 .... 60
一致性 ........ 60
平台性 ........ 61
修复速度更快 ................................ 61
行动速度更快 ................................ 62
节省时间 .... 62
自动化对Google SRE 的价值 .............. 62
自动化的应用案例 ................................ 63
Google SRE 的自动化使用案例 .... 63
自动化分类的层次结构 ................. 64
让自己脱离工作：自动化所有的东西 .. 66
舒缓疼痛：将自动化应用到集群上线中 ................................. 67
使用Prodtest 检测不一致情况 ...... 68
幂等地解决不一致情况 ................. 69
专业化倾向. 71
以服务为导向的集群上线流程 ...... 72
Borg ：仓库规模计算机的诞生 ............. 73
可靠性是基本的功能......................... 74
建议 ................... 75
第8 章 发布工程................................ 76
发布工程师的角色 ................................ 76
发布工程哲学 .... 77
自服务模型. 77
追求速度 .... 77
密闭性 ........ 77
强调策略和流程 ............................ 78
持续构建与部署 . 78
构建 ............ 78
分支 ............ 79
测试 ............ 79
打包 ............ 79
Rapid 系统 .. 80
部署 ............ 81
配置管理 ............ 81
小结 ................... 82
不仅仅只对Google 有用 ............... 83
一开始就进行发布工程 ................. 83
第9 章 简单化 85
系统的稳定性与灵活性......................... 85
乏味是一种美德 . 86
我不放弃我的代码......................... 86
“负代码行”作为一个指标 ................... 87
小 API ............ 87
模块化 ................ 87
发布的简单化 .... 88
小结 ................... 88
第Ⅲ部分 实践
第10 章 基于时间序列数据进行有效报警.. 93
Borgmon 的起源 94
应用软件的监控埋点 ............................ 95
监控指标的收集 . 96
时间序列数据的存储 ............................ 97
标签与向量. 98
Borg 规则计算 ... 99
报警 ................. 104
监控系统的分片机制 .......................... 105
黑盒监控 .......... 106
配置文件的维护 .................................. 106
十年之后 .......... 108
第11 章 on-call 轮值....................... 109
介绍 ................. 109
on-call 工程师的一天 .......................... 110
on-call 工作平衡 ..................................111
数量上保持平衡 ...........................111
质量上保持平衡 ...........................111
补贴措施 .. 112
安全感 .............. 112
避免运维压力过大 .............................. 114
运维压力过大 .............................. 114
奸诈的敌人—运维压力不够 .... 115
小结 ................. 115
第12 章 有效的故障排查手段................ 116
理论 ................. 117
实践 ................. 119
故障报告 .. 119
定位 .......... 119
检查 .......... 120
诊断 .......... 122
测试和修复.................................. 124
神奇的负面结果 .................................. 125
治愈 .......... 126
案例分析 .......... 127
使故障排查更简单 .............................. 130
小结 ................. 130
第13 章 紧急事件响应........................ 131
当系统出现问题时怎么办 ................... 131
测试导致的紧急事故 .......................... 132
细节 .......... 132
响应 .......... 132
事后总结 .. 132
变更部署带来的紧急事故 ................... 133
细节 .......... 133
事故响应 .. 134
事后总结 .. 134
流程导致的严重事故 .......................... 135
细节 .......... 135
灾难响应 .. 136
事后总结 .. 136
所有的问题都有解决方案 ................... 137
向过去学习，而不是重复它 ............... 138
为事故保留记录 .......................... 138
提出那些大的，甚至不可能的问题：假如…… ............. 138
鼓励主动测试 .............................. 138
小结 ................. 138
第14 章 紧急事故管理....................... 140
无流程管理的紧急事故....................... 140
对这次无流程管理的事故的剖析 ........ 141
过于关注技术问题 ...................... 141
沟通不畅 .. 141
不请自来 .. 142
紧急事故的流程管理要素 ................... 142
嵌套式职责分离 .......................... 142
控制中心 .. 143
实时事故状态文档 ...................... 143
明确公开的职责交接 ................... 143
一次流程管理良好的事故 ................... 144
什么时候对外宣布事故....................... 144
小结 ................. 145
第15 章 事后总结：从失败中学习......... 146
Google 的事后总结哲学 ...................... 146
协作和知识共享 .................................. 148
建立事后总结文化 .............................. 149
小结以及不断优化 .............................. 151
第16 章 跟踪故障..............................152
Escalator .......... 152
Outalator .......... 153
聚合 .......... 154
加标签 ......
|
| 內容試閱：
|
如果用一个词语来描述 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 行业内部并不流行的词语。我们不断重复发明各种系统。很多年以来，只有 USENIX LISA 大会论坛以及其他几个专注于操作系统的会议会讨论一些 IT 基础设施的设计和实现。很多年后的今天，IT 行业已经天翻地覆，但是本书仍然弥足珍贵：它详细记录了Google 迈过分水岭时期的全过程。很显然，这些经历没有办法完全复制，也许只能被模仿，但是却可以启发读者，指引未来。本书作者们表现出了极大的真诚，显示了谦逊的风格，以及极强的凝聚力、领导力。这些文章记录了作者们的希望、担忧、前言 ｜ xxxiii
成功与失败的经历。我向这些作者们和编者们的勇气致敬，正是这种坦率，让我们能够作为旁观者和后来人，从前人的经历中学习到宝贵的知识。
Mark Burgess
In Search of Certainty 一书作者
Oslo，2016 年3 月
序言
软件工程有的时候和养孩子类似：虽然生育的过程是痛苦和困难的，但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是，传统软件工程专业花费了很多精力讨论软件的开发过程，而不是其后的维护过程。有统计显示， 一个软件系统的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 的一切特性。用她自己的话来讲：“团队文化就是从一切经历中不断学习，包括来自那些我们意想不到的地方的经历。”
在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，其中包括了一些有益读物， 希望读者能从中获得阅读的乐趣。
致谢
本书全靠作者们和技术作家们的不懈努力才得以面世。我们要特别感谢以下内部评审者，他们提供了非常有价值的反馈：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
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
