Google SRE 概览

1、系统管理员模式与SRE

• 系统管理员模式，雇佣系统管理员运维复杂的计算机系统，随着系统变得越来越复杂，组件越来越多，相关的事件和变更也会越来越多，于是公司招聘更多的系统管理员。该模式中存在2个问题。
• • 直接成本，因为团队大部分维护事件和变更的实施是依赖人工处理，团队的大小、成本与系统负载成线性相关；
  • 间接成本，研发部门和运维部门的工作目标是截然不同的，甚至是互相矛盾的，由此带来的分歧与沟通问题给公司带来的间接成本往往大得多；
• GOOGLE的解决办法：SRE（Site Reliability Engineering）模式，是Google在DevOps上的具体实践，创造软件系统来维护系统运行以替代传统模型中的人工操作，用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务，通过设计、构建自动化工具来取代人工操作。
• • SRE团队成员要对重复性、手工性的操作有天然的排斥感，需要有足够的技术能力快速开发出软件系统以替代手工操作；
  • 传统的Ops团队，随着产品负载得增涨就需要更多的团队成员来重复进行同样的事情；
  • 传统运维工作包括工单处理、手工操作等，负责运维以上产品的团队必须有足够的时间改进所维护的服务，将50%的精力花在真实的优化、开发工作上，否则他们就会被运维工作所淹没；

2、SRE方法论

一般来说，SRE 团队要承担以下几类职责：可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。

Google SRE 管理层针对这些内容制定了一套完整的沟通准则和行事规范，这些规范规定了 SRE 是如何操作 Google 生产环境的，也规定了 SRE 如何和产品研发部门、测试部门、最终用户进行有效沟通。这些准则和规范能够帮助每一个 SRE 部门保持一个良好的研发、运维工作的平衡。以下为Google SRE的几个核心方法论。

2.1 确保长期关注研发工作

• Google 将 SRE 团队的运维工作限制在 50% 以下，SRE 团队应该将剩余时间花在研发项目上，SRE 管理人员应该经常度量团队成员的时间配比，想一切办法去保证这个50%的安全线。
• SRE 处理运维工作的时候的一项准则是：在 8 ~ 12 小时的 on-call 轮值期间最多应该只处理 2 个紧急事件。这个准则保证了 on-call 工程师有足够的时间跟进紧急事件，正确地处理并且恢复服务，并且要撰写一份事后报告。正常状况是是让每一天需要 SRE 响应的紧急事件都是一个合理的负载，每一个事件都可以被专业地处理。
• 所有的产品事故都应该有对应的事后故障总结，无论有没有触发警报。事后故障总结应该包括以下内容：故障发生、发现、解决的全过程，故障的根本原因，预防或者优化的解决方案。在一个故障总结中，你应该列出所有导致故障触发的因素，而不是把它当作一个承认错误的地方。

2.2 在保障服务 SLO (Service Level Objective) 的前提下最大化迭代速度

• 企业中，最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾，在 SRE 模型中使用的工具是错误预算；
• 公司的商业部门或者是产品部门必须建立起一个合理的可靠性目标。一旦建立，“错误预算”就是“1 - 可靠性目标”。如果一个服务的可靠性目标是 99.999%，那么错误预算就是 0.001%，在一年中的累计服务不可用时间为8.76小时。这意味着产品研发部门和 SRE 部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。
• 尽量不要把错误预算都花在一个地方。“错误预算”都可以用于什么范畴呢？研发团队需要用这个预算上线新功能，吸引新用户。理想情况下，我们应该使用这个错误预算来最大化新功能上线的速度，同时保障服务质量。这个基本模型建立起来之后，许多常见的战术策略，例如灰度发布，1% A/B 测试等就全说得通了。这些战术策略都是为了更好地使用整个服务的错误预算。

2.3 监控

