简介
- 书名：《SRE：Google运维解密》
- 作者： 贝特西·拜尔等
- 分类： 计算机-计算机综合
- ISBN：9787121297267
- 出版社：电子工业出版社
概述
在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。本书适合各种水平的运维工程师参考使用。
划线
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。
SRE就是运行和管理这百万台服务器和众多分布式系统的关键。
SRE强调的是对问题和故障的自动处理，而非人工干预；再者，按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己开发的程序更熟悉，易于处理程序上线过程中遇到的问题。
100%的可用性是不现实的，需要达到这个目标的成本通常远超于所能获得的价值，所以Google会针对每种产品设定一个错误预算（容错率），既能保证用户体验又不影响创新和部署的速度。
SRE是一群天生的怀疑论者，我们怀疑一切宣传起来“高大上”的技术，以及任何“神奇”的产品——我们只想看具体的设计架构、实现细节，以及真实的监控图表。
SRE其实是一群崇尚工匠主义的人，我们坚信只要不断地解决根源问题，服务质量就一定会得到提升。而SRE正是用这种“日拱一卒”的方法造就了Google这个世界级的奇迹。
本书体系化地覆盖了运维工作的方方面面，是一本运维行业的教科书。
更重要的是，我们展示了在建设过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。IT 行业大多自我封闭，交流过少，很多从业人员都或多或少地受教条主义的限制。如果Google 工程师团队能克服这个惯性，保持开放的精神，那么我们也能够一起和他们面对 IT 行业内最尖端的挑战。
今天，我们能感受到整个行业都在鼓吹厚颜无耻的 “代码拿来主义”（just show me the code）。开源软件社区内部正在形成一种“不要问我问题”的风气，过于强调平等却忽略领域专家的意见。Google 是行业内为数不多的，愿意投入精英力量钻研本质问题的公司，而且这些公司精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件，用来链接日益庞杂的软件、人和海量的数据。
一个公司的成长，意味着整个公司商业模式和工作模式的扩展，而不是简单的资源扩张
有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。[1]
从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。
有的时候，SRE 和产品研发团队共同工作，其他时候我们需要开发这些系统的额外组件：例如备份系统和负载均衡系统等。理想情况下，同时推进这些组件在多个项目中复用。还有的时候，我们的任务是想出各种各样的办法用现有组件解决新的问题。
这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多
团队文化就是从一切经历中不断学习，包括来自那些我们最意想不到的地方的经历。
只有靠着对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。这就是SRE 最重要的理念！欢迎加入SRE的大家庭！
不能将碰运气当成战略。
极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”
由于两个部门使用的语境不同，对风险的定义也不一致。
开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。
目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
所有的SRE团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。
（a）对重复性、手工性的操作有天然的排斥感。（b）有足够的技术能力快速开发出软件系统以替代手工操作。
SRE团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上
我们可以认为DevOps是SRE核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排。同时，SRE是DevOps模型在Google的具体实践，带有一些特别的扩展。
“错误预算”起源于这样一个理念：任何产品都不是，也不应该做到100% 可靠（显然这并不适用于心脏起搏器和防抱死刹车系统等）。一般来说，任何软件系统都不应该一味地追求100% 可靠。因为对最终用户来说，99.999% 和 100% 的可用性是没有实质区别的（详见附录A）
一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。
但是长久看来一个手持“运维宝典”经过多次演习的on-call工程师才是正确之路
由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的办法”而生
Google的大部分计算资源都存放在自主设计的数据中心中。这些数据中心拥有自己设计的供电系统、制冷系统、网络系统以及计算机硬件（参见文献[Bar13]）。
一个典型的Google数据中心的拓扑结构：● 约10台物理服务器组成了一个机柜（Rack）● 数台机柜组成一个机柜排（Row）● 一排或多排机柜组成了一个集群（Cluster）● 一般来说，一个数据中心（Datacenter）包含多个集群● 多个相邻的数据中心组成了一个园区（Campus）
因为一个集群中包括很多硬件设备，每天硬件设备的损坏量很高。在一年内，一个单独集群中平均会发生几千起物理服务器损坏事件，会损失几千块硬盘。
如果一个工程师遇到了他工作的项目之外的一个基础组件的问题，他可以直接修改这个问题，向管理者提交一份改动申请（changelist,CL），等待代码评审，最后直接提交。
任何对自己项目代码的改动也需要代码评审。
有些项目组甚至在实践自动部署机制：提交一个新版本，测试通过后，将直接部署于生产环境。
监控系统都是运维生产环境必不可少的组件。如果没有针对服务的监控，就无从得知目前服务的状态，如果不知道服务的状态，就无从谈起维护服务的可靠性。
极端的可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量。
尽管当时YouTube已经有了一个很出色的产品，但它仍然在不断变化和快速发展着。因此，我们为YouTube设定了一个相比我们企业的产品更低的可用性目标，因为快速发展更加重要。
一种在符合成本效益条件下满足这些竞争性约束的方式就是将基础设施分割成多个服务，在多个独立的服务水平上提供该服务。
对意外事件的容忍程度有多高？做得太少，我们就只能设计出一个脆弱无用的产品。做得太多，我们的产品可能没有人会使用（但运行非常稳定
SLI是指服务质量指标（indicator）—该服务的某项服务质量的一个具体量化指标。
如果系统正常运转中需要人工干预，应该将此视为一种Bug。
SRE的一个公开目标是保持每个SRE的工作时间中运维工作（即琐事）的比例低于50%。SRE至少花50%的时间在工程项目上，以减少未来的琐事或增加服务功能。
让我们多创新，少干琐事吧！
监控系统应该解决两个问题：什么东西出故障了，以及为什么出故障。
“现象”和“原因”的区分是构建信噪比高的监控系统时最重要的概念。
监控系统的4个黄金指标分别是延迟、流量、错误和饱和度（saturation）。
● 每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。● 每个紧急警报都应该是可以具体操作的。● 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。
-mail警报的价值通常极为有限，很容易变成噪声。我们应该倾向于构建一个良好的监控台页面，直接显示所有的非紧急的异常情况。
一致性地执行范围明确、步骤已知的程序—是自动化的首要价值。
在行业内普遍认同的是，在产品生命周期中一个问题越晚被发现，修复代价越高；
自动化是“元软件”，也就是操作其他软件的软件。
广泛使用的工具有Puppet、Chef、cfengine，甚至 Perl都提供了自动化完成特定任务的方法，主要区别在于对帮助进行自动化的组件的抽象层次不同。
如何管理包的版本？应该采用持续构建和部署的模型，还是应该定期构建？发布的频率应该怎样？应该使用什么策略管理配置文件？哪些发布过程的指标比较有用？
可靠性只有靠对最大程度的简化不断追求而得到。
我们的工作最终是在系统的灵活性和稳定性上维持平衡
有的时候为了灵活性而牺牲稳定性是有意义的。我在面临一个不熟悉的问题域时，经常进行“探索性编码”—给我写的任何代码设置一个明确的保质期，我清楚地知道自己需要先探索以及失败才能真正理解需要完成的任务。这种带保质期的可以在测试覆盖和发行管理上更宽松，因为它永远不会被发布到生产环境或被用户使用。
某种程度上，这与面向对象编程中的类设计类似：正如普遍认同的，编写一个其中包含无关功能的“大杂烩”类是一个糟糕的实践。构建和发布“util”或“misc”二进制文件同样也是个糟糕的实践。一个设计良好的分布式系统是由一系列合作者组成的，每一个合作者都具有明确的、良好定义的范围。
我们可以将一个服务的健康程度指标分为低级需求：能够正常对外提供服务，和高级需求：SRE能够主动控制服务状态，而不是被动救火。
[插图]
on-call轮值是很多运维和研发团队的重要职责，这项任务的目标是保障服务的可靠性和可用性。
SRE团队和纯运维团队十分不一样的地方在于，SRE团队非常强调用工程化手段来应对运维问题。而这些运维问题，当达到一定规模时，也确实只有采用软件工程化手段才能解决。
我们强调至少将SRE团队50%的时间花在软件工程上。在其余时间中，不超过25%的时间用来on-call，另外25%的时间用来处理其他运维工作。
1.对通用的故障排查过程的理解（不依靠任何特定系统）。2.对发生故障的系统的足够了解。
当所有的可能都存在的时候，我们应该优先考虑最简单的解释
更糟的是，随着系统部署规模的不断增加，复杂性也在不断增加，监控指标越来越多。不可避免的，纯属巧合，一些现象会和另外一些现象几乎同时发生。
在大型问题中，你的第一反应可能是立即开始故障排查过程，试图尽快找到问题根源。这是错误的！不要这样做
正确的做法应该是：尽最大可能让系统恢复服务。
在大型系统中，逐个检查可能太慢了，可以采用对分法（bisection）将系统分为两部分，确认问题所在再重复进行。
将你的想法明确地记录下来，包括你执行了哪些测试，以及结果是什么。[35]尤其是当你处理更加复杂的问题时，良好的文档可以让你记住曾经发生过什么，可避免重复执行。[36]如果你修改了线上系统，例如给某个进程增加了可用资源。系统化和文档化这些改变有助于将系统还原到测试前的状态，而不是一直运行在这种未知状态下。
东西早晚要坏的，这就是生活。
时间和经验一再证明，系统不但一定会出问题，而且会以没有人能够想到的方式出问题。
事故总控负责人最重要的职责就是要维护一个实时事故文档。该文档可以以wiki的形式存在，但是最好能够被多人同时编辑。大部分Google团队使用Google Docs，但是Google Docs 团队使用Google Sites做这件事：利用你正要修复的服务来修复该服务恐怕不是什么好主意。
Google团队依靠下面几个宽松的标准——如果下面任何一条满足条件，这次事故应该被及时宣布。● 是否需要引入第二个团队来帮助处理问题？● 这次事故是否正在影响最终用户？● 在集中分析一小时后，这个问题是否依然没有得到解决？
划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场。事前准备：事先和所有事故处理参与者一起准备一套流程。信任：充分相信每个事故处理参与者，分配职责后让他们自主行动。反思：在事故处理过程中注意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助
考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情。练习：平时不断地使用这项流程，直到习惯成自然。换位思考：上次你是事故总控负责人吗？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。
最佳实践：公开奖励做正确事的人
Google使用Outalator—一个故障跟踪工具来做这件事。Outalator系统被动收集监控系统发出的所有报警信息，同时提供标记、分组和数据分析功能。
如果你还没有亲自试过某件东西，那么就假设它是坏的。
合并通用型人才（generalist）和领域专家组成一个种子团队，通用型人才可以很快地开始工作，而资深领域专家可以提供更广阔的知识和经验。这样一个多样化的团队可以避免设计盲点。
每个项目都有正确的时间点来引入领域专家。
按照QPS来规划服务容量，或者是按照某种静态属性（认为其能指代处理所消耗的资源：例如某个请求所需要读取的键值数量）一般是错误的选择。
如何给新手带上喷气背包，同时保证老手的速度不受影响
[插图]图28-1：培养SRE加入on-call的计划图
这个团体活动，每个季度会进行一次，有助于在生产环境中发现亟待解决的新Bug—系统并不会像我们想象的那样优雅降级。
紧急警报主要是通过设置专门的主on-call工程师来处理的。也就是说，让一个工程师独立接收和响应紧急警报，处理发生的事故或者故障。
从某种意义上讲，人类可以被称为不完美的机器。人会感觉无聊，人的处理器（指思维方式）工作原理不清楚，用户界面（指沟通方式）也不太友好，效率也不高。
极化时间意味着当每个人来上班时，他们应该清晰地知道自己今天是否只是做项目工作，还是只是做中断性工作
工单处理应该由全职人员负责，同时保证占用合理的时间。如果团队目前的工单主oncall和副on-call都处理不完，那么需要重新架构整个工单的处理流程，保障任何时间都有两个全职员工处理工单。不要将复杂分散到整个团队中去。人不是机器，这样做只会干扰员工，降低他们的工作效率
如果团队中需要很多人同时进行中断性任务，那么可能这种负载是不能持久的。有一系列方式可以降低整体的工单负载。
第一阶段：了解服务，了解上下文
日益增加的工单不应需要更多的SRE来处理。SRE模型的目标是仅仅在系统复杂度上升的时候才增加新人。你应该尝试引导团队建立健康的工作习惯，这样能够减少花费在工单上的时间。这与指出该服务目前还可以自动化或者进一步简化同样重要。
对“未来的一件大事”的过度依赖
第二阶段：分享背景知识
书写一个好的事后总结作为示范
第三阶段：主导改变保持团队健康是一个持续的过程。正因为此，这不是你可以通过个人英雄主义来解决的问题。为了确保团队在未来可以进行自我调节，我们需要帮助他们建立一个良好的SRE心理模型。
● 从技术角度，最好是量化的角度指出团队需要改变的原因。● 提供一个详细、具体的“改变”作为例子。● 解释SRE经常采用的“常识”背后的逻辑推理过程。● 提供以可伸缩的方式来解决崭新情况所必需的核心理念。你的最后一个任务是书写一份报告。报告中应该重申你的观点、例子和逻辑推理过程。同时，该报告应该向团队提供一些待办事项，来保证他们会实践你所传授的东西。你应该将报告组织成一份检查报告[12]，解释成功路上的每一个重要的决策。
就像数据必须围绕生产流动那样，数据也要围绕SRE团队流动—关于项目的数据，关于服务状态、生产环境状态以及个人状态的数据。团队的最佳运行状态是，数据可靠地从一个感兴趣的团队流动到另一个团队。思考这种流动的一个方法是思考SRE团队与其他团队建立的接口API。和设计一个API一样，好的设计对于有效性是至关重要的。如果API的设计是错误的，后续改正它将是非常痛苦的。
。生产会议是一种特殊的会议。在这个会议中，SRE团队向自己—以及邀请的嘉宾—描述服务的目前状态。这样那些关心服务的人对服务状态的了解程度得到了提高，同时也能提高服务自身的运维质量。
一般来说，单人项目最终肯定会失败，除非此人个人能力超强或者待解决的问题是非常简单直接的。做成任何高价值的事情都需要很多人共同协作
因为人与人之间的沟通方式差异很大，第一次见面时书面表达习惯和口语表达习惯中隐含的微妙暗示很容易被误解。在项目开始之初，那些不在总部工作的团队成员经常会错过会议开始之前和结束之后立刻进行的即兴讨论（现在的沟通渠道已经大大改善了）。
其次，也许是最好的方式，与其创造很多各异的个体系统交给SRE运维，不如直接让研发团队在一个通过SRE验证的基础设施平台上进行产品开发。
最佳实践代码化将生产环境中运行良好的最佳实践代码化，这样服务可以通过简单地使用这些代码，自然而然地成为“生产就绪”。可重复使用的解决方案常见并易于共享的技术实现，用于改善可扩展性和可靠性的问题。带有通用控制界面的通用生产操作平台生产设施的统一接口，统一的运维控制机制，以及统一的监控、日志以及服务配置。更简易的自动化和更智能的系统通用的控制接口使自动化和智能化达到一个以前不可能达到的水平。例如，SRE可以用一个统一的视图查看关于一次故障的全部相关信息，不用收集和分析来自不同数据源的原始数据（日志、监控数据，等等）。
建立了一系列SRE支持的平台和服务框架
服务框架以一个标准化的方式实现了基础设施部分的代码并且预先解决了常见的各种生产问题
SRE通过构建框架模块来实现这些关注重点的标准解决方案。其结果是，因为该框架已经考虑了正确的基础设施的使用，所以研发团队可以更专注于业务逻辑的开发
● 究竟发生了什么● 响应的有效程度● 下次是否可以采用其他方案解决问题● 如何确保这次故障不会再次发生
纠结于“谁”造成了这个故障是没有意义的。事后总结在每次事故发生之后都会进行，同时会在整个SRE团队内部传阅，以便让所有人都能从中受益。
采用的标准是如果整个发电站需要在少于30分钟的时间内响应某种情况，那么这种响应必须要自动化进行。
某项决策的基本方向是事先决定的，而不是事后得出的。● 决策时考虑的信息源是清楚的。● 任何假设都应该明确说明。● 数据驱动决策要优于情感驱动的决策、直觉驱动的决策，以及资深人士的意见。
飞机上布满了非常可靠的、冗余度非常高的系统。这就是不断重视安全与可靠性的后果
高可用性、性能极度优化、变更管理、监控与报警、容量规划，以及应急处理。
越精简越好，他们所操作的东西应该更抽象而非更具体
[插图]
紧急警报某个人必须执行某项操作。工单某个人必须在几天之内执行某种操作。日志没有人会马上看这些日志，但是以后需要的时候可以用来分析。
每次on-call轮值应该处理不超过两起事故（平均每12小时1个）：
泄洪集群，
笔记
系统运维长久以来都依赖实践积累之上的口口相传，经验通常是领域从业者手里掌握的秘诀。
💭 人肉运维哈哈哈
我们无法按照传统方式运维Google系统，必须要思考一种新的模式，但是同时我们也没有时间等待其他人验证和支持我们的理论。
💭 适合自己的才是最好的
有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。[1]
💭 就像生孩子一样，十月怀胎一朝分娩，一辈子成人。
从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作。
💭 yaml 工程师哈哈哈
从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作。
💭 标准化，流程化，自动化
如果100% 不是一个正确的可靠性目标，那么多少才是呢？这其实并不是一个技术问题，而是一个产品问题。
💭 技术服务于客户
到底什么是琐事？琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。
💭 人肉运维哈哈哈
如果事先没有针对可能发生的紧急事故进行过演习，那么当事故发生时，一切管理理念都起不了作用
💭 演习，演习，还是演习。
我们将之前的某篇事后总结的场景再现，一批工程师负责扮演这篇文档中提到的各种角色。经常，当时的事故总控负责人也参与其中，确保这次演习越真实越好。 在引入事后总结机制
💭 事后总结
SRE团队最需要的就是技能的多样性，成员多元化的背景和多样化的解决问题的方式可以避免在团队中出现盲点。
💭 广度
不要过于关注完美和解决方案的纯粹性，尤其是当待解决问题的边界不够清晰时。我们应该更快地发布和迭代。
💭 更快的去做，更多的去尝试。知行合一！
Google SRE团队通过一个老传统—“故障处理分角色演习”来解决这些问题。这个活动同时也被称为“命运之轮”（wheel of misfortune）或者 “走木板”（walk the plank）等，这些名字对新加入的SRE来说不会那么吓人。
💭 沙盘模拟经营很重要！
为了限制干扰数量，我们应该减少上下文切换（指工作类型、环境等的改变）。某些中断性任务是无法避免的。然而，将工程师当成是可以随时中断、上下文切换没有成本是不正确的。给每次上下文切换加上成本的考虑。在项目工作中，一次20分钟的中断性任务需要进行两次上下文切换，而这种切换会造成数个小时的生产力的丧失。为了避免这种经常性的生产力丧失，我们应该延长每种工作模式的时间，一天甚至半天都可以。这种策略与“挤时间”（参见文献[Gra09]）策略工作得很好。
💭 上下文切换
SRE则恰恰相反。他们通过编写软件系统或者消除系统瓶颈的方法来解决这个问题。
💭 熵减
SRE团队陷入Ops模式的原因是过分关注如何快速解决紧急事件而不是如何减少紧急事件的数量。
💭 治标也要治本！
SRE团队成员拥有系统工程或架构能力（见文献[Hix15b]）、软件工程技术、项目管理能力、领导才能，各种行业背景的人都有（参见第33章）
💭 扫地僧
在本章中，我们会讨论到许多SRE的核心指导思想。为了简化与其他行业最佳实践的比较，我们将这些理念分为4大类： ● 灾难预案与演习 ● 书写事后总结的文化 ● 自动化与降低日常运维负载 ● 结构化的、理智的决策
💭 标准化，流程化，自动化