SLO 和 SLI的最佳实践

1. 我们要给犯错以空间，充分考虑错误预算。否则，开发团队可能会在尝试新功能时过于谨慎，抑制产品的增长。不过作为一般经验法则， SLO 应该比你在 SLA 中详细说明的内容更严格。
2. 在一开始启动 SLO 的时候，你可能没有办法确定当前系统整体的情况，所以我会建议从一个较低的 SLO 目标开始，根据团队整体的成熟度逐渐提升 SLO 的目标。设定这个目标需要考虑产品的性质、团队的优先级以及最终用户的期望，然后不断进行动态调整。例如，你的团队持续大幅超越目标，你可能希望收紧这些值，或者加大开发力度来利用未使用的错误预算；但是如果团队一直未能实现目标，那么把它们降到更容易实现的水平，或投入更多时间来稳定产品可能就是明智之举。
3. 保持耐心，你的团队可能需要一段时间才能找到跟踪和维持 SLO 目标的诀窍。如果改变没有在一夜之间发生，不要气馁。请继续和你的团队讨论这些工具和概念，尝试各种想法，朝着更好的监控和可靠性目标进发。这里具体包括：与利益相关者开会，努力就可靠性标准达成一致；对 SLO 进行优先级排序，收集一个月的 SLI 数据并进行分析和调整，等等。就像软件迭代一样，SLO 的建设也是个逐步完善的过程。
4. 在定义 SLO 目标时，建议不要设置过多的 SLO 或使 SLI 过于复杂。比如说，你可能会为一个用户使用产品的关键旅程中的每个相关集群、主机或组件设置单独的 SLI，但这样做不如尝试以有意义的方式将它们聚合为单个 SLI，然后花更多时间关注那些真正影响最终用户使用体验 SLI。这有助于消除很多“噪音”，让你专注于真正重要的事情。
5. 面向最终用户体验和性能的指标才是合格的 SLI。比如说你的应用软件后端是一个高可用集群，如果集群有一个节点出现问题，但却并不会影响用户正常的使用，这时候这个节点的故障就不适合作为 SLI。当然，并不是说这个故障节点就完全不用理会了，我们也应该设置相关的监控和告警，在出现问题的时候及时修复。否则如果再有节点出现问题，就可能让用户无法使用产品服务了，这就影响到 SLO 了。

总体而言，系统的可靠性并不是我们的监控和日志来决定的，而是由我们产品的最终用户说了算。你编写的代码和设计的系统都是为你的用户服务的。毕竟，如果我们构建了一个没人使用的东西，那么我们最好把时间和精力花在其他事情上。

可靠性是所有系统最重要的要求，因为它是用户信任的基础。如果用户不信任系统，他们就不会使用它，很快我们的系统就会没有用户了。换句话说，即使产品和服务提供了更多的新功能，如果它们不可靠，也就不会被信任，就会无人关注。

此文章为3月Day12 学习笔记，内容来源于极客时间《深入浅出可观测性》，推荐该课程。