监控系统是 SRE 团队监控服务质量和可用性的一个主要手段。最普遍和传统的报警策略是针对某个特定的情况或者监控值，一旦出现情况或者监控值超过阈值就触发 E-mail 报警。

但是这样的报警并不是非常有效：一个需要人工阅读邮件和分析报警来决定目前是否需要采取某种行动的系统从本质上是错误的。

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

• 在 Google 有一个规则：没有不需要采取行动的警报，如果您遇到一个自己认为不需要执行操作的警报，您需要采用自动化的手段来修复该警报；
• 明确警报问题修复的责任，并跟进相关团队，提交 bug 并跟踪记录为什么会这样的问题；
• 调整警报阈值，避免用户并没有出现访问问题时候发送报警；
• 删除那些无效警报，因为它是无用的和不相关的；

监控的输出

• 警报，收到警报的用户需要立即执行某种操作，目标是解决某种已经发生的问题，或者是避免即将要发生的问题，如果在5分钟内没有被回应，它会找到你的替代者。如果问题落到替代者来处理，Google SRE 团队有一个送花规则，你将需要给替代者送去花和一张卡。
• 工单，意味着接受工单的用户应该执行某种操作，但是并非立即执行。尤其是监控到的故障事件在符合设计条件时，要直接自动化得在任务管理系统中生成一个任务工单。
• 日志，平时没有人需要关注日志信息,但是日志信息依然被收集起来以备调试和事后分析时使用。

2.4 紧急事件处理

可靠性是 MTTF（平均无故障时间）和 MTTR（从出现故障到恢复中间的这段时间）的结合结果。评价一个团队将系统恢复到正常情况的最有效指标，就是 MTTR。

• 任何需要人工操作的事情，都只会延长恢复时间。
• 通过事先预案并且将最佳方法记录在“运维手册”上通常会使 MTTR 降低 3 倍以上。在巨大的时间压力和产品压力下，运维手册中记录的清晰调试步骤和分析方法对处理问题的人是不可或缺的。
• 没有手册是一个奢侈的事情，只有在团队需要支持的事情很少的情况下可行。我们这些支持很多系统的人不能将所有内容全部放入脑子。
• 如果手册无用，就应该重建它，或删除警报和手册。因为没有足够有用的背景信息的警报是如此危险。
• Google SRE 将大部分重心放在“运维手册”的维护上，同时通过“Wheel of Misfortune”（厄运之轮）等项目培训团队成员。

2.5 变更管理

SRE 经验告诉我们，大概 70% 的生产事故由某种部署的变更而触发。变更管理的最佳实践可使用自动化来完成以下几个项目：

• 采用渐进式发布机制。
• 迅速而准确地检测到问题的发生。
• 当出现问题时，安全迅速地回退改动。

这三点可以有效地降低变更给 SRE 和最终用户带来的时间成本和服务质量的下降。于是，变更执行的速度和安全性同时得到了提高。

70％ 的故障可以通过不做任何事情来避免！我们是自己的敌人。因此，可以将错误预算支出降低高达 70％ 的基本工具是：及时发现上线出现问题并快速回滚。

你需要多长时间才能注意到这是一个有问题的版本发布？回滚它需要多长时间？在回滚完成之前，它影响了多少人？这些是你应该绝对知道答案的问题。

2.6 需求预测和容量规划

需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。这里并没有任何特别的概念，但是我们发现行业内有许多团队根本没有这个意识和计划去满足这个要求。一个业务的容量规划，不仅仅要包括自然增长(随着用户使用量上升,资源使用率也上升)，也需要包括一些非自然增长的因素（新功能的发布、商业推广，以及其他商业因素在内）。

容量规划有几个步骤是必须的：

• 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。
• 规划中必须有准确的非自然增长的需求来源的统计。
• 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。

压力测试不需要以整体方式进行，您可以查看正在运行的系统在负载下的行为，以了解其性能，并且您经常得到更好的数字。

