SRE指导思想

拥抱风险

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
  • 模块化
Feisky wechat
微信公众号订阅