2.1. 拥抱风险
极端的可靠性会带来成本的大幅提升,过分追求稳定性限制了新功能的开发速度和产品交付给用户的速度。
SRE旨在寻求快速创新和高效服务运营之间的风险平衡,而不是简单将服务在线时间最大化。
2.1.1. 管理风险
可靠性进一步的提升需要的成本并不是线性的。 成本可能来自2个维度
计算成本: 比如说需要的更多冗余资源。
机会成本: 都忙稳定性了, 用户新功能和新产品的工作呢。
SRE管理服务,服务的可靠性很大程度上是通过管理风险来进行的。
目标是: 明确地将运维风险和业务风险对应进来,努力提高一项服务的可靠性,但不会超过该服务需要的可靠性。
需要做成本/收益分析的。
2.1.2. 度量服务风险
google标准做法是通过一个客观的指标来提现一个待优化的系统属性。
计划外宕机的度量方法
基于时间的可用性: 正常时间/(正常时间+ 停机时间)
基于次数的可用性: 成功请求数/总的请求数
2.1.3. 服务的风险容忍度
服务的风险容忍度通常直接根据基本能产品或服务的定义建立的。
SRE必须和产品负责人一起努力,将一组商业目标转化为明确的可以实现的工程指标。
2.1.3.1. 辨别消费者服务的风险容忍度
评价服务风险容忍度,有需要考虑的因素,比如:
需要的可用性水平是什么?
不同类型的失败对服务有不同的影响吗?
我们如何使用服务成本呢来帮助在风险曲线上定位这个服务?
有哪些其他重要的服务指标需要考虑。
2.1.3.1.1. 可用性目标
服务的可用性目标通常取决于提供的功能以及市场上的定位。下面是一些考虑因素。
用户期望的服务水平是什么
是否影响收入
收费还是免费
有竞争对手吗,对手服务水平如何
toB 还是toC
2.1.3.1.2. 故障类型
可以接受计划内的常规服务中断,认为维修窗口中发生的偶然的、正常的、计划之中的故障是可以接受的,这些故障看做计划内停机时间。
2.1.3.1.3. 成本
成本是一个重要考虑的因素了,需要有对比的。比如下面的
可用性目标 99%=>99.9%
增加的可用性 0.09%
服务的收入 100万美元
改进后的价值 100万 * 0.09% =900美元
# 然后比较下需要投入的成本和价值。
2.1.3.2. 基础设施服务的风险容忍度
基本设施服务组件有很多客户,他们都有很多不同的需求。
2.1.3.2.1. 可用性目标
可以针对不同目标设置不同稳定性需求。
2.1.3.2.2. 故障类型
2.1.3.2.3. 成本
可以维护多个集群,对应不同的用户需求。
2.1.4. 使用错误预算的目的
开发和运维绩效评估是不同的,SRE的绩效表现取决于可靠性,开发的绩效取决于快速创建代码。
目标是定义个双方都愿意的客观指标,该指标用来指导谈判方向,一项决策越是基于数据的,一般就越好。
2.1.4.1. 错误预算的构建过程
产品管理层定义一个SLO
sli计算系统
差值
指导
2.1.4.2. 好处
错误预算主要好处是它能够激励产品研发和SRE一起找出创新和可靠性之间合理的平衡点。