凯的BLOG

《SRE Google运维解密》阅读

·

Google工程师在提高系统部署规模、改进可靠性和资源利用率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。

一、介绍 #

系统管理员的日常工作与研发工程师相差甚远，通常分属两个不同的部门：开发部（Dev）和运维部（Ops）。

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

SRE这种模型是Google尝试着从根本上避免产生这种矛盾的结果。SRE团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。

SRE就是让软件工程师来设计一个新型运维团队的结果。

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

SRE的几个核心方法论：

  • 确保长期关注研发工作
  • 在保障服务SLO的前提下最大化迭代速度
  • 监控系统
  • 应急事件处理
  • 变更管理
  • 需求预测和容量规划
  • 资源部署
  • 效率与性能

Google SRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破。由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的办法”而生，SRE模型已经发展成一套指导思想、一套方法论、一套激励方法和一个拥有广阔空间的独立职业。

二、Google生产环境：SRE视角 #

Borg是一个分布式集群操作系统。其与Apache Mesos类似，Brog负责在集群层面管理任务的编排工作。

  • Borg负责运行用户提交的”任务“（job）。同时会不断监控这些实例
  • 每当Borg启动某一个任务的时候，它会给每个具体的任务实例分配一个名字和一个编号，这个系统称之为Borg名称解析系统（BNS）
  • Borg还负责将具体资源分配给每个任务。
  • 如果一个任务实例资源使用超出了它的分配范围，Borg会杀掉这个实例，并且重启它。

存储系统由多层结构组成：

  1. 最底层由称为D的服务提供（D代表磁盘Disk，但是D可以同时使用磁盘和SSD）。
  2. D服务的上一层被称之为Colossus，Colossus建立了一个覆盖了整个集群的文件系统。
  3. 构建于Colossus之上，有几个类似数据库的服务可供选择：
    1. Bigtable是一个NoSQL数据库。
    2. Spanner是可以提供SQL接口以及满足一致性要求的全球数据库。
    3. 另外几种数据库系统，例如Blobstore也可用。

全球负载均衡系统（GSLB）在三个层面上负责负载均衡工作：

  • 理用地理位置信息进行负载均衡DNS请求（例如www.google.com的解析）。
  • 在用户服务层面进行负载均衡，例如YouTube和Google Maps。
  • 在远程调用（RPC）层面进行负载均衡。

Chubby集群锁服务提供一个与文件系统类似的API来操作锁。

Borgmon定期从监控对象抓取监控指标（Metric）。

所有的Google服务之前都使用远程调用（RPC）通信，称为Stubby。

除了一些开源项目之外（Android和Chrome等），其他Google软件工程师全部使用同一个共享软件仓库开发。

三、拥抱风险 #

SRE旨在寻求快速创新和高效的服务运营业务之间的风险的平衡，而不是简单地将服务在线时间最大化。

我们的目标是：明确地将运维风险与业务风险对应起来。我们会努力提高一项服务的可靠性，但不会超过该服务需要的可靠性。

Google标准做法是通过一个客观的指标来体现一个待优化的系统属性。通过设立这样一个目标，我们可客观地评价目前的系统表现以及追踪一段时间内的改进和退步。

  1. 计划外停机：可用性 = 系统正常运行时间 / （系统正常运行时间 + 停机时间）
  2. 请求成功率：可用性 = 成功请求数 / 总的请求数

错误预算提供了一个明确的、客观的指标来决定服务在一个单独的季度中能接受多少不可靠性。

  • 产品管理层定义一个SLO，确定一项服务在每个季度预计的正常运行时间。
  • 实际在线时间是通过一个中立的第三方来测算的：我们的监控系统。
  • 这两个数字的差值就是这个季度中剩余的不可靠性预算。
  • 只要测算出正常的在线时间高于SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新的版本。

关键点

  • 管理服务的可靠性主要在于管理风险，而且管理风险的成本可能很高。
  • 100%可能永远都不是一个正确的可靠性目标：不仅是不可能实现的，而且它通常比一项服务的用户期望的可靠性大得多。我们要将服务风险和愿意承担的业务风险相匹配。
  • 错误预算在SRE和产品研发团队之间调整激励，同时强调共同责任。错误预算使得讨论发布速率更容易，同时可有效地减少任何关于事故的讨论。这样，多个团队可以毫无怨言地对生产环境风险度达成一致。

四、服务质量目标 #

SLI是服务质量指标（Indicator）：服务的某项服务质量的一个具体量化指标。

SLO是服务质量目标（Objective）：服务的某个SLI的目标值，或者目标范围。

SLA是服务质量协议（Agreement）：指服务与用户之间的一个明确的，或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。

指标在实践中的应用

我们不应该将监控系统中的所有指标都定义为SLI；只有理解用户对系统的真实需求才能真正决定哪些指标是否有用。指标过多会影响对那些真正重要的指标的关注，而选择指标过少则会导致某些重要的系统行为被忽略。

大部分指标都应该以”分布“，而不是平均值来定义。

为了节约成本，应该为常见的指标构建一套可以重用的SLI模板，从而使得理解每个SLI更简单。

目标在实践中的应用

要求SLO能够被100%满足是不正确，也是不现实的：过于强调这个会降低创新和部署的速度，增加一些成本过高、过于保守的方案。更好的方案是使用错误预算（Error Budget）——对达不到SLO的容忍度——以天或者以周为单位计量。

选择目标SLO不是一个纯粹的技术活动，因为这里还涉及产品和业务层面的决策。SLI和SLO（甚至SLA）的选择都应该直接反应该决策。

  • 不要仅以目前的状态为基础选择目标
  • 保持简单
  • 避免绝对值
  • SLO越少越好
  • 不要追求完美

协议在实践中的应用

起草一份SLA需要业务部门和法务部门选择合适的后果条款。SRE在这个过程中的作用是帮助这些部门理解SLA的SLO达标的概率和困难程度。