SRE 作者: 贝特西 拜尔 (Betsy Beyer)/等 出版社: 电子工业出版社 出品方: 博文视点 副标题: Google运维解密 原作名: Site Reliability Engineering: How Google Runs Production Systems 译者: 孙宇聪 出版年: 2016-10-1 页数: 450 定价: CNY 108.00 装帧: 平装 丛书: O'Reilly动物系列（中译本） ISBN: 9787121297267

内容简介

Betsy 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一职。回国后，积极推动国内容器化运维架构升级。目前是开放运维联盟之应用运维规范制定组，高可用运维规范制定者。

作者简介

Betsy 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一职。回国后，积极推动国内容器化运维架构升级。目前是开放运维联盟之应用运维规范制定组，高可用运维规范制定者。

网友热评

ehoc: 指导思想一章总结的很好，“主动制造故障”去避免过度的依赖很有魄力。 zzyong: 坚定的学习和实践。但这不是一朝一夕可以完成的，我一直怀疑谷歌自己实现了许多其它公司当标准使用的东西，例如dns解析客户端。 随候鸟南飞: 有趣的经验和方法论总结，似乎在刻意回避讲具体技术，所以上下文铺陈很少，感觉只适合作为参考手册选择在意的章节跳着读，坦白讲不喜欢这种讲述结构；数据恢复的故事和模仿跑团做事故经验分享印象比较深，讲新 SRE 如何错误的上手 on-call 时提到的“浴火重生”式培训，不知道有多少人膝盖中箭。 风花雪月的龙龙: 读这种书 就像在听大牛们演讲 总有一些观点让你bling bling 赖涛儿: 这本书在很多方面可以给出一种思路，分享 google 在处理一些事情的经验，以及一些失败的教训。书中对大部分的方案，无论是从技术方面和团队管理方面，大多数时候没有给出具体的解决方法，但是总体的指导原则还是很有用的。 一个公司并不是将运维改名为SRE就算是 SRE 了，失败的SRE组织充满了琐碎的工作和极大的沟通成本，成功的SRE每天面对的都是有趣的工作。

图书目录

