搜索
高级检索
高级搜索
书       名 :
著       者 :
出  版  社 :
I  S  B  N:
文献来源:
出版时间 :
SRE生存指南:系统中断响应与正常运行时间最大化
0.00     定价 ¥ 79.00
图书来源: 浙江图书馆(由JD配书)
此书还可采购25本,持证读者免费借回家
  • 配送范围:
    浙江省内
  • ISBN:
    9787121371769
  • 作      者:
    [美]纳特韦尔奇(NatWelch)
  • 译      者:
    冯文辉
  • 出 版 社 :
    电子工业出版社
  • 出版日期:
    2019-09-01
收藏
编辑推荐

√ 作者长期服务于对服务中断非常敏感的大型互联网公司,总结出一套久经考验的方法论,专用于监控现代Web服务、设置警报、评估针对生产事件的响应机制,以及短时间内恢复网站宕机事故。

 

√ 除了别出心裁增设SRE面试一章,精华内容还包括监控灾难性故障|向团队发出紧急宕机警报|分析生产事件应对策略|构建属于自己的自动化测试工具或相关软件|预测瓶颈以改善用户体验。

 

√ 阿里巴巴高可用架构团队负责人游骥|蘑菇街平台技术总监赵成|《SRE:Google运维解密》译者(谷歌前SRE)作序力荐,ThoughtWorks资深技术专家冯文辉倾情献译。

 

√ 不仅涵盖对服务中断的反应——揭示安全测试和发布软件所需的工具和策略、制订长期增长计划,还预测了未来的瓶颈所在,完整覆盖网站全线全周期危机。

 

√ 全书系统呈现由冗余和容灾|容量规划|系统自动保护|失败预案|监控能力|发布与变更管理|故障应急处理等领域核心话题构成的SRE技术蓝图。


展开
作者简介

Nat Welch是一名美国的软件开发人员。自2005年以来,他一直做着网站构建及运维的工作。他热爱网站的基础设施建设,因为这可以支持其他人的创造性努力。2012年,Nat成为谷歌的SRE(Site Reliability Engineering,站点可靠性工程)工程师,并爱上了这个职业。从那时起,他在各种规模的公司工作过,并一直致力于提高网站的可靠性,以帮助开发人员构建可靠的系统。


关于审查者

Pavlos Ratis是HolidayCheck的一名SRE工程师,负责自动化软件和基础设施的可靠性。随着时间的推移,他参与了大量的项目,并参与过从编写软件到自动化,管理基于云的多服务器基础设施,到开发Web应用程序等很多环节。


展开
内容介绍

站点可靠性工程(Site Reliability Engineering,简称SRE)是一个令人兴奋的新兴领域,它专注于如何确保系统稳定、可靠地运行。本书基于一个金字塔层次结构模型,深入浅出地介绍了关于SRE的方方面面,涉及监控、事故响应与回顾、测试与发布、容量规划、开发、用户体验设计,以及贯穿其中的沟通技巧。

本书是SRE工程师、DevOps工程师、运维工程师和系统管理员不可或缺的参考资料;软件架构师、软件工程师、用户体验设计师也能从本书中获取关于SRE的相关知识。

展开
精彩书评

推荐序一

近20年是互联网技术飞速发展的20年。互联网技术框架从单机、一体机演进到分布式的多层、多组件架构,原本由5个以内的技术组件构建的业务系统,到今天可能要有上百个技术组件来构建。为了在较低的成本基础上保障服务的扩展能力,很多互联网企业放弃了稳定性更强但也更昂贵的商业技术,转而使用开源、自研的技术。互联网业务的快速发展不仅直接带来了流量、安全等方面的不确定性,同时也促进了技术架构的快速演进——技术架构变得越来越复杂,而这些因素都将导致系统不可用发生概率的大幅度提升。当人类的工作、生活变得越来越依赖互联网时,一旦网站系统不可用,其造成的影响和损失就将难以想象:在远古时代,人类能够习惯没有自来水,也没有电的生活;但今天如果停水、停电,很多人都会无法适应。

