赞誉

• SRE和传统的IT运维有很大区别，SRE真正实现了DevOps：首先，SRE深度参与开发阶段的工作，对
• Google SRE团队的精华在于研发软件系统，将运维自动化以替代传统模型中的人工操作。
• 100%的可用性是不现实的，需要达到这个目标的成本通常远超于所能获得的价值，

第Ⅰ部分 概览

第1章 介绍

系统管理员模式

• 这两个部门的目标从本质上来说是互相矛盾的。
• 在现实生活中，公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益。

Google的解决之道：SRE

• 第一类，团队中 50%～60% 是标准的软件工程师，具体来讲，就是那些能够正常通过Google软件工程师招聘流程的人。第二类，其他40%～50% 则是一些基本满足Google软件工程师标准（具备85%～99% 所要求的技能），但是同时具有一定程度的其他技术能力的工程师。目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
• ，Google为整个SRE团队所做的所有传统运维工作设立了一个50%的上限值。传统运维工作包括：工单处理、手工操作等。设立这样一个上限值确保了SRE团队有足够的时间改进所维护的服务，将其变得更稳定和更易于维护。

SRE方法论

• 确保长期关注研发工作
• ：在每8～12小时的on-call 轮值期间最多只处理两个紧急事件。
• 。Google 的一项准则是“对事不对人”，事后总结的目标是尽早发现和堵住漏洞，而不是通过流程去绕过和掩盖它们。
• 错误预算可以用于什么范畴呢？研发团队需要用这个预算上线新功能，吸引新用户。
• 监控系统
• 。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。一个监控系统应该只有三类输出。
• 可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数（参见文献[Sch15]）。评价一个团队将系统恢复到正常情况的最有效指标，就是MTTR。
• “运维手册（playbook）”上
• 运维手册中记录的清晰调试步骤和分析方法对处理问题的人是不可或缺的。因此，Google SRE将大部分工作重心放在“运维手册”的维护上，同时通过“Wheel of Misfortune”等项目[2]不断培训团队成员。
• 变更管理SRE
• 需求预测和容量规划需求预测和容量规
• 容量规划有几个步骤是必需的：● 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。● 规划中必须有准确的非自然增长的需求来源的统计。● 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。
• 因为SRE最终负责容量的部署和配置，因此SRE也必须承担起任何有关利用率的讨论及改进

第Ⅱ部分 指导思想

• 我们将琐事定义为无聊、重复性的运维工作，这些工作通常不具有长期价值，而且会随着服务规模的扩大而增长。

第3章 拥抱风险

• 极端的可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量。

管理风险

• 机会成本这类成本由某一个组织承担。当该组织分配工程资源来构建减少风险的系统或功能，而非那些用户直接可用的功能时需要承担这些成本。这些工程师不能再从事为终端用户设计新功能和新产品的工作
• 。也就是说，当设定了一个可用性目标为99.99%时，我们即使要超过这个目标，也不会超过太多，否则会浪费为系统增加新功能、清理技术债务或者降低运营成本的机会。
• 组件化和上云后机会成本其实没有那么大了。但是真实成本肯定是要大量增加的

  。也就是说，当设定了一个可用性目标为99.99%时，我们即使要超过这个目标，也不会超过太多，否则会浪费为系统增加新功能、清理技术债务或者降低运营成本的机会。

度量服务的风险

• 公式3-1：基于时间的可用性
• 公式3-2：合计可用性
• 影响用户占比

  公式3-2：合计可用性

服务的风险容忍度

• 在没有专门的产品团队的情况下，建立系统的工程师们经常在知情或不知情的情况下扮演了这个角色。
• 在为每一项服务确定可用性目标时，可以考虑如下的问题： ● 构建和运维可用性再多一个“9”的系统，收益会增加多少？ ● 额外的收入是否能够抵消为了达到这一可靠性水平所付出的成本？
• 基础设施服务运维的关键战略就是明确划分服务水平，从而使客户在构建系统时能够进行正确的风险和成本权衡。通过明确划定的服务水平，基础设施提供者其实就是将服务的成本的一部分转移给了用户。以这种方式暴露成本可以促使客户选择既能够满足他们的需求又能够压缩成本的服务水平。
• 考核平台型服务的可用性要考虑实际使用场景的合理性

  基础设施服务运维的关键战略就是明确划分服务水平，从而使客户在构建系统时能够进行正确的风险和成本权衡。通过明确划定的服务水平，基础设施提供者其实就是将服务的成本的一部分转移给了用户。

使用错误预算的目的

