SRE：Google运维解密
SRE：Google运维解密
Betsy Beyer 著
孙宇聪 译
出版时间：2016年09月
页数：480
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢？在《SRE：Google运维解密》中，Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。通过阅读《SRE：Google运维解密》，读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。
任何一个想要创建、扩展大规模集成系统的人都应该阅读《SRE：Google运维解密》。《SRE：Google运维解密》针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。
  1. 前言
  2. 序言
  3. 第I部分　概览
  4. 第1章　介绍
  5. 系统管理员模式
  6. Google的解决之道：SRE
  7. SRE方法论
  8. 确保长期关注研发工作
  9. 在保障服务SLO的前提下最大化迭代速度
  10. 监控系统
  11. 应急事件处理
  12. 变更管理
  13. 需求预测和容量规划
  14. 资源部署
  15. 效率与性能
  16. 小结
  17. 第2章　Google生产环境：SRE视角
  18. 硬件
  19. 管理物理服务器的系统管理软件
  20. 管理物理服务器
  21. 存储
  22. 网络
  23. 其他系统软件
  24. 分布式锁服务
  25. 监控与警报系统
  26. 软件基础设施
  27. 研发环境
  28. 莎士比亚搜索：一个示范服务
  29. 用户请求的处理过程
  30. 任务和数据的组织方式
  31. 第II部分　指导思想
  32. 第3章　拥抱风险
  33. 管理风险
  34. 度量服务的风险
  35. 服务的风险容忍度
  36. 辨别消费者服务的风险容忍度
  37. 基础设施服务的风险容忍度
  38. 使用错误预算的目的
  39. 错误预算的构建过程
  40. 好处
  41. 第4章　服务质量目标
  42. 服务质量术语
  43. 指标
  44. 目标
  45. 协议
  46. 指标在实践中的应用
  47. 运维人员和最终用户各关心什么
  48. 指标的收集
  49. 汇总
  50. 指标的标准化
  51. 目标在实践中的应用
  52. 目标的定义
  53. 目标的选择
  54. 控制手段
  55. SLO可以建立用户预期
  56. 协议在实践中的应用
  57. 第5章　减少琐事
  58. 琐事的定义
  59. 为什么琐事越少越好
  60. 什么算作工程工作
  61. 琐事繁多是不是一定不好
  62. 小结
  63. 第6章　分布式系统的监控
  64. 术语定义
  65. 为什么要监控
  66. 对监控系统设置合理预期
  67. 现象与原因
  68. 黑盒监控与白盒监控
  69. 4个黄金指标
  70. 关于长尾问题
  71. 度量指标时采用合适的精度
  72. 简化，直到不能再简化
  73. 将上述理念整合起来
  74. 监控系统的长期维护
  75. Bigtable SRE ：警报过多的案例
  76. Gmail：可预知的、可脚本化的人工干预
  77. 长跑
  78. 小结
  79. 第7章　Google的自动化系统的演进
  80. 自动化的价值
  81. 一致性
  82. 平台性
  83. 修复速度更快
  84. 行动速度更快
  85. 节省时间
  86. 自动化对Google SRE的价值
  87. 自动化的应用案例
  88. Google SRE的自动化使用案例
  89. 自动化分类的层次结构
  90. 让自己脱离工作：自动化所有的东西
  91. 舒缓疼痛：将自动化应用到集群上线中
  92. 使用Prodtest检测不一致情况
  93. 幂等地解决不一致情况
  94. 专业化倾向
  95. 以服务为导向的集群上线流程
  96. Borg：仓库规模计算机的诞生
  97. 可靠性是最基本的功能
  98. 建议
  99. 第8章　发布工程
  100. 发布工程师的角色
  101. 发布工程哲学
  102. 自服务模型
  103. 追求速度
  104. 密闭性
  105. 强调策略和流程
  106. 持续构建与部署
  107. 构建
  108. 分支
  109. 测试
  110. 打包
  111. Rapid系统
  112. 部署
  113. 配置管理
  114. 小结
  115. 不仅仅只对Google有用
  116. 一开始就进行发布工程
  117. 第9章　简单化
  118. 系统的稳定性与灵活性
  119. 乏味是一种美德
  120. 我绝对不放弃我的代码
  121. “负代码行”作为一个指标
  122. 最小API
  123. 模块化
  124. 发布的简单化
  125. 小结
  126. 第III部分　具体实践
  127. 第10章　基于时间序列数据进行有效报警
  128. Borgmon的起源
  129. 应用软件的监控埋点
  130. 监控指标的收集
  131. 时间序列数据的存储
  132. 标签与向量
  133. Borg规则计算
  134. 报警
  135. 监控系统的分片机制
  136. 黑盒监控
  137. 配置文件的维护
  138. 十年之后
  139. 第11章　on-call轮值
  140. 介绍
  141. on-call工程师的一天
  142. on-call工作平衡
  143. 数量上保持平衡
  144. 质量上保持平衡
  145. 补贴措施
  146. 安全感
  147. 避免运维压力过大
  148. 运维压力过大
  149. 奸诈的敌人—运维压力不够
  150. 小结
  151. 第12章　有效的故障排查手段
  152. 理论
  153. 实践
  154. 故障报告
  155. 定位
  156. 检查
  157. 诊断
  158. 测试和修复
  159. 神奇的负面结果
  160. 治愈
  161. 案例分析
  162. 使故障排查更简单
  163. 小结
  164. 第13章　紧急事件响应
  165. 当系统出现问题时怎么办
  166. 测试导致的紧急事故
  167. 细节
  168. 响应
  169. 事后总结
  170. 变更部署带来的紧急事故
  171. 细节
  172. 事故响应
  173. 事后总结
  174. 流程导致的严重事故
  175. 细节
  176. 灾难响应
  177. 事后总结
  178. 所有的问题都有解决方案
  179. 向过去学习，而不是重复它
  180. 为事故保留记录
  181. 提出那些大的，甚至不可能的问题：假如……
  182. 鼓励主动测试
  183. 小结
  184. 第14章　紧急事故管理
  185. 无流程管理的紧急事故
  186. 对这次无流程管理的事故的剖析
  187. 过于关注技术问题
  188. 沟通不畅
  189. 不请自来
  190. 紧急事故的流程管理要素
  191. 嵌套式职责分离
  192. 控制中心
  193. 实时事故状态文档
  194. 明确公开的职责交接
  195. 一次流程管理良好的事故
  196. 什么时候对外宣布事故
  197. 小结
  198. 第15章　事后总结：从失败中学习
  199. Google的事后总结哲学
  200. 协作和知识共享
  201. 建立事后总结文化
  202. 小结以及不断优化
  203. 第16章　跟踪故障
  204. Escalator
  205. Outalator
  206. 聚合
  207. 加标签
  208. 分析
  209. 未预料到的好处
  210. 第17章　测试可靠性
  211. 软件测试的类型
  212. 传统测试
  213. 生产测试
  214. 创造一个构建和测试环境
  215. 大规模测试
  216. 测试大规模使用的工具
  217. 针对灾难的测试
  218. 对速度的渴求
  219. 发布到生产环境
  220. 允许测试失败
  221. 集成
  222. 生产环境探针
  223. 小结
  224. 第18章　SRE部门中的软件工程实践
  225. 为什么软件工程项目对SRE很重要
  226. Auxon案例分析：项目背景和要解决的问题
  227. 传统的容量规划方法
  228. 解决方案：基于意图的容量规划
  229. 基于意图的容量规划
  230. 表达产品意图的先导条件
  231. Auxon简介
  232. 需求和实现：成功和不足
  233. 提升了解程度，推进采用率
  234. 团队内部组成
  235. 在SRE团队中培养软件工程风气
  236. 在SRE团队中建立起软件工程氛围：招聘与开发时间
  237. 做到这一点
  238. 小结
  239. 第19章　前端服务器的负载均衡
  240. 有时候硬件并不能解决问题
  241. 使用DNS进行负载均衡
  242. 负载均衡：虚拟IP
  243. 第20章　数据中心内部的负载均衡系统
  244. 理想情况
  245. 识别异常任务：流速控制和跛脚鸭任务
  246. 异常任务的简单应对办法：流速控制
  247. 一个可靠的识别异常任务的方法：跛脚鸭状态
  248. 利用划分子集限制连接池大小
  249. 选择合适的子集
  250. 子集选择算法一：随机选择
  251. 子集选择算法二：确定性算法
  252. 负载均衡策略
  253. 简单轮询算法
  254. 最闲轮询策略
  255. 加权轮询策略
  256. 第21章　应对过载
  257. QPS陷阱
  258. 给每个用户设置限制
  259. 客户端侧的节流机制
  260. 重要性
  261. 资源利用率信号
  262. 处理过载错误
  263. 决定何时重试
  264. 连接造成的负载
  265. 小结
  266. 第22章　处理连锁故障
  267. 连锁故障产生的原因和如何从设计上避免
  268. 服务器过载
  269. 资源耗尽
  270. 服务不可用
  271. 防止软件服务器过载
  272. 队列管理
  273. 流量抛弃和优雅降级
  274. 重试
  275. 请求延迟和截止时间
  276. 慢启动和冷缓存
  277. 保持调用栈永远向下
  278. 连锁故障的触发条件
  279. 进程崩溃
  280. 进程更新
  281. 新的发布
  282. 自然增长
  283. 计划中或计划外的不可用
  284. 连锁故障的测试
  285. 测试直到出现故障，还要继续测试
  286. 测试最常用的客户端
  287. 测试非关键性后端
  288. 解决连锁故障的立即步骤
  289. 增加资源
  290. 停止健康检查导致的任务死亡
  291. 重启软件服务器
  292. 丢弃流量
  293. 进入降级模式
  294. 消除批处理负载
  295. 消除有害的流量
  296. 小结
  297. 第23章　管理关键状态：利用分布式共识来提高可靠性
  298. 使用共识系统的动力：分布式系统协调失败
  299. 案例1：脑裂问题
  300. 案例2：需要人工干预的灾备切换
  301. 案例3：有问题的小组成员算法
  302. 分布式共识是如何工作的
  303. Paxos概要：协议示例
  304. 分布式共识的系统架构模式
  305. 可靠的复制状态机
  306. 可靠的复制数据存储和配置存储
  307. 使用领头人选举机制实现高可用的处理系统
  308. 分布式协调和锁服务
  309. 可靠的分布式队列和消息传递
  310. 分布式共识系统的性能问题
  311. 复合式Paxos：消息流过程详解
  312. 应对大量的读操作
  313. 法定租约
  314. 分布式共识系统的性能与网络延迟
  315. 快速Paxos协议：性能优化
  316. 稳定的领头人机制
  317. 批处理
  318. 磁盘访问
  319. 分布式共识系统的部署
  320. 副本的数量
  321. 副本的位置
  322. 容量规划和负载均衡
  323. 对分布式共识系统的监控
  324. 小结
  325. 第24章　分布式周期性任务系统
  326. Cron
  327. 介绍
  328. 可靠性
  329. Cron任务和幂等性
  330. 大规模Cron系统
  331. 对基础设施的扩展
  332. 对需求的扩展
  333. Google Cron系统的构建过程
  334. 跟踪Cron任务的状态
  335. Paxos协议的使用
  336. 领头人角色和追随者角色
  337. 保存状态
  338. 运维大型Cron系统
  339. 小结
  340. 第25章　数据处理流水线
  341. 流水线设计模式的起源
  342. 简单流水线设计模式与大数据
  343. 周期性流水线模式的挑战
  344. 工作分发不均造成的问题
  345. 分布式环境中周期性数据流水线的缺点
  346. 监控周期性流水线的问题
  347. 惊群效应
  348. 摩尔负载模式
  349. Google Workflow简介
  350. Workflow是模型—视图—控制器（MVC）模式
  351. Workflow中的执行阶段
  352. Workflow正确性保障
  353. 保障业务的持续性
  354. 小结
  355. 第26章　数据完整性：读写一致
  356. 数据完整性的强需求
  357. 提供超高的数据完整性的策略
  358. 备份与存档
  359. 云计算环境下的需求
  360. 保障数据完整性和可用性：Google SRE的目标
  361. 数据完整性是手段，数据可用性是目标
  362. 交付一个恢复系统，而非备份系统
  363. 造成数据丢失的事故类型
  364. 维护数据完整性的深度和广度的困难之处
  365. Google SRE保障数据完整性的手段
  366. 24种数据完整性的事故组合
  367. 第一层：软删除
  368. 第二层：备份和相关的恢复方法
  369. 额外一层：复制机制
  370. 1T vs. 1E：存储更多数据没那么简单
  371. 第三层：早期预警
  372. 确保数据恢复策略可以正常工作
  373. 案例分析
  374. Gmail—2011年2月：从GTape上恢复数据（磁带）
  375. Google Music—2012年3月：一次意外删除事故的检测过程
  376. SRE的基本理念在数据完整性上的应用
  377. 保持初学者的心态
  378. 信任但要验证
  379. 不要一厢情愿
  380. 纵深防御
  381. 小结
  382. 第27章　可靠地进行产品的大规模发布
  383. 发布协调工程师
  384. 发布协调工程师的角色
  385. 建立发布流程
  386. 发布检查列表
  387. 推动融合和简化
  388. 发布未知的产品
  389. 起草一个发布检查列表
  390. 架构与依赖
  391. 集成
  392. 容量规划
  393. 故障模式
  394. 客户端行为
  395. 流程与自动化
  396. 开发流程
  397. 外部依赖
  398. 发布计划
  399. 可靠发布所需要的方法论
  400. 灰度和阶段性发布
  401. 功能开关框架
  402. 应对客户端滥用行为
  403. 过载行为和压力测试
  404. LCE的发展
  405. LCE检查列表的变迁
  406. LCE没有解决的问题
  407. 小结
  408. 第IV部分　管理
  409. 第28章　迅速培养SRE加入on-call
  410. 新的SRE已经招聘到了，接下来怎么办
  411. 培训初期：重体系，而非混乱
  412. 系统性、累积型的学习方式
  413. 目标性强的项目工作，而非琐事
  414. 培养反向工程能力和随机应变能力
  415. 反向工程：弄明白系统如何工作
  416. 统计学和比较性思维：在压力下坚持科学方法论
  417. 随机应变的能力：当意料之外的事情发生时怎么办
  418. 将知识串联起来：反向工程某个生产环境服务
  419. 有抱负的on-call工程师的5个特点
  420. 对事故的渴望：事后总结的阅读和书写
  421. 故障处理分角色演习
  422. 破坏真的东西，并且修复它们
  423. 维护文档是学徒任务的一部分
  424. 尽早、尽快见习on-call
  425. on-call之后：通过培训的仪式感，以及日后的持续教育
  426. 小结
  427. 第29章　处理中断性任务
  428. 管理运维负载
  429. 如何决策对中断性任务的处理策略
  430. 不完美的机器
  431. 流状态
  432. 将一件事情做好
  433. 实际一点的建议
  434. 减少中断
  435. 第30章　通过嵌入SRE的方式帮助团队从运维过载中恢复
  436. 第一阶段：了解服务，了解上下文
  437. 确定最大的压力来源
  438. 找到导火索
  439. 第二阶段：分享背景知识
  440. 书写一个好的事后总结作为示范
  441. 将紧急事件按类型排序
  442. 第三阶段：主导改变
  443. 从基础开始
  444. 获取团队成员的帮助
  445. 解释你的逻辑推理过程
  446. 提出引导性问题
  447. 小结
  448. 第31章　SRE与其他团队的沟通与协作
  449. 沟通：生产会议
  450. 议程
  451. 出席人员
  452. SRE的内部协作
  453. 团队构成
  454. 高效工作的技术
  455. SRE内部的协作案例分析：
  456. Viceroy的诞生
  457. 所面临的挑战
  458. 建议
  459. SRE与其他部门之间的协作
  460. 案例分析：将DFP迁移到F1
  461. 小结
  462. 第32章　SRE参与模式的演进历程
  463. SRE参与模式：是什么、怎么样以及为什么
  464. PRR模型
  465. SRE参与模型
  466. 替代性支持
  467. PRR：简单PRR模型
  468. 参与
  469. 分析
  470. 改进和重构
  471. 培训
  472. “接手”服务
  473. 持续改进
  474. 简单PRR 模型的演进：早期参与模型
  475. 早期参与模型的适用对象
  476. 早期参与模型的优势
  477. 不断发展的服务：框架和SRE平台
  478. 经验教训
  479. 影响SRE的外部因素
  480. 结构化的解决方案：框架
  481. 新服务和管理优势
  482. 小结
  483. 第V部分　结束语
  484. 第33章　其他行业的实践经验
  485. 有其他行业背景的资深SRE
  486. 灾难预案与演习
  487. 从组织架构层面坚持不懈地对安全进行关注
  488. 关注任何细节
  489. 冗余容量
  490. 模拟以及进行线上灾难演习
  491. 培训与考核
  492. 对详细的需求收集和系统设计的关注
  493. 纵深防御
  494. 事后总结的文化
  495. 将重复性工作自动化，消除运维负载
  496. 结构化和理性的决策
  497. 小结
  498. 第34章　结语
  499. 附录A　系统可用性
  500. 附录B　生产环境运维过程中的最佳实践
  501. 附录C　事故状态文档示范
  502. 附录D　事后总结示范
  503. 附录E　发布协调检查列表
  504. 附录F　生产环境会议记录示范
  505. 参考文献
  506. 索引
书名：SRE：Google运维解密
作者：Betsy Beyer 著
译者：孙宇聪 译
国内出版社：电子工业出版社
出版时间：2016年09月
页数：480
书号：978-7-121-29726-7
原版书书名：Site Reliability Engineering
原版书出版商：O'Reilly Media
Betsy Beyer
 
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。他目前在参与书写爱尔兰互联网发展史。他拥有计算机科学、数学，以及诗歌学的学历（他当时一定是想错了！）。他目前与妻子和两个儿子居住在都柏林。
 
 
购买选项
定价：108.00元
书号：978-7-121-29726-7
出版社：电子工业出版社
联系出版社邮购

© 2024，奥莱利技术咨询(北京)有限公司。版权所有。
传真: +86-10-88097463
 京ICP备05003502号