第一部分

开发和运维的矛盾

传统的研发团队和运维团队分歧的焦点主要在软件新版本、 新配置的变更的发布速度上。 研发部门最关注的是如何能够更快速地构建和发布新功能。 运维部门更关注的是如何能在他们值班期间避免发生故障。

SRE团队构成

第一类 ，团队中50%-60%是标准的软件工程师；第二类， 其他40%-50%则是一些基本满足软件工程师标准（具备85%-99%所要求的技能），但是同时具有一定程度的其他技术能力的工程师。

SRE的本质

用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。

SRE团队职责

可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理以及容量规划与管理。

SRE方法论

1、确保长期关注研发工作

所有的产品事故都应该有对应的事后总结，无论有没有触发警报。 这里要注意的是， 如果一个产品事故没有触发警报 ， 那么事后总结的意义可能更大．因为它将揭示监控系统中的漏洞。事后总结应该包括以下内容：事故发生、 发现、 解决的全过程，事故的根本原因， 预防或者优化的解决方案。

2、在保障服务**SLO（服务等级目标）**的前提下最大化迭代速度

在企业中，最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾。

错误预算：任何产品都不是，也不应该做到 100% 可靠

适用场景：上线新功能， 吸引新用户。例如灰度发布、1% AB 测试

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。

3、监控系统

最普遍的和传统的报警策略是针对某个特定的情况或者监控值， 一旦出现情况或者监控值超过阈值值就触发E-mail警报。

监控系统不应该依赖人来分析警报信息， 而是应该由系统自动分析、仅当前用户执行某种操作时，才需要通知用户。

一个监控系统应该只有三类输出

紧急警报：意味着收到警报的用户需要立即执行某种橾作，目标是解决某种已经发生的问题，或者是避免即将发生的问题。

工单：意味着接收工单的用户应该执行某种操作，但是并非立即执行。系统并不能自动解决目前的情况，但是如果一个用户在几天内执行这项操作，系统不会受到任何影响。

日志：日志信息依然被收集起来以备调试和事后分析时使用。 正确的做法是平时没人会去主动阅读日志，除非有特殊需要。

4、应急事件处理

可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数。评价一个团队将系统恢复到正常情况的最有效指标，就是MTTR。

通过事先预案并且将最佳方法记录在“运维手册”上通常可以使MTTR降低3倍以上。

5、变更管理

变更管理的最佳实践是使用自动化来完成以下几个项目：

采用渐进式发布机制。

迅速而准确地检测到问题的发生。

当出现问题时，安全迅速地回退改动。

6、需求预测和容量规划

需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。

7、资源部署

资源的部署和配置必须能够非常迅速地完成， 而且仅仅是在必要的时候才执行。

8、效率与性能

一个业务总体资源的使用情况是由以下几个因素驱动的：用户需求（流量）、可用容量和软件的资源使用效率。

N+2模式

在更新过程中，有一个任务实例将会短暂不可用，只有36个实例可提供服务。如果另外一个物理服务器同时也出现问题，那么另外一个任务实例也受到影响，只剩35个实例可以对外服务，刚好可以满足峰值要求。

第二部分

适当的可靠性

管理服务的可靠性主要在于管理风险，而且管理风险的成本可能很高。

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

100%可能永远都不是一个正确的可靠性目标：不仅是不可能实现的，而且它通常比一项服务的用户期望的可靠性大得多。我们要将服务风险和愿意承担的业务风险相匹配。

成本存在的两个维度

冗余物理服务器/计算资源的成本

通过投入冗余设备，我们可以进行常规的系统离线或其他预料之外的维护性操作。又或者可以利用一些空间来存储奇偶校验码块，以此来提供一定程度的数据持久性保证。

机会成本

这类成本由某一个组织承担。 当该组织分配工程资源来构建减少风险的系统或功能，而非那些用户直接可用的功能时需要承担这些成本。 这些工程师不能再从事为终端用户设计新功能和新产品的工作。

计划外停机及可用性计算

对于大多数服务而言，最直接的能够代表风险承受能力的指标就是对于计划外停机时间的可接受水平。计划外停机时间是由服务预期的可用性水平所体现的，通常我们愿意用提供的“9”系列的数字来体现，比如可用99.9%，99.99%或99.999%。每个额外的“9”都对应一个向 100%可用性的数量级上的提高。 对于服务系统而言，这个指标通常是基于系统正常运行时间比例的计算得出的。

基于时间的可用性

可用性=系统正常运行时间/(系统正常运行时间+停机时间)