重要的是要知道，当你达到边界条件（如 CPU 跑满或达到内存上限）时发生的事情可能会灾难性的，所以有时重要的是要知道这些限制的位置。 

由于容量对可用性至关重要，因此 SRE 团队必须负责容量规划，这意味着他们也必须负责配置。

2.7 资源部署

资源的部署与配置是变更管理与容量规划的结合物。在我们的经验里，资源的部署和配置必须能够非常迅速地完成，而且仅仅是在必要的时候才执行，因为资源通常是非常昂贵的。而且这个部署和配置的过程必须要确保能够正确地执行完毕，否则资源就仍然处于不可用状态。增加现有容量经常需要启动新的实例甚至是集群，这通常需要大幅度修改现有的集群配置 ( 配置文件、负载均衡、网络等 )，同时还要执行一系列测试，确保新上线的容量可以正确地服务用户。因此新资源的部署与配置是一个相对比较危险的操作，必须要小心谨慎地执行。

不要试图让计算机模仿人类的配置步骤，如“编辑文件，发送审查，运行脚本，检查控制台”，而是以流动和恒定的方式，“当利用率 > x％，添加 1 个服务器”，“当 1 台新的服务器上线，将它们添加到负载均衡器的后端”。

2.8 效率与性能

• 高效地利用各种资源是任何营利性服务都要关心的。因为 SRE 最终负责容量的部署和配置，因此 SRE 必须也承担起任何有关利用率的讨论及改进。因为一个服务的利用率指标通常依赖于这个服务的工作方式以及对容量的配置与部署上。如果能够通过密切关注一 个服务的容量配置策略，进而改进其资源利用率，可以非常有效地降低系统的总成本。
• 一个业务总体资源的使用情况是由以下几个因素驱动的：用户需求（流量）、可用容量和软件的资源使用效率。SRE 可以通过模型预测用户需求，合理部署和配置可用容量，同时可以改进软件提升资源使用效率。通过这三个因素能够大幅度推动一个服务的效率提升（但是并非全部）。
• 软件系统一般来说在负载上升的时候，会导致延迟升高。延迟升高其实和容量损失是一样的。当负载到达临界线的时候，一个逐渐变慢的系统最终会停止一切服务。换句话说，系统此时的延迟已经是无穷大了。SRE 的目标是根据一个预设的延迟目标部署和维护足够的容量。SRE 和产品研发团队应该共同监控和优化整个系统的性能，这就相当于给服务增加容量和提升效率了

系统的可靠性是 SRE 的责任，他们需要防止新的版本导致用户可见的错误，SRE 团队的责任还包括检测，减轻和防止性能退化。

我的团队在监控和防止新版本的性能退化方面做得还不够，但我们非常关心系统架构，并确保仔细检查新系统的文档说明，以满足一个 SRE 的要求。

3、Google 生产环境介绍

典型的 Google 数据中心的拓扑结构 :

• 约 10 台硬件服务器组成了一个机柜(Rack)
• 数台机柜组成一个机柜排(Row)。
• 一排或多排机柜组成了一个集群(Cluster)
• 一般来说，一个数据中心(Datacenter)包含多个集群
• 多个相邻的数据中心组成了一个园区(Campus)

3.1 Borg集群管理系统

Borg 负责在集群层面管理任务的编排工作。Borg 的下一代，Kubernetes，开源容器化集群编排系统，Google 创立于 2014 年。

