控制SLI和SLO实现的手段
SLI 和 SLO 在决策系统运维时也非常有用∶1.监控并且度量系统的 SLI。
2.比较 SLI 和 SLO，以决定是否需要执行操作。
3.如果需要执行操作，则要决定究竟什么操作需要被执行，以便满足目标。
4.执行这些操作。
例如，如果在第2步中，请求延迟正在上涨，无操作的话，会在几个小时内超出SLO范围。第3步则会测试服务器是否是CPU资源不够，同时增加一些CPU来分散负载。没有SLO的话，我们就不知道是否（或者何时）需要执行该动作。
通过公布SLO可以设置用户对系统行为的预期。用户（以及潜在用户）经常希望知道他们可以预期的服务质量，以便理解该服务是否能够满足他们的要求。例如，某个团队想要开发一个照片分享网站，可能会避免使用一个数据持久性高、成本低，但是可用性低的系统。但是，可能会使用另外一个存档信息管理系统。
为了让用户拥有正确的预期，我们可以考虑使用以下几种策略∶
留出一定的安全区
对内使用更高的 SLO，对外使用稍低的 SLO 可以留出一些时间用来响应问题。SLO 缓冲区也可以用来进行可能影响系统属性的重构，例如降低成本以及方便运维等，缓冲区保护我们不会对用户产生直接影响。
实际 SLO也不要过高
用户一般不会严格按照书本定义的SLO，而是按照实际情况来构建服务，这在基础设施类服务上非常明显。如果服务的实际性能要比 SLO宣传得好太多，用户可能会逐渐依赖于现在的假象。我们可以利用主观可控模式减少这种过度依赖。（Google Ch y服务会用计划内维护来避免过于可用。）同时，可以采取对一些请求限速，或者限制系统在低负载情况下也不会速度过快的手段。
理解系统行为与预期的符合程度可以帮助决策是否需要投入力量优化系统，使其速度更快、更可用，或者更可靠。如果服务一切正常，可能力量应该花在其他的优先级上，例如消除技术债务、增加新功能，或者引入其他产品等。
起草一份SLA需要业务部门和法务部门选择合适的后果条款。SRE在这个过程中的作用是帮助这些部门理解SLA的SLO达标的概率和困难程度。许多针对SLO的建议也同样适用于SLA。最好在用户宣传方面保持保守，因为受众越广，修改和删除一个不合适或者很有困难达到的SLA就越困难。
页:
[1]