当基于时间的可用性无限接近100%时，还可以通过请求成功率来定义服务可用性。这个基于产量的指标是通过滚动窗口计算出来的（比如，一天内成功请求的比率）。

合计可用性

可用性=成功请求数/总的请求数

消费者服务

消费者服务通常会有一个对应的产品团队，是该服务的商业所有者。它们每一个都有自己的产品经理。这些产品经理负责了解用户和业务，在市场上塑造产品的定位。

需要考虑的风险容忍度因素

需要的可用性水平、不同类型的失败对服务不同的影响、使用服务成本来帮助在风险曲线上定位这个服务、
需要考虑的其他重要的服务指标

可用性目标考虑的问题

用户期望的服务水平、服务是否直接关系到收入（我们的收人或我们的客户的收入）、是一个有偿服务还是免费服务、竞争对手提供的服务水平如何、服务是针对消费者还是企业的

故障的类型

持续的低故障率、偶尔发生的全网中断

基础设施服务

基础设施有多个客户，而他们通常有很多不同的需求。

风险容忍度因素、可用性目标和故障的类型

不同的用户有不同的需求，有时需求甚至是相反的。

成本

一种在符合成本效益条件下满足这些竞争性约束的方式就是将基础设施分割成多个服务，在多个独立的服务水平上提供该服务。

基础设施服务运维的关键战略就是明确划分服务水平，从而使客户在构建系统时能够进行正确的风险和成本权衡。 通过明确划定的服务水平，基础设施提供者其实就是将服务的成本的一部分转移给了用户。 以这种方式暴露成本可以促使客户选择既能够满足他们的需求又能够压缩成本的服务水平。

这里要注意的是，我们可以使用相同的硬件和软件运行多个级别的服务。可以通过调整服务的各种特性提供不同的服务水平，如资源的数量、冗余程度、资源的地理配置，以及基础设施软件的配置。

错误预算指标

产品管理层定义一个SLO，确定一项服务在每个季度预计的正常运行时间。

实际在线时间是通过一个中立的第三方来测算的：我们的监控系统。

这两个数字的差值就是这个季度中剩余的不可靠性预算。

只要测算出的正常在线时间高于SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新的版本。

当SLO违规导致错误预算接近耗尽时，将发布的速度减慢，或者回退到上一版本。

错误预算在SRE和产品研发团队之间调整激励，同时强调共同责任。 错误预算使得讨论发布速率更容易，同时可有效地减少任何关于事故的讨论。 这样，多个团队可以毫无怨言地对生产环境风险度达成一致。

服务质量术语

SLI是指服务质量指标（indicator）——该服务的某项服务质量的一个具体量化指标。如处理请求所消耗的时间、错误率（请求处理失败的百分比）、系统吞吐量（每秒请求数量）、可用性（服务可用时间的百分比）等

SLO是服务质量目标（Objective）——服务的某个SLI的目标值，或者目标范围。SLO的定义是SLI≤目标值，或者范围下限≤SLI≤范围上限。

SLA是服务质量协议（Agreement）——指服务与用户之间的一个明确的，或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。区别SLO和SLA的一个简单方法是问“如果SLO没有达到时，有什么后果？”如果没有定义明确的后果，那么我们就肯定是在讨论一个SLO，而不是SLA。

SLI的分类

用户可见的服务系统。

存储系统通常强调：延迟、可用性和数据持久性。

大数据系统。

所有的系统都应该关注：正确性。 正确性是系统健康程度的一个重要指标，但是它更关注系统内部的数据，而不是系统本身，所以这通常不是SRE 直接负责的。

琐事的定义

琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。琐事与服务呈线性服务的成长。

工程工作类别

软件工程：编写或修改代码，以及所有其他相关的设计和文档工作。例如，编写自动化脚本，创造工具或框架，增加可扩展性和可靠性的服务功能，或修改基础设施代码以使其更稳健.

系统工程：配置生产系统、修改现存配置，或者用一种通过一次性工作产生持久的改进的方法来书写系统文档。例如，监控的部署和更新、负载均衡的配置，服务器配置，操作系统的参数调整和负载均衡器的部署。系统工程还包括与研发团队进行的架构、设计和生产环境方面的咨询工作。

琐事：与运维服务相关的重复性的、手工的劳动。

流程负担：与运维服务不直接相关的行政工作。例如招聘、人力资源书面工作、团队/公司会议、任务系统的定期清理工作，工作总结，同行评价和自我评价，以及培训课程等。

