By

Contents

在Some practical advice when setting SLA中聊到了一些关于设置SLA的好的建议，值得一读，我把其中的一些要点记录如下。

  • SLA是有法律（Legal）和财务（Finance）的考虑的，是对客户的承诺。SLA是对外的，SLO是对内的，这是SLA和SLO的主要区别。
  • 高SLA是有成本的，要定义合适的SLA（而不是尽量追求高SLA）。通常来说，每增加一个9，运维和组织的成本需要增加10倍。高SLA带来的成本有下面几个方面。
    • 基础设施成本 - 更多的硬件资源
    • 复杂度 - 更高的复杂度带来更高的维护成本
    • 效率 - 更高的SLA通常意味着更谨慎（少、慢）的发布，更多的测试和流程。
  • 考虑服务依赖的第三方的SLA
  • SLA的设置要符合业务需求。比如对于医疗类的服务，可能5个9的高可用性都很有必要，但是对于其他的比如社交媒体，可能就不用那么高。
  • SLA的设置要务实。最常用的方法就是看看历史数据来决定一个合理的值。
  • 要考虑SLA的设置是日历月还是回看窗口。假设SLA设置一个月可以有1个小时的不可用时间，那么如果月末和月初都发生了50分钟的事故，如果按照日历月，SLA还是满足的，但是对用户的影响可能是巨大的，这样就需要考虑使用回看窗口。
  • 考虑适合用平均无故障时间（MTBF）还是平均修复时间（MTTR）。通常来说如果一个服务是连续的，比如在线视频服务，平均无故障时间更合适。反之，比如一个REST API，可能平均修复时间更合适。
  • 测量工具。如果SLA对应的SLI的测量工具不可用了，SLI的值肯定就不可靠了。
  • 测量的位置。比如可用性的检查，可以在k8s内部（这个通常不是好的测量位置），也可以在k8s外面但是在同一个云提供商里，还可以在云提供商之外，甚至在用户端。要根据服务的具体业务场景来决定合适的测量位置。
  • 状态页面。有一个页面可以给客户随时看服务状态是建立信任的好方法。
  • 采样。有些业务场景可能针对每一次服务计算SLI太过于昂贵，这个时候就需要考虑采样，当然采样要保证统计上能覆盖所有的数据。
  • 根据人造的访问来计算还是根据实际的访问来计算。
  • SLA不只是可用性（Availability或者uptime）。SLA的制定需要考虑业务需求，有时候可能需要延迟（Latency）、失败率（Error Rate）、CPU或者网络的饱和度（Saturation）。
DevOps
Contents