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
- 模块化