《SRE：Google运维解密》

编辑推荐

　　√超级畅销书，国外在线书店长居前列，打标#1BestSeller
　　√运维高烧不退，谷歌神书问世，继续为这一热潮推波助澜
　　√《SRE：Google运维解密》解密全球神秘又让人仰望的技术岗位——谷歌SRE
　　√未出先火，《SRE：Google运维解密》原著问世时各大社区火爆异常、人气爆棚

内容简介

作者简介

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

　　ChrisJones，是GoogleAppEngine的一名SRE。GoogleAppEngine是一个PaaS服务，每天处理超过280亿个请求。他的办公室在旧金山，他之前的工作包括Google广告统计、数据仓库，以及用户支持系统的维护。在之前，Chris曾经在学校IT行业任职，同时参与过竞选数据分析，以及一些BSD内核的修改。他有计算机工程、经济学，以及技术政策学的学位。同时他也是一名有执照的职业工程师。

　　JenniferPetoff，是GoogleSRE团队的一名项目经理，工作地点在都柏林，爱尔兰。她曾经负责管理大型全球项目，包括：科学研究、工程、人力资源，以及广告等。Jennifer在加入Google之前，曾在化工行业任职八年。她获得了Stanford大学的化学博士与学士学位，同时她还拥有Rochester大学的心理学学位。

　　NiallMurphy，是Google爱尔兰团队广告SRE的负责人。他拥有20年互联网行业经验，目前是INEX（爱尔兰网络互联枢纽）的主席。他曾经写作以及参与写作很多科技文章与书籍，包括O’Reilly出版的IPv6NetworkAdministration，以及很多RFC。他目前在参与书写爱尔兰互联网发展史。他拥有计算机科学、数学，以及诗歌学的学历（他当时一定是想错了！）。他目前与妻子和两个儿子居住在都柏林。

　　孙宇聪，前GoogleSRE（2007-2015），山景城总部，曾参与构建运维Youtube全球CDN网络，2008年奥运会直播项目，构建维护海量视频编码传输系统。后参与Google内部云平台运维工作，负责运维全球百万级别服务器集群，以及Borg、Omega等大规模集群理系统。2015年加入Coding，任CTO一职。回国后，积极推动国内容器化运维架构升级。目前是开放运维联盟之应用运维规范制定组，高可用运维规范制定者。

精彩书评