前言xxxi 序言xxxv 第Ⅰ部分　概览 第1章　介绍2 系统管理员模式2 Google的解决之道：SRE4 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 BigtableSRE：警报过多的案例57 Gmail：可预知的、可脚本化的人工干预58 长跑59 小结59 第7章　Google的自动化系统的演进60 自动化的价值60 一致性60 平台性61 修复速度更快61 行动速度更快62 节省时间62 自动化对GoogleSRE的价值62 自动化的应用案例63 GoogleSRE的自动化使用案例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 最小API87 模块化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 Escalator152 Outalator153 聚合154 加标签155 分析155 未预料到的好处156 第17章　测试可靠性157 软件测试的类型158 传统测试159 生产测试160 创造一个构建和测试环境163 大规模测试165 测试大规模使用的工具166 针对灾难的测试167 对速度的渴求168 发布到生产环境170 允许测试失败170 集成172 生产环境探针173 小结175 第18章　SRE部门中的软件工程实践176 为什么软件工程项目对SRE很重要176 Auxon案例分析：项目背景和要解决的问题177 传统的容量规划方法177 解决方案：基于意图的容量规划179 基于意图的容量规划180 表达产品意图的先导条件181 Auxon简介182 需求和实现：成功和不足183 提升了解程度，推进采用率185 团队内部组成187 在SRE团队中培养软件工程风气187 在SRE团队中建立起软件工程氛围：招聘与开发时间188 做到这一点189 小结190 第19章　前端服务器的负载均衡191 有时候硬件并不能解决问题191 使用DNS进行负载均衡192 负载均衡：虚拟IP194 第20章　数据中心内部的负载均衡系统197 理想情况198 识别异常任务：流速控制和跛脚鸭任务199 异常任务的简单应对办法：流速控制199 一个可靠的识别异常任务的方法：跛脚鸭状态200 利用划分子集限制连接池大小201 选择合适的子集201 子集选择算法一：随机选择202 子集选择算法二：确定性算法204 负载均衡策略206 简单轮询算法206 最闲轮询策略209 加权轮询策略210 第21章　应对过载212 QPS陷阱213 给每个用户设置限制213 客户端侧的节流机制214 重要性216 资源利用率信号217 处理过载错误217 决定何时重试218 连接造成的负载220 小结221 第22章　处理连锁故障223 连锁故障产生的原因和如何从设计上避免224 服务器过载224 资源耗尽225 服务不可用228 防止软件服务器过载228 队列管理229 流量抛弃和优雅降级230 重试231 请求延迟和截止时间234 慢启动和冷缓存236 保持调用栈永远向下238 连锁故障的触发条件238 进程崩溃239 进程更新239 新的发布239 自然增长239 计划中或计划外的不可用239 连锁故障的测试240 测试直到出现故障，还要继续测试240 测试最常用的客户端241 测试非关键性后端242 解决连锁故障的立即步骤242 增加资源242 停止健康检查导致的任务死亡242 重启软件服务器242 丢弃流量243 进入降级模式243 消除批处理负载244 消除有害的流量244 小结244 第23章　管理关键状态：利用分布式共识来提高可靠性246 使用共识系统的动力：分布式系统协调失败248 案例1：脑裂问题249 案例2：需要人工干预的灾备切换249 案例3：有问题的小组成员算法249 分布式共识是如何工作的250 Paxos概要：协议示例251 分布式共识的系统架构模式251 可靠的复制状态机252 可靠的复制数据存储和配置存储252 使用领头人选举机制实现高可用的处理系统253 分布式协调和锁服务253 可靠的分布式队列和消息传递254 分布式共识系统的性能问题255 复合式Paxos：消息流过程详解257 应对大量的读操作258 法定租约259 分布式共识系统的性能与网络延迟259 快速Paxos协议：性能优化260 稳定的领头人机制261 批处理262 磁盘访问262 分布式共识系统的部署263 副本的数量263 副本的位置265 容量规划和负载均衡266 对分布式共识系统的监控270 小结272 第24章　分布式周期性任务系统273 Cron273 介绍273 可靠性274 Cron任务和幂等性274 大规模Cron系统275 对基础设施的扩展275 对需求的扩展276 GoogleCron系统的构建过程277 跟踪Cron任务的状态277 Paxos协议的使用277 领头人角色和追随者角色278 保存状态281 运维大型Cron系统282 小结283 第25章　数据处理流水线284 流水线设计模式的起源284 简单流水线设计模式与大数据284 周期性流水线模式的挑战285 工作分发不均造成的问题285 分布式环境中周期性数据流水线的缺点286 监控周期性流水线的问题287 惊群效应287 摩尔负载模式288 GoogleWorkflow简介289 Workflow是模型—视图—控制器（MVC）模式290 Workflow中的执行阶段291 Workflow正确性保障291 保障业务的持续性292 小结294 第26章　数据完整性：读写一致295 数据完整性的强需求296 提供超高的数据完整性的策略297 备份与存档298 云计算环境下的需求299 保障数据完整性和可用性：GoogleSRE的目标300 数据完整性是手段，数据可用性是目标300 交付一个恢复系统，而非备份系统301 造成数据丢失的事故类型301 维护数据完整性的深度和广度的困难之处303 GoogleSRE保障数据完整性的手段304 24种数据完整性的事故组合304 第一层：软删除305 第二层：备份和相关的恢复方法306 额外一层：复制机制308 1Tvs.1E：存储更多数据没那么简单309 第三层：早期预警310 确保数据恢复策略可以正常工作313 案例分析314 Gmail—2011年2月：从GTape上恢复数据（磁带）314 GoogleMusic—2012年3月：一次意外删除事故的检测过程315 SRE的基本理念在数据完整性上的应用319 保持初学者的心态319 信任但要验证320 不要一厢情愿320 纵深防御320 小结321 第27章　可靠地进行产品的大规模发布322 发布协调工程师323 发布协调工程师的角色324 建立发布流程325 发布检查列表326 推动融合和简化326 发布未知的产品327 起草一个发布检查列表327 架构与依赖328 集成328 容量规划328 故障模式329 客户端行为329 流程与自动化330 开发流程330 外部依赖331 发布计划331 可靠发布所需要的方法论332 灰度和阶段性发布332 功能开关框架333 应对客户端滥用行为334 过载行为和压力测试335 LCE的发展335 LCE检查列表的变迁336 LCE没有解决的问题337 小结338 第Ⅳ部分　管理 第28章　迅速培养SRE加入on-call341 新的SRE已经招聘到了，接下来怎么办341 培训初期：重体系，而非混乱344 系统性、累积型的学习方式345 目标性强的项目工作，而非琐事346 培养反向工程能力和随机应变能力347 反向工程：弄明白系统如何工作347 统计学和比较性思维：在压力下坚持科学方法论347 随机应变的能力：当意料之外的事情发生时怎么办348 将知识串联起来：反向工程某个生产环境服务348 有抱负的on-call工程师的5个特点349 对事故的渴望：事后总结的阅读和书写349 故障处理分角色演习350 破坏真的东西，并且修复它们351 维护文档是学徒任务的一部分352 尽早、尽快见习on-call353 on-call之后：通过培训的仪式感，以及日后的持续教育354 小结354 第29章　处理中断性任务355 管理运维负载356 如何决策对中断性任务的处理策略356 不完美的机器357 流状态357 将一件事情做好358 实际一点的建议359 减少中断361 第30章　通过嵌入SRE的方式帮助团队从运维过载中恢复363 第一阶段：了解服务，了解上下文364 确定最大的压力来源364 找到导火索364 第二阶段：分享背景知识365 书写一个好的事后总结作为示范366 将紧急事件按类型排序366 第三阶段：主导改变367 从基础开始367 获取团队成员的帮助367 解释你的逻辑推理过程368 提出引导性问题368 小结369 第31章　SRE与其他团队的沟通与协作370 沟通：生产会议371 议程372 出席人员373 SRE的内部协作374 团队构成375 高效工作的技术375 SRE内部的协作案例分析：Viceroy376 Viceroy的诞生376 所面临的挑战378 建议379 SRE与其他部门之间的协作380 案例分析：将DFP迁移到F1380 小结382 第32章　SRE参与模式的演进历程383 SRE参与模式：是什么、怎么样以及为什么383 PRR模型384 SRE参与模型384 替代性支持385 PRR：简单PRR模型386 参与386 分析387 改进和重构387 培训388 “接手”服务388 持续改进388 简单PRR模型的演进：早期参与模型389 早期参与模型的适用对象389 早期参与模型的优势390 不断发展的服务：框架和SRE平台391 经验教训391 影响SRE的外部因素392 结构化的解决方案：框架392 新服务和管理优势394 小结395 第Ⅴ部分　结束语 第33章　其他行业的实践经验398 有其他行业背景的资深SRE399 灾难预案与演习400 从组织架构层面坚持不懈地对安全进行关注401 关注任何细节401 冗余容量401 模拟以及进行线上灾难演习402 培训与考核402 对详细的需求收集和系统设计的关注402 纵深防御403 事后总结的文化403 将重复性工作自动化，消除运维负载404 结构化和理性的决策406 小结407 第34章　结语408 附录A　系统可用性411 附录B　生产环境运维过程中的最佳实践412 附录C　事故状态文档示范417 附录D　事后总结示范419 附录E　发布协调检查列表423 附录F　生产环境会议记录示范425 参考文献427 索引439__