【读书笔记】SRE：Google运维解密 第Ⅰ部分 概览

第Ⅰ部分 概览

第1章 介绍

系统管理员模式

研发团队和系统运维团队分属两个部门所带来的间接成本就没那么容易度量了，但是这些间接成本往往大得多。

Google的解决之道：SRE

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

• 目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。

SRE团队成员具有如下特点

1. 对重复性、手工性的操作有天然的排斥感。
2. 有足够的技术能力快速开发出软件系统以替代手工操作。

SRE方法论

• 事后总结的目标是尽早发现和堵住漏洞，而不是通过流程去绕过和掩盖它们。

• "错误预算”起源于这样一个理念：任何产品都不是，也不应该做到100%可靠（显然这并不适用于心脏起搏器和防抱死刹车系统等）。一般来说，任何软件系统都不应该一味地追求100%可靠。因为对最终用户来说，99.999%和100%的可用性是没有实质区别的。

• SRE团队的目标不再是 “零事故运行”,SRE团队和产品研发团队目标一致，都是在保障业务服务可靠性需求的同时尽可能地加快功能上线速度。

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

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

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

  • 日志（logging）平时没有人需要关注日志信息，但是日志信息依然被收集起来以备调试和事后分析时使用。

• 通过事先预案并且将最佳方法记录在“运维手册（playbook）”上通常可以使MTTR 降低3倍以上。因此，Google SRE将大部分工作重心放在“运维手册”的维护上，同时通过“Wheel of Misfortune”等项目[2]不断培训团队成员。

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

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

• **需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。**一个业务的容量规划，不仅仅要包括自然增长（随着用户使用量上升，资源用量也上升），也需要包括一些非自然增长的因素（新功能的发布、商业推广，以及其他商业因素在内）。容量规划有几个步骤是必需的。

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

• 高效地利用各种资源是任何赢利性服务都要关心的。如果能够通过密切关注一个服务的容量配置策略，进而改进其资源利用率，这可以非常有效地降低系统的总成本。一个业务总体资源的使用情况是由以下几个因素驱动的：用户需求（流量）、可用容量和软件的资源使用效率。

第2章 Google 生产环境：SRE视角

硬件

• 物理服务器（machine）代表具体的硬件（有时候也代表一个VM 虚拟机）。

• 软件服务器（server）代表一个对外提供服务的软件系统。