互联网正在逐步演变成像供水、供电设施那样的基础设施,网站系统的可用性变得至关重要。在这样的大背景下,SRE的概念被提了出来,随着互联网在各行各业的深度渗透,SRE快速发展成了一个热门领域。几年前大家对SRE的概念还停留在Google对它的简单介绍上,如今,国内的一大批互联网企业都在尝试构建自己的SRE体系,SRE逐渐成为互联网企业的标配,该领域也迎来了百花齐放的盛况。阿里巴巴也正是在这个阶段构建了自己的SRE体系,其为阿里集团业务和云客户业务持续提供通用的高可用技术产品、解决方案的方法论,以及专业化的业务可用性运维能力。

任何事物的发展、壮大都需要有相应的方法论进行指引。SRE首先是一套方法论,它从传统运维中将与稳定性相关的工作内容提炼出来进行升华,构建了SRE的方法论体系。冗余和容灾、容量规划、系统自动保护、失败预案、监控能力、发布与变更管理、故障应急处理等构成了SRE领域的蓝图,并不断地快速迭代着。方法论的落地实施离不开相关组织和个人,传统的运维工程师在SRE方法论的熏陶下在系统可用性方面的技能得到了极大的提高,其中一部分传统运维工程师“进化”成了技术含金量极高的SRE工程师,他们聚合在一起,构成了专职的SRE团队。同样,方法论的落地还需要有一系列配套的技术产品和工具来支撑,与SRE相关的技术体系在近几年也得到迅速发展,特别是随着AI技术的发展、演进,两者结合产生了奇妙的“化学反应”,使系统可用性保障的效率和性能都获得了极大的提升。

本书是一本SRE指南手册,它不仅完善地介绍了与SRE相关的理论体系,还从实践的维度阐述了SRE的技术体系应该如何构建。对于关注网站可靠性的研发和运维人员,或者其他想深度了解SRE的技术人员来说,这是一本非常值得阅读的参考书。

阿里巴巴高可用架构团队负责人 游骥

 

推荐序二

在我看来,SRE是指导网站系统稳定性得到保障和落地的佳实践方案,没有之一。

这套方案源自Google及国外先进互联网企业的实践,以及在其实践基础上提炼出来的宝贵经验;Google将这套方案推广分享到业界,得到了业界很多企业的尝试和应用,且都取得了很不错的效果;这套方案经过了非常广泛的实践检验,包括我们自己也在不断地对其实践和检验着。

坦率地讲,对于Google SRE中所涉及的技术,业界绝大多数企业都是学不来的,主要原因在于业务类型及业务规模相差巨大。但是, SRE的很多指导原则,却适用于不同的企业和业务场景。

这其中我认为,SLO和事后回顾是核心内容,SLO可以帮助我们设定开发和运维人员需要共同遵守的指标,包括围绕SLO应该如何设定相应的流程、机制和决策原则等。事后回顾告诉我们,“故障是常态,正常才是异常”,所以面对故障,我们更多的应该是从中进行学习和改进,把故障作为提升系统性能的切入点,而不是故障之后的相互指责和推诿扯皮。

本书给出了指导原则之外的更多细节介绍和实践方法,可以说是在现有的SRE知识体系下,针对SRE内容的非常好的补充。

开卷有益,希望本书能够带给业界更多的指导意义。

蘑菇街 平台技术总监 赵成

 

推荐序三

自从2015年有幸负责翻译并推广《SRE:Google运维解密》一书以来,SRE理念已经逐渐从运维圈走向了更为广泛的IT圈,也逐渐从互联网企业文化圈传播到了传统行业的IT文化圈,这是非常令人振奋的事情。

自《SRE:Google运维解密》成书以来,我已经有幸受邀与各行各业的运维主管、技术负责人等进行了十几次极有启发性的交流。运维人员长期面临着责任重、压力大、成长难的问题;云平台、电商的抢购和秒杀活动、视频网站等新业务的飞速发展带来了优秀的高流量、高并发的业务需求;而大数据、人工智能、机器学习等新技术的大量使用,则意味着指数级增长的资源管理需求;越来越精细的运营环境意味着对系统稳定性及其他性能的要求也越来越高。传统的运维技术、思路、方法论、组织结构已经不再适用。SRE理念作为Google对业务运维体系的反思与整理,不仅梳理了在新业务形态下运维人员应该承担的责任,更给运维人员指明了一条职业发展路线。

