SRE指导思想

Mon, Jan 1, 0001

拥抱风险

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

• 管理服务可用性主要在于管理风险，而且管理风险的成本可能很高
  • 冗余服务器／计算资源的成本
  • 机会成本
• 度量服务风险
  • 时间可用性=系统正常运行时间/(系统正常运行时间+停机时间)，比如99.99%的系统一年内停机时间不能超过52.56分钟
  • 请求可用性=成功请求数/总的请求数
  • 成本核算：成本<服务收入*增加的可用性
  • 避免对服务的过度依赖（用户错误的认为某个服务比实际情况更可靠），计划内停机：如果真实故障没有将可用性指标降低到SLO，有意安排一次可控的故障
• 错误预算
  • 只要系统符合SLO，就可以继续发行新版本
  • 当SLO违规导致错误预算接近耗尽时，减慢发布速度或者回退到上一版本

SLO

• 常见系统的指标
  • 用户可以的服务系统：可用性、延迟和吞吐量
  • 存储系统：延迟、可用性和数据持久性
  • 大数据系统：吞吐量和端到端延迟
  • 所有系统都应该关注正确性
• 系统指标应该以“分布”而不是平均值来定义（一组数据的百分比分布），比如
  • 90%的请求在1ms内完成
  • 99%的请求在10ms内完成
  • 99.9%的请求在100ms内完成
• 目标的选择
  • 从全局而不是目前状态为基础选择目标
  • 避免绝对值
  • 保持简单，SLO越少越好
• 建立用户预期
  • 流出一定的安全区
  • 但实际SLO不要过高，避免用户依赖现在的假象

减少琐事

如果系统正常运转中需要人工干预，应该将此认为是一种bug。“正常”的定义随系统的进步不断改变。

• 琐事是指那些手动的、重复的、可以被自动化的、战术性、没有持久化价值的工作
• 50%原则

监控告警

监控的目标

• 分析长期趋势
• 跨时间范围的比较
• 报警
• 建立监控台页面
• 临时性的回溯分析

建立信噪比高的监控系统

• 监控系统要解决“什么东西出现故障”和“为什么出故障”这两个问题
• 黄金指标
  • 延迟，区分成功和失败很重要
  • 流量
  • 错误，包括显式失败（比如500）、隐式失败（比如200回复中包含了错误内容）和策略原因导致的失败（比如超时）
  • 饱和度，系统在达到100%利用率之前会出现性能的严重下降
• 系统指标应该以“分布”而不是平均值来定义
• 简化告警系统
  • 避免告警太多导致“狼来了”效应
  • 每个告警都应该是可以具体操作的
  • 每个紧急告警的回复都应该包括某种智力分析过程，否则不应该成为紧急警报
  • 应对紧急警报经常会牺牲短期内的可用性和性能，以换取未来整体系统性能的提升

自动化

自动化的价值

• 一致性地执行范围明确、步骤已知的程序
• 提供可扩展、广泛适用的甚至可能带来额外收益的平台
• 修复速度更快
• 行动速度更快
• 节省时间

自动化的演进

• 没有自动化
• 外部维护的系统特定的自动化系统
• 外部维护的通用自动化系统
• 内部维护的系统特定自动化系统
• 不需要任何自动化的系统

发布

发布工程哲学

• 自服务模型：发布工程师开发工具，制定最佳实践，产品研发团队自主掌握自己的发布流程
• 追求速度
• 密闭性：构建过程不依赖系统的第三方类库或工具
• 强调策略和流程，代码评审，多层安全和访问控制
• 一开始就进行发布工程

持续构建与部署

• Blaze构建（开源版为Bazel）
• 代码默认提交到主分支，但发布新的分支
• 持续测试，自动单元测试
• 打包
• 集成测试和测试部署
• 部署（Sisyphus）

配置文件

• 使用主分支版本的配置文件
• 将配置文件与二进制文件一起打包
• 从外部存储服务中读取配置文件（Chubby、Bigtable等）

简单化

• 简单性是可靠性的前提
• 最小API
• 模块化