SRE:Google运维解密

SRE:Google运维解密

暂无评价综合评分的显示会考虑用户真实性等多项因素,每部作品出现综合评分的时间不定。
8.8441 评价豆瓣读书
免费试读

作品简介

大型软件系统生命周期的绝大部分都处于“使用”阶段,而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢?在《SRE:Google运维解密》中,Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的,以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。通过阅读《SRE:Google运维解密》,读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。

任何一个想要创建、扩展大规模集成系统的人都应该阅读《SRE:Google运维解密》。《SRE:Google运维解密》针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。

(美)贝特西·拜尔(Betsy Beyer)是Google纽约负责SRE的一名技术文档作家。她之前曾为遍布全球的Google数据中心与Mountain View硬件运维团队编写文档。在搬到纽约之前,Betsy是Stanford大学技术性写作课程的讲师。她曾经学习国际关系与英文文学,并在Stanford和Tulane获得学历。

作品目录

  1. O'Reilly Media,Inc.介绍
  2. 赞誉
  3. 译者序
  4. 前言
  5. 序言
  6. 第Ⅰ部分 概览
  7. 第1章 介绍
  8. 第2章 Google 生产环境:SRE视角
  9. 第Ⅱ部分 指导思想
  10. 第3章 拥抱风险
  11. 第4章 服务质量目标
  12. 第5章 减少琐事
  13. 第6章 分布式系统的监控
  14. 第7章 Google 的自动化系统的演进
  15. 第8章 发布工程
  16. 第9章 简单化
  17. 第Ⅲ部分 具体实践
  18. 第10章 基于时间序列数据进行有效报警
  19. 第11章 on-call轮值
  20. 第12章 有效的故障排查手段
  21. 第13章 紧急事件响应
  22. 第14章 紧急事故管理
  23. 第15章 事后总结:从失败中学习
  24. 第16章 跟踪故障
  25. 第17章 测试可靠性
  26. 第18章 SRE部门中的软件工程实践
  27. 第19章 前端服务器的负载均衡
  28. 第20章 数据中心内部的负载均衡系统
  29. 第21章 应对过载
  30. 第22章 处理连锁故障
  31. 第23章 管理关键状态:利用分布式共识来提高可靠性
  32. 第24章 分布式周期性任务系统
  33. 第25章 数据处理流水线
  34. 第26章 数据完整性:读写一致
  35. 第27章 可靠地进行产品的大规模发布
  36. 第Ⅳ部分 管理
  37. 第28章 迅速培养SRE加入on-call
  38. 第29章 处理中断性任务
  39. 第30章 通过嵌入SRE的方式帮助团队从运维过载中恢复
  40. 第31章 SRE与其他团队的沟通与协作
  41. 第32章 SRE参与模式的演进历程
  42. 第Ⅴ部分 结束语
  43. 第33章 其他行业的实践经验
  44. 第34章 结语
  45. 附录A 系统可用性
  46. 附录B 生产环境运维过程中的最佳实践
  47. 附录C 事故状态文档示范
  48. 附录D 事后总结示范
  49. 附录E 发布协调检查列表
  50. 附录F 生产环境会议记录示范
  51. 参考文献
  52. 索引
  53. 关于编著者
  54. 封面介绍
载入中

热门划线

  1. 一般来说,SRE团队要承担以下几类职责:可用性改进,延迟优化,性能优化,效率优化,变更管理,监控,紧急事务处理以及容量规划与管理。6 人
  2. 如果100% 不是一个正确的可靠性目标,那么多少才是呢?这其实并不是一个技术问题,而是一个产品问题。要回答这个问题,必须考虑以下几个方面:● 基于用户的使用习惯,服务可靠性要达到什么程度用户才会满意?● 如果这项服务的可靠程度不够,用户是否有其他的替代选择?● 服务的可靠程度是否会影响用户对这项服务的使用模式?3 人
  3. 一个监控系统应该只有三类输出。紧急警报(alert)意味着收到警报的用户需要立即执行某种操作,目标是解决某种已经发生的问题,或者是避免即将发生的问题。工单(ticket)意味着接受工单的用户应该执行某种操作,但是并非立即执行。系统并不能自动解决目前的情况,但是如果一个用户在几天内执行这项操作,系统不会受到任何影响。日志(logging)平时没有人需要关注日志信息,但是日志信息依然被收集起来以备调试和事后分析时使用。正确的做法是平时没人会去主动阅读日志,除非有特殊需要。3 人
  4. SRE的经验告诉我们,大概 70% 的生产事故由某种部署的变更而触发。变更管理的最佳实践是使用自动化来完成以下几个项目:● 采用渐进式发布机制。● 迅速而准确地检测到问题的发生。● 当出现问题时,安全迅速地回退改动。3 人
  5. 在设计评审中,他们会认真推演各种灾难场景。在每周例会时,他们又会讨论如何消除和防范事故发生、优化各种警报策略以及增强自动化功能。在平时工作中,他们则会精心维护团队的各种文档和项目源代码,一点一点地提高服务质量。2 人
  6. Google 将这个职位称为站点可靠性工程师(SRE,Site Reliability Engineering)。2 人
  7. 不能将碰运气当成战略。2 人
  8. 系统管理员的日常工作与研发工程师相差甚远,通常分属两个不同的部门:开发部(Dev)和运维部(Ops)。2 人
  9. 传统的研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。研发部门最关注的是如何能够更快速地构建和发布新功能。运维部门更关注的是如何能在他们值班期间避免发生故障2 人
  10. 第一类,团队中 50%~60% 是标准的软件工程师,具体来讲,就是那些能够正常通过Google软件工程师招聘流程的人。第二类,其他40%~50% 则是一些基本满足Google软件工程师标准(具备85%~99% 所要求的技能),但是同时具有一定程度的其他技术能力的工程师。目前来看,UNIX 系统内部细节和1~3层网络知识是Google最看重的两类额外的技术能力。2 人

喜欢这本书的人也喜欢