运维人员常常熬夜甚至通宵工作,天天救“火”,却只能作为执行者,无法真正从“火灾”隐患中走出来。在这样的情况下,研发自动化工具,对内提供服务平台来应对业务的飞速增长;关注有效监控与有效警报,将业务系统白盒化、透明化,甚至达到故障自愈、无人运维的状态。这样运维人员才能解放出更多的精力,从而去关注更高层次的系统性能架构调优、容量的规划与制备等。

与《SRE:Google运维解密》一样,本书也是由Google前SRE工程师写成的,它们相互辉映,互相补充。本书将SRE理念与当下普遍、流行的开源技术、开源软件相结合,理论指导实践,实践检验理论,内容翔实,值得运维人员仔细阅读。也希望本书能将SRE理念带给更多的从业人员,共勉。

《SRE:Google运维解密》译者  孙宇聪

展开
目录

1  简介  1

SRE简史  2

SRE是什么  3

关于这本书  7

以SRE作为新项目的框架  9

小结  12


2  监控  13

为什么要监控  13

检测应用程序  16

度量什么  23

SLI、SLO和错误预算简介  26

错误预算  27

收集和保存监控数据  29

轮询应用程序  29

推送应用程序  32

展示监控信息  35

任意查询  35

图表  36

仪表板  37

聊天机器人  38

管理和维护监控数据  38

沟通  39

他们知道有监控吗  39

小结  40

参考资料  40


3  事故响应  42

什么是事故  43

什么是事故响应  45

警报  47

什么时候发起警报  48

怎么发出警报  49

向谁发出警报  54

随时待命  55

沟通  57

事故指挥系统  59

在哪里沟通  61

恢复系统  61

警报解除  63

小结  64


4  事后回顾  65

什么是事后回顾  65

为什么写事后回顾报告  66

何时写事后回顾报告  68

开展事故分析  69

如何写事后回顾报告  71

总结  71

影响  72

时间  73

根本原因  74

行动项  75

附录  77

停止事后指责  77

举行事后回顾会议  79

分析以往的事后回顾报告  80

MTTR与MTBF  81

警报疲劳  81

讨论过去的服务中断  81

小结  82

参考资料  82


5  测试和发布  83

测试  84

测试内容  87

发布  100

何时发布  101

回滚  104

自动化  104

持续  105

小结  106


6  容量规划  107

企业财务简介  108

为什么需要规划  110

风险管理与期望管理  111

定义一个规划  112

当前的容量是多少  113

何时达到容量极限  115

应该如何更改容量  119

执行规划  125

架构——性能变化的根源  126

技术作为利润中心和采购  128

小结  128


7  构建工具  129

寻找项目  131

定义项目  133

RDD  133

设计文档  136

项目计划  138

例子  139

回顾会与站会  141

工作分配  142

构建项目  143

关于编写代码的建议  143

关注点分离  144

长期工作  145

笔记本  148

文档与维护项目  149

小结  150


8  用户体验  151

设计和用户体验简介  155

现实世界的交互设计  157

用户测试  160

挑选一种体验  161

设计测试  162

寻找要测试的人  162

开发者体验  163

工具经验  164

绩效预算  164

安全性  166

身份认证  167

授权  168

风险概况  168

网络钓鱼  169

ACM道德准则  170

小结  171

参考资料  172


9  网络基础  173

互联网  173

发送一个HTTP请求  175

DNS  175

以太网和TCP/IP  179

HTTP  186

curl与wget  189

网络监控工具  194

netstat  194

nc  195

tcpdump  196

小结  197

参考资料  197


10  Linux和云基础  198

Linux基础  198

一切皆是文件  199

进程是什么  206

syscalls  207

构建自己的工具  213

云基础  214

虚拟机  215

容器  216

负载均衡  218

自动伸缩  219

存储  219

队列与发布/订阅  220

伸缩单元  221

架构面试示例  222

小结  226

参考资料  226

展开
加入书架成功!
收藏图书成功!
我知道了(3)
发表书评
读者登录

请选择您读者所在的图书馆

选择图书馆
浙江图书馆
点击获取验证码
登录
没有读者证?在线办证