• Borg 负责运行用户提交的“任务”(Job)。每个任务可以由一个或多个实例 (Task)组成(有时候甚至由几千个实例组成)。
• 当 Borg 启动一个任务的时候，它会为每一个实例安排一台物理服务器，并且执行具体的程序启动它。
• Borg 同时会不断监控这些实例，如果发现某个实例出现异常，其会终止该实例，并且重启它，有时候会在另外一台物理服务器上重启。
• 因为实例与机器并没有一对一的固定对应关系，不能简单地用 IP 地址和端口来指代某一个具体任务实例。为了解决这个问题，增加了一个新的抽象层。 每当 Borg 启动某一个任务的时候，Borg 给每个具体的任务实例分配一个名字和一个编号，这个系统称之为 Borg 名称解析系统(BNS)。
• Borg 还负责将具体资源分配给每个任务。每个任务都需要在配置文件中声明它需要的具体资源 (例如: 3CPU 核心 ， 2GB 内存等)。
• Borg 还关注物理服务器的故障域属性，同一个服务的多个实例会被分散部署到多个机柜中，如果某一个任务实例的资源使用超出了它的分配范围则会被Borg重启。

3.2 网络

• 几百台 Google自己制造的交换机用 Clos （贝尔实验室Charles Clos）连接方式连接起来创建了一个非常快的虚拟网络交换机，这个交换机有几万个虚拟端口。 这个交换机的名称叫 Jupiter。在 Google 最大的一个数据中心中，Jupiter 可以提供 1.3 Pb/s的服务器交叉带宽。Clos，A study of Non-Blocking Switching Networks（http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x）
• Google 数据中心是由一套全球覆盖的骨干网B4连接起来的。Google 使用一个基于 OpenFlow 的软件定义网络(SDN)，没有选择使用高级智能路由器连接，而是采用 了普通的非智能交换组件+集中化(有备份的)的控制器连接方式。 该控制器负责计算网络中间的最佳路径，将整个集群的复杂路由计算从具体交换硬件上分离开来，从而降低成本。
• 带宽控制器(Bandwidth Enforcer，BwE)负责管理所有可用带宽，不仅需要优化带宽的使用以降低成本，还需要解决流量迁移问题。

     Google 的有些服务通常是遍布全球的。为了降低分布式集群的服务延迟，希望能够将用户指派给距离最近的、有空余容量的数据中心处理。

• 全球负载均衡系统(GSLB)在三个层面上负责负载均衡工作 :
• •     利用地理位置信息负载均衡 DNS 请求。
  •     在用户服务层面进行复载均衡，例如 YouTube 和 Google Maps。
  •     在远程调用(RPC)层面进行负载均衡。

每个服务的管理者首先需要在配置文件中给服务起一个名称，然后为其指定一系列的 BNS 地址， 每个 BNS 地址可用的容量(通常，容量的单位是QPS，每秒请求数量)。

GSLB 会自动 将用户流量导向到合适的位置。

在中小企业自建IDC机房的生产环境中基本上都是使用的千兆网络，服务器交叉带宽相当于0.000001Pb/s。

传统网络与Clos网络的简单对比。

传统网络柘朴：

特点：

• 使用生成树协议或三层路由核心网络构建的传统网络的问题是从一组备选路径中选择单个“最佳路径”。
• 所有数据流量采用“最佳路径”，直到它被拥塞，然后分组被丢弃。

Clos网络柘朴：

特点：

• 不再使用生成树协议，但同时仍然保持无环路拓扑，且同时利用所有多个冗余链路。
• Clos网络现在表现为交换机互连的方式，数据中心网络由机架顶交换机和核心交换机组成。
• 叶交换机不彼此连接，并且主干交换机仅连接到叶交换机（或上游核心设备）。
• 来自叶交换机的上行链路的数量等于主干交换机的数量。连接总数等于中心交换机数量乘以叶交换机的数量（在该图中8×4 = 32个链路）。
• Clos网络的优点是您可以使用一组相同和便宜的设备来创建树并获得高性能和弹性。
• 通信路径是随机选择的，使得业务负载均匀分布在顶层交换机之间。 如果其中一个顶层交换机出现故障，它只会稍微降低数据中心的性能。
• 目前主流的网络设备厂商也都有支持Clos网络架构方案的相关设备型号，一般用于数据中心规模的网络建设方案。

参考资料详见：http://www.networkworld.com/article/2226122/cisco-subnet/clos-networks--what-s-old-is-new-again.html