B. Google SRE指导思想 - 拥抱风险
概述
目标：快速创新和高效的服务运营业务之间的风险的平衡
提升可靠性的成本
冗余的物理服务器/计算资源的成本
机会成本
度量服务的风险
基于时间的可用性
系统正常运行时间 / (系统正常运行时间 + 计划外停机时间)
合计可用性
成功请求数 / 总请求数
服务的风险容忍度
辨别消费者服务的风险容忍度
风险评估因素
需要的可用性水平
不同类型的失败对服务有不同的影响吗？
我们如何使用服务成本来帮助在风险曲线上定位这个服务
有哪些其他重要的服务指标需要考虑
等等
可用性目标
用户期望的服务水平是什么
这项服务是否直接关系到收入（我们的服务还是我们的客户的收入）
这是一个有偿服务，还是一个免费服务
如果市场上有竞争对手，那些竞争对手提供的服务水平如何
这项服务是针对消费者和企业的
等等
故障类型
给定服务的故障预期：不同类型的服务能够接受的故障不一样
成本
可量化的：直接计算，比如说广告系统
不可量化：低于背景（各种协议）误差率，基本上在0.01% ~ 1%
其他服务目标
响应延迟时间
等等
基础设施服务的风险容忍度：以Bigtable为例
概述：有多个用户，每个用户有很多不同的需求
关键战略：明确划分服务水平，从而是客户能够在构建系统时正确的风险和成本平衡
可用性目标
消费终端团队：低延时，高可靠
离线数据分析团队：高吞吐量
故障类型
低延时用户：请求队列为空
离线分析用户：队列总是满，Bigtable应该避免处于空闲状态
成本
针对不同的目标部署多套系统，比如说低延时集群和高吞吐量集群
低延时集群：资源冗余度高
高吞吐量集群：资源冗余度低
错误预算
问题：系统可靠性和产品创新速度之间的矛盾
软件对故障的容忍度：做的太少，产品脆弱无用，做的太多，失去市场机会
测试
发布频率：每一次发布都是有风险的
金丝雀测试的持续时间和大小
步骤
产品管理层定义一个SLO，确定一项服务在每个季度预计的正常运行时间
实际在线时间是通过一个中立的第三方来测算的：我们的监控系统
这两个数字的差值就是这个季度剩余的不可靠性预算
只要测算出的正常在线时间高于SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新版本
好处：统一产品和SRE的目标