　我们都知道Google公司的分布式系统设计和实现在业界遥遥领先，这些分布式系统多年前就已经运行在百万台服务器上，很多公司也都在觊觎这么多服务器是如何运行和管理的。《SRE：Google运维解密》揭开了这层神秘的面纱，SRE就是运行和管理这百万台服务器和众多分布式系统的关键。
　　多年前，Google是通过发布技术论文帮助业界解决分布式难题的，如今各种分布式系统百花齐放，如何管理这些系统对传统的运维技术和理念产生了极大的挑战，现在Google给我们带来了技术指导和实践。该书汇集了Google多年生产环境的管理经验，连编写工作都采用了分布式实现的方法，由各个领域的资深专家联合创作而成。可以把《SRE：Google运维解密》看作是一座灯塔，很多公司的集群规模还远达不到Google的规模，但是参照《SRE：Google运维解密》中的技术指导和实践，不仅可以加速传统运维向SRE的进化，更重要的是可以帮助公司高效地运维和管理各种复杂的分布式系统。
　　——吕宏利，GoogleAdsSRE
　　
　　信息技术领域是英文缩写词的高产领域，几乎所有的新概念、新技术和新产品的推出甚至一场市场营销的策划都会伴随着新的英文缩写词的出现。SRE这个缩写，在公司内部不仅代表了一个全新的运维理念和其伴随的崭新的工程领域、一套完整的系统运维体系和其对应的实践，而且也是我和我的好朋友——《SRE：Google运维解密》的译者孙宇聪一起工作了数年的战斗集体。而《SRE：Google运维解密》的作者们也都是这个大集体中的师长和伙伴。
　　系统运维长久以来都依赖实践积累之上的口口相传，经验通常是领域从业者手里掌握的秘诀。《SRE：Google运维解密》从实践出发，汇集了众多业内优秀的系统运维人员的实战心得，理论基础和实操指导并重，系统化地阐述了在新一代信息系统架构（大规模、分布式、高并发、多业务、多租户）下系统运维的理念（当前被广泛接受并被大量实践的DevOps就起源于此）、思路、实践以及对应的组织架构和人员管理的方方面面，是系统运维领域从业人员不可多得的参考和学习资料。《SRE：Google运维解密》是对新时代系统运维领域实践的总结和理论升华。
　　《SRE：Google运维解密》的译者孙宇聪在生活中是一个略显粗犷的大男人，但对于《SRE：Google运维解密》的翻译，他充分发挥了自己在这个领域中多年的从业经验和对系统运维的深刻理解，细致入微地做到内容和语言两个方面的精准和优美，这在翻译的技术图书中是非常难得的。
　　——张矩，锋瑞资本执行董事，前GoogleSRE
　　
　　很高兴受译者孙宇聪邀请为该书写推荐序，这《SRE：Google运维解密》是Google的SRE部门多年实践的总结，孙宇聪本人也在GoogleSRE部门工作多年。SRE部门在Google真正落实了DevOps。SRE工程师在Google不只是维护各种线上服务的稳定性，还要负责保证各项服务的性能，同时负责管理维护数据中心。美国多家互联网公司都在依照Google的方式来组织和运作SRE部门，可以说SRE被Google发扬光大，Google的SRE实践正在成为DevOps的标准。
　　SRE和传统的IT运维有很大区别，SRE真正实现了DevOps：首先，SRE深度参与开发阶段的工作，对应用程序的设计实现方式、依赖库、运行时的资源消耗都有严格的规约；其次，SRE工程师本身也要做不少编程工作，来实现各种工具用以自动解决问题和故障，换句话说，SRE强调的是对问题和故障的自动处理，而非人工干预；再者，按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己开发的程序更熟悉，易于处理程序上线过程中遇到的问题。总之，作为Google的DevOps实践，SRE非常注重开发和运维职能的结合，极大地加快了业务应用迭代周期，提升了IT对业务的支撑能力。
　　随着DevOps在国内的宣传推广，国内的很多企业客户也逐渐接受了DevOps的理念，但是在具体落地实践DevOps的过程中缺乏实际案例作为参照。《SRE：Google运维解密》的推出，方便了国内广大IT人员在落地DevOps过程中参照Google的SRE实践。非常感谢孙宇聪把这么好的一《SRE：Google运维解密》翻译成中文。
　　——王璞，数人云创始人
　　
　　Google首次创造了SRE这个职业，并将其SRE思想体系和方法论贡献出来汇集成此书。中文版的及时出版，使得国内广大运维从业者可以更高效地赏阅并实践。很荣幸此书在GOPS全球运维大会首发，高效运维社区将继续作为GoogleSRE国内第1传播平台，推进其和《互联网应用运维框架及能力模型》（《SRE：Google运维解密》译者孙宇聪先生联合撰写）的融合，促进其在中国运维行业的落地生根、蓬勃发展。
　　——萧田国，高效运维社区发起人，开放运维联盟联合主席
　　
　　从接触GoogleSRE的概念开始，就感受到它神秘地存在，直到看到英文版的SRE书籍，才知道它对传统运维的颠覆性。《SRE：Google运维解密》的面世，让国内更多的运维人员接触到Google先进的运维理论与实践。个人坚信这种理论和实践的提升与改变，才是运维人的出路，运维的业务价值、行业价值便也随之而来。运维也可以“高大上”地存在！
　　——王津银，“精益运维”发起人；优维科技创始人；开放运维联盟发起人之一；开放运维联盟应用标准规范组组长、起草人
　　
　　

目录

前言　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
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
最小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
加标签　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
负载均衡：虚拟IP　194
第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
Cron　273
介绍　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
……
第27章　可靠地进行产品的大规模发布　322
……
第Ⅳ部分　管理
第28章　迅速培养SRE加入on-call　341
……
第29章　处理中断性任务　355
……
第30章　通过嵌入SRE的方式帮助团队从运维过载中恢复　363
……
第31章　SRE与其他团队的沟通与协作　370
……
第32章　SRE参与模式的演进历程　383
……
第Ⅴ部分　结束语
第33章　其他行业的实践经验　398
……
第34章　结语　408
附录A　系统可用性　411
附录B　生产环境运维过程中的最佳实践　412
附录C　事故状态文档示范　417
附录D　事后总结示范　419
附录E　发布协调检查列表　423
附录F　生产环境会议记录示范　425
参考文献　427
索引　439

精彩书摘

