本文原作者：Alex Hidalgo

想象一下，当你舒舒服服地窝在沙发上，打开你最喜欢的数字媒体流媒体服务，准备看电影，然后按下了遥控器上的一个按钮。大多数时候，电影缓冲几秒钟就开始播放。但如果电影需要整整 20 秒才能缓冲呢？你当时可能会有点恼火，但最终电影还是流畅地播放了。尽管出了这点小问题，这个服务依然表现得相当可靠，因为大部分时间它缓冲的时间都远远不到 20 秒。

要是每次缓冲都要花 20 秒呢？那情况就完全不同了，从有点烦人到完全不可靠。在众多数字媒体流媒体服务中，你可能会选择放弃这个服务，转而选择另一个。

没有什么是完美的，也没有任何系统能够做到 100% 可靠。这不仅是现实，而且人们似乎也完全接受这一点！没人真的指望计算机系统时刻完美运行；我们只需要它们在足够多的时候足够可靠。

那么，我们该如何确定合适的可靠性水平呢？这时可靠性堆栈就派上用场了。它由三个部分组成：服务等级指标（SLI）、服务等级目标（SLO）和错误预算（Error Budget）。

可靠性堆栈的基础是 SLI，它是从用户角度衡量你的服务。为什么是用户？因为你的系统必须为用户良好运行。用户决定了你的服务是否可靠。如果他们的电影每次缓冲都要花 20 秒，没人会在意你那边看起来多么完美。一个 SLI 的例子可能是：“电影缓冲时间不超过 5 秒。”

接下来是 SLO。SLO 由 SLI 驱动。如果 SLI 是衡量服务运行情况的指标，SLO 则是你希望它们达到良好运行状态的频率目标。以我们的例子来说，你现在可能想说：“电影缓冲时间不超过 5 秒，这种情况要占 99%。”如果缓冲时间超过 5 秒的情况只在 100 次中发生 1 次，大多数人可能都能接受。

没有什么是完美的，所以别追求完美。相反，要确保你只是在足够多的时候保持可靠。如果你试图追求完美，会耗费无限的人力物力资源。

最后，在可靠性堆栈的顶端是错误预算，它由 SLO 决定，仅仅是一个衡量你在一段时间内表现是否符合目标的指标。比起单纯知道你当前的运行情况，了解你在一周、一个月或一个季度内的表现要更有用。错误预算能让你说：“我们每个月不能有 7 小时 18 分 17 秒的缓冲不可靠情况。”你可以利用错误预算更全面地思考服务的可靠性。利用这些数据进行更好的讨论，并就如何解决可靠性问题做出更明智的决策。

你不可能完美，而且事实证明，没人指望你完美。利用可靠性堆栈来确保你的服务足够可靠。