监控术语

监控（monitoring）：收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等。

白盒监控（white-box monitoring）：依靠系统内部暴露的一些性能指标进行监控。包括日志分析，Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。

黑盒监控（lack-box monitoring）：通过测试某种外部用户可见的系统行为进行监控。

监控台页面（dashboard）：提供某个服务核心指标一览服务的应用程序（一般是基于Web的）。该应用程序可能会提供过滤功能（filter），选择功能（selector）等，但是最主要的功能是用来显示系统最重要的指标。 该程序同时可以显示相应团队的一些信息，包括目前工单的数量、高优先级的Bug列表，目前的on-call工程师和最近进行的生产发布等。

警报（alert）：目标对象是某个人发向某个系统地址的一个通知。目的地可以包括工单系统、E-mail地址，或者某个传呼机。相应的，这些警报被分类为：工单，E-mail 警报，以及紧急警报（page）。

根源问题（root cause）：指系统（软件或流程）中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题不会再以同样的方式发生。 某一个故障情况可能同时具有多个根源问题。

节点或者机器（node/machine）：这里的两个术语是可以互换的:指在物理机，虚拟机，或者容器内运行的某个实例。某个单独的物理机器上可能有多个服务需要监控，这些服务可能具有如下特点。

相互关联的服务：例如Web服务器与对应的缓存服务器。不相关的服务，它们仅仅共享硬件：例如代码仓库和把文件存放在代码仓库中的配置管理系统的主进程。

推送（push）：关于某个服务正在运行的软件或者其配置文件的任何改动。

监控的原因

分析长期趋势；跨时间范围的比较，或者是观察实验组与控制组之间的区别；报警；构建监控台页面；临时性的回溯分析（也就是在线调试）。

监控系统解决的问题

什么东西出故障了（现象），以及为什么出故障（原因，可能只是中间原因，并不是根源问题），现象和原因的区分是构建信噪比高的监控系统时最重要的概念。

黑盒监控和白盒监控的区别

黑盒监控是面向现象的，代表了目前正在发生的，而非预测会发生的问题，即“系统现在有故障”。

白盒监控则大量依赖对系统内部信息的检测，如系统日志、抓取提供指标信息的HTTP节点等。 白盒监控系统因此可以检测到即将发生的问题及那些重试所掩盖的问题等。

监控系统的四个黄金指标

延迟：服务处理某个请求所需要的时间。这里区分成功请求和失败请求很重要。

流量：使用系统中的某个高层次的指标针对系统负载需求所进行的度量。

错误：请求失败的速率，要么是显式失败（例如HTTP 500），要么是隐式失败（例如HTTP 200回复中包含了错误内容），或者是策略原因导致的失败（例如，如果要求回复在1s内发出任何超过1s的请求就都是失败请求）。

饱和度：服务容量有多“满”。通常是系统中目前最为受限的某种资源的某个具体指标的度量。很多系统在达到100%利用率之前性能会严重下降，增加一个利用率目标也是很重要的。

监控系统设计要求

那些最能反映真实故障的规则应该越简单越好，可预测性强，非常可靠。

那些不常用的数据收集、汇总，以及警报配置应该定时删除。

收集到的信息，但是没有暴露给任何监控台。或者被任何警报规则使用的应该定时删除。

设置监控警报的理念

每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。

每个紧急警报都应该是可以具体操作的。

每个紧急警报的回复都应该需要某种智力分析过程。 如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。

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

结论：如果某个紧急警报满足上述四点，那么不论是从白盒监控系统还是黑盒监控系统发出都一样。 最好多花一些时间监控现象，而不是原因。针对“原因”来说，应该只监控那些非常确定的和非常明确的原因。

自动化的价值

一致性，平台性，修复速度更快，行动速度更快，节省时间

集群上线自动化进化路径

1、操作人员触发手动操作（无自动化）。

2、操作人员编写，系统特定的自动化。

3、外部维护的通用自动化。

4、内部维护，系统特定的自动化。

5、不需要人为干预的自治系统。

加入自动化的意义

自动化提供的不仅仅是对时间的节省，所以在单纯的时间花费和时间节省的计算之外也值得实施。 但是，最有效的方法其实在设计阶段：更快地交付和更快地迭代可能会帮助你更快地实现功能，但是却很难形成一个有弹性的系统。对足够大的系统来说，进行改造时加入自主行为是很难的，但软件工程的良好标准的做法将会有很大的帮助：解耦子系统，引入API，最大限度地减少副作用等