资讯文章资讯 · NEWS

可用性该定到几个九：目录站的 SLO、错误预算和那条抓取成功率线

2026-10-24 约 1,795 字预计阅读 4 分钟 yiyunkj

大多数团队的监控是「指标过剩，判断力不足」：几十张仪表盘，出问题的时候还是回答不了「现在到底算不算故障」。

缺的是目标。SRE 那套方法之所以有用，不是因为工具，而是因为它逼你先把三件事写下来：量什么（SLI）、目标多少（SLO）、超了怎么办（错误预算策略）。

SLO 目标值对应的每月允许不可用时间与错误预算消耗分档

图片来源：网络，版权归原作者所有，侵权请联系删除

三个概念，一句话各自说清

SLI 是对用户可见行为的量化测量，比如请求成功率、响应延迟。SLO 是给这个指标定的目标，比如 30 天内 99.9% 的请求成功。错误预算就是 SLO 反过来那部分——99.9% 的目标意味着 0.1% 的不可用额度可以花。

错误预算的价值在于它把「要不要发版」从争论变成了算术。预算健康就正常发，烧得快就放慢高风险变更，烧完了就停下发版、先修稳定性。

选目标之前先看看代价。每多一个九，成本大致涨一个量级。

目录站定 99.9% 基本够用。往上调不是不行，但先想清楚：多出来的那几十分钟，是用冗余机器换，还是用更慢的发版节奏换。

不要一上来就定十个。挑跟用户体验和收录直接相关的，三到五个足够。

定义：返回 2xx 的请求数除以总请求数。注意这里要把 5xx 算失败，4xx 通常不算——除非是本来该 200 的页面返回了 404。

目录站上这个指标最容易被 CDN 掩盖。CDN 缓存了页面，源站挂了用户也看不出来，但爬虫请求的是源站。所以这个 SLI 要按来源分开算：用户侧一次，爬虫侧一次。

这是目录站特有的一条，也是跟收录关系最直接的。定义：搜索引擎爬虫请求中返回 200 的比例。数据只能从服务器日志来——先按反向加正向 DNS 验证确认是真实爬虫，再单独统计。

这条线建议单独定一个 SLO，而且要比用户侧的更严。原因很简单：用户这次打不开，下次还能再来；爬虫连续几次拿不到 200，会降低抓取频率，严重的会掉索引。谷歌在《降低抓取频率》相关文档里也提到，长期返回 5xx 会让抓取量下降。

不要用平均值，用分位数。建议量 p95，目标写成「95% 的列表页请求在 800 毫秒内返回」这种形式。平均值会被大量快请求拉平，看不出问题。

目录站很多内容是定时生成的：新条目入库、缩略图更新、外链巡检。这类异步任务适合定一个「及时性」SLO，比如 99% 的任务在 5 分钟内跑完。任务积压往往比宕机更早暴露问题。

没有应对策略的 SLO 只是一个仪表盘数字。至少要把三种状态对应的动作定清楚。

还要定义「谁有权限宣布进入第三种状态」。这个决策权不明确，预算机制就等于没有。

只看 30 天窗口的问题是：等你发现 SLO 不达标，预算早就花完了。所以要用消耗率（burn rate）告警——监控的是「消耗预算的速度」，而不是「还剩多少」。

谷歌 SRE 实践里的经典做法是配对窗口：同时看一个长窗口和一个短窗口，两个都超阈值才告警。长窗口保证确实消耗了有意义的预算，短窗口保证问题现在还在发生。这样能避免「半夜抖一下就告警」和「慢慢恶化却没人管」两个极端。

具体阈值要按自己的 SLO 窗口和目标算，不要直接抄别人的数字。

拿 CPU、内存当主 SLI。它们是排查用的诊断指标，不是用户体验指标，不适合当 SLO 的目标对象。

所有接口共用一个 SLO。列表页、条目页、提交接口的重要程度完全不同，至少要分两档。

把计划内维护不算进去。错误预算应该包含计划内停机——既然你主动接受这段时间不可用，就该从预算里扣。

忘了归档窗口。大版本迁移、机房切换这类已知会消耗预算的操作，提前划一个例外窗口并写进记录，否则事后复盘说不清。

不用一步到位。第一版只需要：选两个 SLI（页面成功率、抓取成功率），各定一个 30 天目标，配一条消耗率告警，写清楚预算耗尽时谁来决定停发版。跑三个月再回头调目标值。

对目录站来说，这套东西真正的价值不在发版决策，而在那句以前说不清的话——「我们的站最近稳不稳」，现在有了一个所有人都能认可的数字。