　　译者序
　　当我在2016年年初听说《SRE：Google运维解密》的英文版即将面世时，第一时间就意识到这将是一本不可多得的经典之作。我作为GoogleSRE曾经的一员，看到《SRE：Google运维解密》中提到的那些熟悉的技术和理念时非常兴奋——现在终于有机会用一种体系化、结构化的方式将这些知识和技术与大家分享了！
　　GoogleSRE全球共计约1000人，负责运维Google的大部分家喻户晓、不可或缺的商业应用。同时，SRE还负责运维幕后那些全球首屈一指的计算基础设施，不管是全球百万台级别的服务器集群，还是全球一流的网络架构，背后都有SRE的身影。每个小的传统运维问题在这个平台上似乎都被无限放大了。但是与此同时，Google恰恰又是利用最传统、最朴素的软件工程方法将其一一解决的。
　　SRE是一群天生的怀疑论者，我们怀疑一切宣传起来“高大上”的技术，以及任何“神奇”的产品——我们只想看具体的设计架构、实现细节，以及真实的监控图表。SRE在保障系统可靠性方面并没有什么万能药，有的只是这种极强的务实态度（pragmatic）。这种务实的态度决定了SRE会认真对待运维问题。在设计评审中，他们会认真推演各种灾难场景。在每周例会时，他们又会讨论如何消除和防范事故发生、优化各种警报策略以及增强自动化功能。在平时工作中，他们则会精心维护团队的各种文档和项目源代码，一点一点地提高服务质量。回头看来，SRE其实是一群崇尚工匠主义的人，我们坚信只要不断地解决根源问题，服务质量就一定会得到提升。而SRE正是用这种“日拱一卒”的方法造就了Google这个世界级的奇迹。
　　《SRE：Google运维解密》的风格亦是如此。书中很多章节用务实的语言记录了GoogleSRE团队在面临各种困难时的思考过程、所采用的解决方案以及事后总结的经验教训。《SRE：Google运维解密》中没有介绍任何“魔法系统”，也没有提供任何“奇技淫巧”，有的只是对问题本质发人深省的深入探讨。从这种意义上讲，《SRE：Google运维解密》体系化地覆盖了运维工作的方方面面，是一本运维行业的教科书。我希望通过翻译此书，能将这种体系和理念分享给更多的人。期待与大家更深入地探讨与交流！
　　回首在Google度过的8年时光，我想感谢我所有的前同事，感谢他们对我的各种帮助，这段职业经历是我终生难忘的。而且，我还要感谢我的家人，是他们的耐心陪伴和帮助才让我踏踏实实地度过了这200多个小时，完成了我人生中最大的一个Project。
　　孙宇聪
　　2016年8月3日傍晚

前言/序言

