SLO解决的问题
成本和收益的矛盾, 要平衡成本和收益, 而不是一味的追求几个9, 得不偿失
科学的运维: 有了SLO, 就有了可量化的标准, 不用总怕出现故障, 只要故障在SLO范围内就是可接受的, 节省出精力用在更重要的事情上
稳定和创新(变更)的矛盾
合理设定SLO
设定原则
区分哪些是核心应用，哪些是非核心应用, 核心应用的 SLO要更严格，非核心应用要放宽
不应该以消灭故障为目的, 要接受故障的发生, 确保故障在SLO标准的范围内，高于这个标准会浪费人力和成本，低于这个标准就需要进行优化
强依赖之间的核心应用，SLO要一致
核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段, 避免由非核心应用的异常而导致核心应用SLO不达标
如果某个核心应用错误预算消耗完，SLO没有达成，那整条链路原则上要全部暂停变更
设定方法
SLO1：99.95% (SLI为状态码成功率)
SLO2：90% (SLI为Latency <= 100ms的百分比)
SLO3：99% (SLI为Latency <= 300ms的百分比)
Availability = SLO1 & SLO2 & SLO3, 只有三个SLI均达到其设定的SLO, 系统的稳定性才算达标
将SLO转化为Error Budget(错误预算)
可类比驾照记分制, 最大的作用就是提示你还有多少次犯错的机会
在 SLO 落地实践时，我们通常就把 SLO 转化为错误预算，以此来推进稳定性目标达成
通过SLO反向推导出错误预算(错误次数), 对于推广等特殊场景, 应合理放大错误预算值
建议以4个自然周为一个统计周期
稳定性燃尽图
故障定级(量化管理)
P0: 故障导致消耗错误预算的比例 > 50%
P1: 30% < 消耗的错误预算比例 <= 50%
P2: 20% < 消耗的错误预算比例 <= 30%
P3: 5% < 消耗的错误预算比例 <= 20%
P4: 消耗的错误预算比例 <= 5%
确定稳定性共识机制
建立稳定性共识机制一定要自上而下，至少要从技术 VP 或 CTO角色去推行, 自上而下推进周边团队或利益方达成共识
原则1: 剩余预算充足或未消耗完之前(也就是SLO达标的状态下)，其他团队或领导需要对故障的发生有容忍度, 不要因为出现故障就认为系统不稳定
原则2: 剩余预算消耗过快或即将消耗完之前，SRE有权中止和拒绝任何线上变更
基于错误预算进行告警
也就是只关注对稳定性造成影响的告警, 有效做到告警收敛
当单次问题/故障消耗的错误预算达到 10% 或 20% 等某一阈值时，就意味着问题非常严重了, 要及时响应
如何衡量 SLO 的有效性
1. SLO达成(Met)或未达成(Missed)
2. 人肉投入(Toil)程度高(High)或低(Low)
3. 用户满意度(Customer Satisfaction)高(High)或低(Low)
根据以上3个维度周期性的对SLO和错误预算进行合理的调整和优化
