查看原文

本文介绍了什么情况下服务是 success 的，以及如何评定服务是 success 的。而 success 的前置条件是 availability（可用性）。可用性指的是在给定时间段内服务有否达到其预期的功能。

有人用 success-requests-count / total-requests-count, 有人用 up-time / total-time，不管哪个指标，都希望其到达 99.9% 甚至 99.999%。例如，假设使用了 99.9% 用于 up-time, 那么服务一个月不能超过宕机 43.2min (30days)。此外，Mean Time Between Failures (MTBF): total uptime / # of failures； Mean Time to Repair (MTTR): total downtime / # of failures 这两个指标可以用来设定 error budget。我们甚至可以用 (Total Period / MTBF) * MTTR 给出针对服务及团队人力合适的 downtime 预测值。

但是，仅仅是这样是很不够的。服务除了没挂，不能出错也是必须的吧？登录系统点击登录按钮后死活不能登录，支付系统点击支付按钮后每个人都没有扣钱，这样子的服务很难说得上是 available 吧？这就引入了 user experience with black-box monitoring。这里的黑箱子，指的是我们不 care 后端服务是怎么实现的，我们只关心它向外暴露的功能是否正确达到了。

这就要求我们要根据 business goal 去设定具体的指标。这样的指标一般会是 XXX服务 有 Y％ 的请求在 Z秒内返回了正确的值，其异常情况包括 超过 Z 秒但还是正常返回了，Timeout 没法返回，返回了错误等等。需要注意的是，这个值需要跟 Operations 的团队一起讨论，因为这个值越高，Operations 付出的人力越大，开发节奏就相应地越慢。

在 Google 内部，他们更偏向于使用 Availability Figures，而不是 MTBF，MTTR。