　　如果用一个词语来描述Google的历史，那就是不断地“扩大规模”（scalingup）。Google的成长经历，是计算机行业中数一数二的成功故事，标志着整个社会向IT为中心的商业模式的转变。Google很早就开始实践IT与商业模式的结合，也是向社区推广DevOps理念的先行者。《SRE：Google运维解密》就是由来自公司各个部门，切身参与甚至主导了整个行业转型实践的人写成的。
　　Google是在一个系统运维工程师行业转型的阶段发展壮大的。Google的发展史就像是对传统的系统运维理念发出的革命宣言：我们无法按照传统方式运维Google系统，必须要思考一种新的模式，但是同时我们也没有时间等待其他人验证和支持我们的理论。在PrinciplesofNetworkandSystemAdministration（参见文献[bur99]）一书的介绍中，我提出了一种观点：系统运维本质上是人与计算机共同参与的一项系统性工程。当时的一些评论者对这种观点表示了强烈的反对：“这个行业还远远没有成熟到可以称为一项工程”。在那时，我甚至对整个运维行业产生了怀疑，认为这个行业在个人英雄主义与神秘色彩中已经永久地迷失了自己，无法前进。但是，这时Google诞生了，Google的高速发展将我的预言变成了现实。我之前的定义变成了一个具体的词语：SRE，站点可靠性工程师。我的几个朋友切身参与了这个新职业的创立，用软件工程理念和自动化工具定义了这个行业。一开始，他们显得很神秘，Google公司内的体验和整个行业也格格不入，Google太特殊了！随着时间的推移，公司内外交流逐渐增多。这《SRE：Google运维解密》的目标就是将SRE的一些思考和实践带给整个行业，以促进交流。
　　在《SRE：Google运维解密》中，我们不仅仅展示了Google是如何建设维护其富有传奇色彩的大型计算集群的。更重要的是，我们展示了在建设过程中，Google工程师团队是如何学习、成长、反复修改，zui后定义出一套完整的工具和科技体系的过程。IT行业大多自我封闭，交流过少，很多从业人员都或多或少地受教条主义的限制。如果Google工程师团队能克服这个惯性，保持开放的精神，那么我们也能够一起和他们面对IT行业内zui尖端的挑战。
　　这《SRE：Google运维解密》由一群有共同目标的Google工程师写就的短文组成。《SRE：Google运维解密》的作者们聚集在同一个公司旗下，为了同一个目标努力，本身就是一件很特别的事情。在《SRE：Google运维解密》的各个章节之间经常能看到软件系统的共同点，以及工作模式上的共通之处。我们经常可以从多个角度分析不同的决策选择，了解他们是如何一起解决公司内部多种利益冲突的。这些文章并不是严谨的学术研究论文，而是这些人的切身经历。虽然《SRE：Google运维解密》的作者们有着不同的工作目标、写作风格，以及技术背景，但是他们都尝试着去真诚地描述自己遇到的问题和解决的经历。这和IT行业内的普遍文风截然不同，风格迥异。有些作者会宣称：“不要做A，只有做B才是正确的。”另一些作者会更谨慎，行文更富有哲学性。这其实恰恰代表了整个IT行业内不同个性融合的现状。而我们作为读者，作为观察者，并不了解整个Google的历史，也没有参与到具体的决策过程中，无法全面了解当事人所面临的纠缠不清的挑战，只能带着谦逊的态度远远旁观。在阅读《SRE：Google运维解密》的过程中，相信读者一定会产生出许多疑问：“他们当时为什么没有选择X？”“如果他们选择了Y，结果会是怎样？”“如果多年之后回头再看，这个选择会是正确的吗?”这些问题，恰恰是阅读《SRE：Google运维解密》的zui大收获，因为我们第1次有机会将自己的经历、选择和《SRE：Google运维解密》陈列的决策逻辑相互对应，从中发现不足和缺陷。
　　这《SRE：Google运维解密》的成书过程也堪称奇迹。今天，我们能感受到整个行业都在鼓吹厚颜无耻的“代码拿来主义”（justshowmethecode）。开源软件社区内部正在形成一种“不要问我问题”的风气，过于强调平等却忽略领域专家的意见。Google是行业内为数不多的，愿意投入精英力量钻研本质问题的公司，而且这些公司精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件，用来链接日益庞杂的软件、人和海量的数据。这《SRE：Google运维解密》中没有万能药，没有什么东西能解决一切问题，但是这恰恰是《SRE：Google运维解密》的宗旨：相比zui后的软件结果、架构设计而言，真实的设计过程、作者本身的思考经历更有价值。实现细节永远只是短暂存在的，但是文档化的设计过程却是无价之宝。有机会了解到这些设计的内幕真是太难得了！
　　这《SRE：Google运维解密》，归根到底，记录了Google这个公司的成长经历。书中的很多故事都是由相互重叠的故事组成的，这恰恰说明了扩展一个计算机系统，要比简单按照书本上的标准架构放大困难得多。一个公司的成长，意味着整个公司商业模式和工作模式的扩展，而不是简单的资源扩张。仅此一点，这《SRE：Google运维解密》就物超所值了。
　　自省，是一个在IT行业内部并不流行的词语。我们不断重复发明各种系统。很多年以来，只有USENIXLISA大会论坛以及其他几个专注于操作系统的会议会讨论一些IT基础设施的设计和实现。很多年后的今天，IT行业已经天翻地覆，但是《SRE：Google运维解密》仍然弥足珍贵：它详细记录了Google迈过分水岭时期的全过程。很显然，这些经历没有办法完全复制，也许只能被模仿，但是却可以启发读者，指引未来。《SRE：Google运维解密》作者们表现出了极大的真诚，显示了谦逊的风格，以及极强的凝聚力、领导力。这些文章记录了作者们的希望、担忧、成功与失败的经历。我向这些作者们和编者们的勇气致敬，正是这种坦率，让我们能够作为旁观者和后来人，从前人的经历中学习到zui宝贵的知识。
　　MarkBurgess
　　InSearchofCertainty一书作者
　　Oslo，2016年3月
　　序言
　　软件工程有的时候和养孩子类似：虽然生育的过程是痛苦和困难的，但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是，传统软件工程专业花费了很多精力讨论软件的开发过程，而不是其后的维护过程。有统计显示，一个软件系统的40%~90%的花销其实是花在开发建设完成之后不断维护过程中的。行业内流行的一个说法是：一个系统如果已经开发完成，部署在生产环境上，那么它就是“稳定的”，就不需要那么多工程师花费精力去优化、维护。我们认为这个说法是错误的。从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，zui后顺利退役。这样一种职业必须具备非常广泛的技能，但是和其他职业的专注点都不同。Google将这个职位称为站点可靠性工程师（SRE，SiteReliabilityEngineering）。
　　那么，站点可靠性工程师究竟代表着什么呢？的确，这个词语并不能够特别清晰地描述这个职位的意义。基本上每个GoogleSRE都会被经常问到这个职位到底代表什么意思，以及他们的日常工作究竟是什么。
　　将这个词语展开来说：首先，也是zui重要的一点，SRE是工程师（engineer）。SRE使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统。有的时候，SRE和产品研发团队共同工作，其他时候我们需要开发这些系统的额外组件：例如备份系统和负载均衡系统等。理想情况下，同时推进这些组件在多个项目中复用。还有的时候，我们的任务是想出各种各样的办法用现有组件解决新的问题。
　　其次，SRE的关注焦点在于可靠性。BenTreynorSloss，Google负责7×24运维的副总裁，SRE名称的发明者，宣称可靠性应该是任何产品设计中zui基本的概念：任何一个系统如果没有人能够稳定地使用，就没有存在的意义。因为可靠性是如此重要，因此SRE专注于对其负责的软件系统架构设计、运维流程的不断优化，让这些大型软件系统运行得更可靠，扩展性更好，能更有效地利用资源。但是，SRE并不是无止境地追求完美：当一个系统已经“足够可靠”的时候，SRE通常将精力转而投入到研发新的功能和创造新的产品中。
　　zui后，SRE的主要工作是运维在分布式集群管理系统上运行的具体业务服务（service）。不论是遍布全球的存储服务，还是亿万用户赖以工作的E-mail服务，还是Googlezui初的Web搜索服务。SRE中的“S”zui开始指代的就是google.com的运维服务，因为SRE的第1个工作就是维持网站的正常运转。随着时间的推移，SRE逐渐接管了Google内部绝大部分产品系统，包括GoogleCloudPlatform这类开发者平台，也包括内部的一些非网站类的基础设施系统，例如Bigtable。
　　虽然我们在这里将SRE的职位定义得比较宽泛，但是在这样一个互联网业务高速发展的时代，这个职位的出现毫不奇怪。同样，虽然在应用系统运营维护的过程中有数不清的重要环节需要关注，我们zui关注的是“可靠性”这一点也不奇怪。在Web服务领域里，对服务器端软件的优化和修改是相对可控的，变更管理与生产安全又结合得非常紧密，一种类似于SRE的职业早晚会在这个环境下诞生。
　　虽然SRE这个行业是在Google内部，从Web社区中诞生的，但我们认为这个职业对其他团队和组织也有很多值得借鉴的地方。《SRE：Google运维解密》是对阐述SRE发展过程的一次尝试：我们既希望将这些宝贵经验共享给其他相关行业，也希望能从其他行业中汲取知识，从而更好地定义各种角色和术语。为了这个目的，《SRE：Google运维解密》将通用的理论、设计理念和思想，与实际的应用工具介绍等分开。在某些需要结合Google内部信息讨论主题的时候，我们相信读者可以进行类比，将书中的理念与自己的实际环境相结合，以便得出更为有效的结论。《SRE：Google运维解密》中也包含了一些对Google内部生产环境的介绍，将Google内部环境与外部常见的开源类软件相对应。这样可以让《SRE：Google运维解密》的一些设计理念与实践的结合度更强，应用起来更容易。
　　zui后，我们当然希望社区内出现更多、更可靠的软件系统。我们知道，创业企业甚至中型企业经常对如何应用这些理念和技术感到困惑。可靠性就像安全性，越早关注越好。这就意味着一些小型创业公司，在应付日常面临的种种挑战时，也应该抽出一部分精力来面对可靠性这个话题。这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多。《SRE：Google运维解密》第4部分着重介绍了SRE团队如何进行内部培训、如何加强内部沟通等zui佳实践，很多都可以直接拿来应用。
　　对中型企业来说，企业内部可能已经有这样的一组人在做着与SRE非常类似的工作。这些人可能并不叫SRE这个名字，甚至可能没有受到管理层的重视。在这样的企业中，提高可靠性zui好的办法往往就是去认可这些人的工作，并配备足够的激励机制。在牛顿被世界正式认可为物理学家之前，他经常被称作是zui后的炼金术师。而这些专注于可靠性的工程师们，正如当年的牛顿一样，是一个新时代的开拓者。
　　如果一定要为SRE寻找一个起源的话，谁才能够被称为世界上第1个SRE呢？我们选择了MargaretHamilton，MIT教授，参与了阿波罗登月计划的软件开发工作。她的工作具有现代SRE的一切特性。用她自己的话来讲：“团队文化就是从一切经历中不断学习，包括来自那些我们zui意想不到的地方的经历。”
　　在Apollo7飞船研发期间的某一天，Margaret带着她的小女儿Lauren一起来到公司。在Margaret忙着和组员们在大型计算机上运行飞行模拟测试的时候，她的小女儿偷偷地按下了控制台上的DSKY键。整个模拟程序出乎意料地崩溃了，导致整个火箭发射程序意外终止。Margaret和组员调试后发现，原来Lauren意外触发了P01这段子程序的执行，导致了整个模拟过程的失败。（该子程序是起飞前调试程序，执行时会删除现存的导航信息，如果在火箭飞行过程中执行这段程序，计算机将无法继续维持火箭航线，后果将是灾难性的。）
　　凭借着SRE的直觉，Margaret为项目组提交了一个软件改动，申请在飞行程序中增加一项特殊状态检查，以避免飞行员在飞行过程中意外触发P01程序的执行。但不幸的是，NASA管理层认为，这项错误发生的可能性太小，根本不值得为此添加这项修改。于是Margaret没有能够成功提交这项软件修改。她只能在火箭飞行手册中添加了一段文字，写道：“在飞行过程中，请勿触发P01程序。”（当时增加这段文字时，很多NASA工程师都认为这很好笑，认为Margaret是小题大做，几乎所有人都认为宇航员经过如此长时间的专业训练，是绝对不会犯如此低级的错误的。）
　　几天后，在Apollo8飞船执行下一项飞行任务时。宇航员JimLovell、WilliamAnders和FrankBorman三人执行一个长达四天的飞行计划途中，JimLovell意外地触发了P01程序的执行。更巧的是，当天正好是美国圣诞节，大部分工程师都休假去了。可想而知，当时NASA的一片混乱状态。这次不是演习，而是人命关天的危急时刻，如果不能及时解决，三名宇航员将永远无法安全返回了。所幸，当时Margaret的飞行手册更新中恰恰提到了这种情形，并且提供了重新上传数据以及恢复执行的有效办法，在有限的时间内解决了问题，使任务可以继续进行。
　　Margaret曾经说过：“无论对一个软件系统运行原理掌握得多么彻底，也不能阻止人犯意外错误。”在这次危机过后，Margaret之前提交的修改申请很快就被批准了。
　　虽然Apollo8的事故发生在几十年前，但是工程师们一定不会对此感到陌生，类似的场景总是在不断重演。希望读者以史为鉴，只有靠着对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。这就是SREzui重要的理念！欢迎加入SRE的大家庭！
　　如何阅读《SRE：Google运维解密》
　　这《SRE：Google运维解密》是由一系列短文组成的，由GoogleSRE成员和前成员共同写就。相比之下，这《SRE：Google运维解密》更像是一本会议文集。《SRE：Google运维解密》的每一章都可以作为一个独立部分进行阅读，但是读者也可以根据自己的兴趣选择某些章节重点阅读。（如果《SRE：Google运维解密》中引用了某些额外文章，你可以在参考文献中找到。）
　　读者可以按照任何顺序阅读《SRE：Google运维解密》，但是我们推荐从第2章和第3章开始。这两章描述了Google的生产运行环境，以及SRE是如何系统化认知与量化“风险”的（毕竟“风险”是SREzui关注的要点）。读者当然也可以选择逐章阅读，《SRE：Google运维解密》逻辑上分为以下几个部分：理念性介绍（第Ⅱ部分）、zui佳实践（第Ⅲ部分）和管理经验（第Ⅳ部分）。每一部分都配有简介，并且配有SRE成员以前发表的文章的引用地址。
　　最后，《SRE：Google运维解密》配有网站https://g.co/SREBook，其中包括了一些有益读物，希望读者能从中获得阅读的乐趣。
　　……