• 测试新发布的代码的最好做法就是在一个典型工作负载的服务子集中进行测试，这种做法通常被称为金丝雀测试
• 为了基于客观数据做出决策，两个团队需要共同定义一个基于服务水平目标（SLO）的季度错误预算（参考第4章）。错误预算提供了一个明确的、客观的指标来决定服务在一个单独的季度中能接受多少不可靠性。这个指标在SRE与产品研发部门的谈判中将政治因素排除
• 错误预算的主要好处就是它能够激励产品研发和SRE一起找出创新和可靠性之间合理的平衡点。

第4章 服务质量目标

• 这个过程中，我们需要利用一些主观判断结合过去的经验以及对服务的理解来定义一些服务质量指标（SLI）、服务质量目标（SLO），以及服务质量协议（SLA）。这三项分别是指该服务最重要的一些基础指标、这些指标的预期值，以及当指标不符合预期时的应对计划。事先选择好合适的指标有助于在故障发生时帮助SRE进行更好地决策，同时也为SRE团队判断系统是否正常工作提供帮助。

服务质量术语

• SLO是服务质量目标（Objective）：服务的某个SLI的目标值，或者目标范围。SLO的定义是SLI≤目标值，或者范围下限≤SLI≤范围上限。
• SRE保证全球Chubby服务能够达到预定义的SLO，但是同时也会确保服务质量不会大幅超出该SLO。每个季度，如果真实故障没有将可用性指标降低到SLO之下，SRE会有意安排一次可控的故障，将服务停机。利用这种方法，我们可以很快找出那些对Chubby全球服务的不合理依赖，强迫服务的负责人尽早面对这类分布式系统的天生缺陷。

指标在实践中的应用

• 我们不应该将监控系统中的所有指标都定义为SLI；只有理解用户对系统的真实需求才能真正决定哪些指标是否有用。
• 一般来说，SRE更倾向于分析一组数据的百分比分布，而非其算术平均值。长尾效应比算术平均值更有特点，使用百分比分布能够更清晰地进行分析

第5章 减少琐事

琐事的定义

• 但是，每件琐事都满足下列一个或多个属性：手动性
• 重复性的
• 可以被自动化的
• 战术性的琐事是突然出现的、应对式的工作，而非策略驱动和主动安排
• 没有持久价值如果在你完成某项任务之后，服务状态没有改变，这项任务就很可能是琐
• 与服务同步线性增长

为什么琐事越少越好

• 来自SRE的数据显示，琐事的最大来源就是中断性工作（即与服务相关的非紧急的邮件和电子邮件）。另一个主要来源是on-call（紧急的），紧随其后的是发布和数据更新
• 当某个SRE报告自己承担了过量的琐事时，这通常意味着管理者需要在团队中更均衡地分布琐事负荷，同时应该鼓励该SRE找到自己满意的工程项目。

第6章 分布式系统的监控

将上述理念整合起来

• ● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。
• 有点理想化了。大型系统能做到相关告警的聚拢和收敛就不错了。

  ● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。

监控系统的长期维护

• ，在紧急警报带来的压力减轻之后应该继续支持和优先处理那些长期修复问题的工作。
• 短期内，接受某种可控的可用性的降低可以换取一些系统长期性的提升。将所有紧急警报作为一个整体来审视是很重要的，要考虑当前的紧急警报的级别是否对未来的一个高可用、高可靠性的系统有帮助

第7章 Google 的自动化系统的演进

自动化的应用案例

• 广泛使用的工具有Puppet、Chef、cfengine

建议

• 在我们的自动化系统中添加更多的合理性检查，包括速率限制，以及使整个退役流程具有幂等性。

第8章 发布工程

发布工程师的角色

• 发布工程师与SRE紧密协作，为变更的测试进行无缝发布，以及为变更的顺利回滚等制定策略。

发布工程哲学

• 批准源代码改动—通过源代码仓库中的配置文件决定

持续构建与部署

• ，大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支，新分支的内容永远不会再合并入主分支。Bug修复先提交到主分支，再cherry picking到发布分支上。
• 一个持续测试系统会在每个主分支改动提交之后运行单元测试
• 我们使用Sisyphus,SRE开发的一个通用的发布自动化框架，来执行更为复杂的部署任务

第9章 简单化

系统的稳定性与灵活性

• 对于大多数生产环境软件系统来说，我们想要在稳定性和灵活性上保持平衡

乏味是一种美德

• 必要复杂度是一个给定的情况所固有的复杂度，不能从该问题的定义中移除，而意外复杂度则是不固定的，可以通过工程上的努力来解决
• 主动降低意外复杂度是一个好开发、团队的标准

  必要复杂度是一个给定的情况所固有的复杂度，不能从该问题的定义中移除，而意外复杂度则是不固定的，可以通过工程上的努力来解决

