网站可用率与SLO怎么定义？从监控结果到错误预算
先定义用户需要哪种“可用”
服务器开机、端口能连、首页返回200和订单能够提交，分别代表不同能力。网站可用率若没有说明成功条件，就很容易成为一个无法解释的漂亮数字。
先选核心用户流程，再定义可测量的成功。例如公开文档页要返回预期内容，搜索接口需要在限定时间内给出有效结果。认证失败等正常业务拒绝是否计入错误，也应提前规定，避免统计时随意调整分母。
SLI是实际测量服务表现的指标，SLO是对该指标设定的目标。Google SRE的服务级别目标章节解释了这种关系，并强调从用户相关的服务行为出发。官方SLO说明
按时间和按请求计算，含义不同
按时间衡量，可用率可以用一减去“不可用时长除以总观察时长”得到；按请求衡量，则统计符合成功定义的请求占有效请求的比例。前者适合表达连续中断，后者更容易反映部分请求失败，两种结果不能直接混用。
假设一个服务在三十天窗口里完全中断十分钟，按时间口径可以计算相应比例。若同样十分钟恰好是业务高峰，按请求统计的影响可能更大；如果是低峰则可能更小。选择哪种口径，应由服务特点决定。
还要明确测量位置。源站内部探测成功，不能证明用户到CDN和DNS的路径正常；单个外部探测点失败，也可能反映该点自身网络异常。实际监控可以结合多个位置，但需要公开说明如何合并结果。
错误预算帮助安排改进与变更
如果某个SLO要求合格请求达到百分之九十九点九，那么同一窗口内允许的不合格比例就是百分之零点一。错误预算由目标和统计口径推导，用于观察服务消耗了多少可接受的不可靠性。
它不是主动制造故障的配额，也不意味着预算未用完就可以忽略用户投诉。实际使用中，可以根据预算消耗情况调整发布节奏、可靠性改进和问题处理优先级。Google的实施SLO章节提供了目标落地和持续改进的思路。实施SLO指南
假设近期几次变更已经消耗大部分预算，就值得减少非必要变更并优先修复重复故障。若目标长期轻易达到，也应检查指标是否遗漏了关键流程，而不是立即宣布系统没有改进空间。
低流量与局部故障需要补充解释
低流量接口可能因为一次失败就出现很大的百分比变化，也可能在没有请求时无法证明服务可用。可以结合合成探测与更长观察窗口，但应保持真实请求和探测指标各自的含义。
平均指标还会掩盖某个地区、地址族或特定接口的持续失败。可以为重要用户群和核心流程单独设定观察维度，再用总体指标查看整体趋势。不要用大多数正常请求稀释某条关键路径完全不可用的问题。
维护窗口是否纳入统计，也必须事先明确。若内部目标排除了计划维护，应单独报告维护影响，不能让用户实际无法使用的时间完全消失。对外服务协议的口径和赔付条件应按正式条款解释，内部SLO不自动等于合同承诺。
用固定口径复查，避免事后改定义
保存目标版本、测量查询、时间窗口和异常处理规则。出现事件后按既定定义计算，同时记录业务影响和未覆盖部分。如果发现指标设计不合理，可以为以后调整，但应保留调整原因和旧口径结果。
上线SLO前先用历史数据试算，确认数据完整性和目标是否具有业务意义。再检查告警是否能够及时发现预算快速消耗，而不是月底才发现整月表现未达要求。
一份可信的可用率报告应能回答成功是什么、数据来自哪里、哪些请求被排除以及发生了什么。这样数字才可以支持可靠性决策，而不是替代对用户体验的真实了解。