SLO (service level objective)
An SLO (service level objective) is a target a team sets for a measured indicator of reliability, such as 99.95% of checks succeeding over 30 days.
An SLO has three parts: the indicator (SLI), the target and the window. "99.95% of requests succeed, measured over a rolling 30 days" is complete; "the site should be fast" is not.
A good SLO describes what users notice and is a little better than they need. Setting it at 100% leaves no room for change; setting it far below what you already deliver makes it useless as a warning.
The gap between the SLO and 100% is the error budget, which turns the target into a rule for how much risk the team can take.
Track an error budget against an SLO →
Questions
How many SLOs should a service have?
Few: one or two per user journey, usually availability and latency. More than that and nobody watches them.
Should the SLO window be calendar or rolling?
A rolling window (such as the last 30 days) reflects the current state at any moment; a calendar month matches billing and most SLAs. Many teams track the rolling one and report the calendar one.
Related terms
Monitor it with OpenUptime
Checks from one or several regions, alerts to the tools you use, and a status page for your customers. Free to start, open source under the MIT license.
SLO（服务等级目标）
SLO（服务等级目标）是团队为某个可靠性指标设定的目标，例如 30 天内 99.95% 的检查成功。
一个 SLO 由三部分组成：指标（SLI）、目标值和时间窗口。“滚动 30 天内 99.95% 的请求成功”是完整的；“网站要快”就不是。
好的 SLO 描述的是用户能感知到的东西，并且比用户的需要略高一点。定成 100% 就没有任何变更的余地；定得远低于现有水平，就起不到预警作用。
SLO 与 100% 之间的差距就是错误预算，它把目标变成了团队能承担多少风险的规则。
常见问题
一个服务应该有几个 SLO？
少而精：每条关键用户路径一到两个，通常是可用性和延迟。再多就没人看了。
SLO 的时间窗口用自然月还是滚动窗口？
滚动窗口（例如最近 30 天）随时反映当前状态；自然月与账单和多数 SLA 一致。很多团队日常跟踪滚动窗口，对外报告用自然月。