我绝对不放弃我的代码

• SRE推崇保证所有的代码都有必须存在的目的的实践。例如，审查代码以确保它确实符合商业目标，定期删除无用代码，并且在各级测试中增加代码膨胀检测。

“负代码行”作为一个指标

• 添加到项目中的每行代码都可能引入新的缺陷和错误。较小的项目容易理解，也更容易测试，而且通常缺陷也少。从这一观点出发，当我们感觉到增加新功能需求时，应该保持保守的态度。我曾经做过的一些最令人满意的编码工作就是删除了数千行已经没用的代码

最小 API

• “不是在不能添加更多的时候，而是没有什么可以去掉的时候，才能达到完美

第Ⅲ部分 具体实践

第10章 基于时间序列数据进行有效报警

Borgmon的起源

• Prometheus[3]与Borgmon十分类似
• 内部部署了一些专门收集信息的Borgmon实例（scraper），这些实例用于收集信息，而集群实例则用于汇总

应用软件的监控埋点

• Google内部产生的每个二进制文件中都默认包含一个HTTP服务，[8]同时每种主流编程语言都提供了一个编程接口可以自动注册暴露指定的程序变量
• 统一框架的好处了

  Google内部产生的每个二进制文件中都默认包含一个HTTP服务，[8]同时每种主流编程语言都提供了一个编程接口可以自动注册暴露指定的程序变量

时间序列数据的存储

• 通常情况下，数据中心和全局Borgmon中一般至少需要存放12小时左右的数据量，以便渲染图表使用
• Borgmon 会定时将内存状态归档至一个外部数据库（TSDB）。

第11章 on-call轮值

on-call工程师的一天

• 或者时间非常紧迫的服务来说，这个时间定为5分钟。而非敏感业务通常来说是30分钟。
• escalate

on-call工作平衡

• Engineering），认为这是区别我们与传统Ops团队的不同之处。所以，我们强调至少将SRE团队50%的时间花在软件工程上。在其余时间中，不超过25%的时间用来on-call，另外25%的时间用来处理其他运维工作。
• 导致每日紧急事件中值＞1，那么早晚另外一个组件也会同时报警，导致当天总报警次数超标。

安全感

• 。业务系统的重要性和操作所带来的影响程度会对on-call工程师造成巨大的精神压力，危害工程师的身体健康，并且可能导致SRE在处理问题过程中犯错误，从而影响到整个系统的可靠性。从医学上讲，压力状态下释放的荷尔蒙，例如皮质醇和促肾上腺皮质素（CRH）都会对人的行为造成影响，甚至造成恐惧，进而影响人类进行正常认知功能的工作，最后导致错误行为的产生（参见文献[Chr09]）。
• 让on-call SRE知道他们可以寻求外部帮助，对减轻on-call压力也很有帮助。最重要的资源有：● 清晰的问题升级路线。● 清晰定义的应急事件处理步骤。● 无指责，对事不对人的文化氛围（参见文献[Loo10]和[All12]）。

第12章 有效的故障排查手段

理论

• 造成低效的故障排查过程的原因通常集中在定位（triage）、检查和诊断环节上，主要由于对系统不够了解而导致。

实践

• 在大型问题中，你的第一反应可能是立即开始故障排查过程，试图尽快找到问题根源。这是错误的！不要这样做。正确的做法应该是：尽最大可能让系统恢复服务
• 查看和操作time-series图表是理解某个系统组件工作情况的好办法，可以通过几个图表的相关性确定问题根源。[31]
• 一些跟踪工具，例如Dapper（参见文献[Sig10]）提供了非常有用的了解分布式系统工作情况的一种方式。但是不同的产品需要极为不同的跟踪系统的设计（参见文献

案例分析

• 在公开上线之前，一个自动化安全扫描程序被用来扫描该App是否有漏洞，

第13章 紧急事件响应

测试导致的紧急事故

• 我们现在要求在大型测试中一定先测试回滚机制。

第24章 分布式周期性任务系统

Google Cron系统的构建过程

• 各个副本利用Paxos协议同步的最重要的状态信息就是哪些Cron任务已经被启动了。该服务需要不停地以同步方式通知大多数的副本每个计划任务的启动和结束信息。
• Dcron貌似使用的gossip协议？

  各个副本利用Paxos协议同步的最重要的状态信息就是哪些Cron任务已经被启动了。该服务需要不停地以同步方式通知大多数的副本每个计划任务的启动和结束信息。