SRE对风险的考量
- SRE旨在寻求快速创新和高效的服务运营业务之间的风险的平衡，而不是简单地将服务在线时间最大化。
- 用户通常不会注意到一项服务在高可靠性和极端可靠性之间的差异，因为用户体验主要是受较不可靠的组件主导。比如：用户在一个有着99%可靠性的智能手机上是不能分辨出4个9和5个9的可靠性的区别。
- 运维风险与业务风险进行对应。稍高于用户可靠性需求即可。过多的考虑可靠性，会非线性的增加资源成本和机会成本。
- 可用性度量方法：1）基于时间的可用性，即正常运行时间与总时间的比值；2）合计可用性，即成功请求数与总请求数间的比值。具备多数据中心的应用，通常基于时间的可用性意义不大，因为总有一部分服务是正常的。这种情况下后者会更具参考价值。
- 可用性目标设定时要考虑的因素：1）用户期望的服务水平；2）这项服务是否直接关系到收入；3）这是一个有偿服务，还是无偿服务；4）竞争对手的服务水平；5）针对的是消费者还是企业。
- 对于支持不同可用性目标的基础设施，可以通过区分建设不同等级的基础服务来分别支持。
错误预算的构建过程
- 产品管理层定义一个SLO，确定一项服务在每个季度预计的正常运行时间。
- 实际在线时间是通过一个中立的第三方来测算的：监控系统。
- 这两个数字的差值就是这个季度中剩余的不可靠性预算。
- 只要测算出正常在线时间高于SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新的版本。
思考
一直以来，大多数公司产品确定可靠性指标通常是两个依据：一是部门的组织能力建设的理想目标，5个9（万一实现了呢）；其实从未达到过，也没有人设计有说服力的度量，也没有人真的关心；另一个来源是友商的指标，比如：Salesforce是99.99%，ServiceNow 是99.97%。通常会设置为99.99%，然后通过内部的故障事故业务中断时长来进行基于时间的可用性计算。对于没有多数据中心持续提供服务的产品来说，这样也算合理。
对于错误预算与产品发布确实有道理。固定的月度/半月版本发布周期，或者极短业务承诺时间确实容易造成运维雪上加霜，上线靠烧香的悲情。用错误预算更容易让全团队在质量和上市间达成默契，后续可以在每次版本上线前加入checklist项，持续检查错误预算剩余配额，控制上线节奏。
