SLO

概述 99.5% 的可用性听起来不错——直到你算一笔账。 一年 8760 小时，99.5% 意味着允许停机 43.8 小时。换算到每个月，差不多 3.65 小时的服务中断。如果是核心交易系统，这 3.65 小时可能就是几十万的订单损失。如果赶在大促期间，损失会翻几十倍。 99.9% 呢？年停机 8.77 小时，月均不到 44 分钟。停机时间砍掉 80%。 0.4 个百分点的提升，背后不是加几台服务器那么简单。我在某出行平台推动过一次这样的改造，从立项到稳定运行在 99.9% 以上，花了整整 14 个月。这期间踩的坑、做的权衡、推翻重来的方案，比写代码本身多得多。 这篇文章不讲理论框架，只拆解我们做过的 6 个关键工程决策，以及 3 个让我后背发凉的踩坑时刻。每个决策都附上我们当时的选型对比和最终方案，你拿去就能对照自己的系统查漏补缺。 可用性的数学本质：为什么 0.4% 这么难 先搞清楚一件事：可用性不是加法，是乘法。 假设你的系统由 3 个服务串联组成，每个服务可用性 99.5%。整个链路的可用性是多少？ 0.995 × 0.995 × 0.995 = 0.9851 ≈ 98.51% 三个"还不错"的服务串联起来，整体可用性直接跌破 99%。年停机从单服务的 43.8 小时暴涨到 128 小时——超过 5 天。 反过来想：如果链路有 10 个服务，每个要达到整体 99.9% 的可用性，单个服务的可用性得是多少？ 0.999^(1/10) ≈ 0.99990 → 99.99% 十个服务每个都得做到四个九。这就是为什么微服务架构下可用性提升的难度呈指数级增长。 关键认知：提升可用性不是给单个服务加机器，而是同时做三件事——减少串联依赖数量、提高单个服务可用性、在关键路径上做冗余和降级。 Google SRE 团队在 The Calculus of Service Availability 中提到一个观点：大多数服务的内部目标应该定在 99....

概述 凌晨三点，你被告警吵醒。爬起来一看：CPU 正常、内存正常、Pod 也在跑，但用户投诉说"系统卡得用不了"。你打开 Grafana 面板，画了一堆曲线，却说不清楚——这到底算不算故障？ 这个场景，我在多个企业客户的 SRE 咨询中反复遇到。核心问题不是监控不够多，而是度量体系设计错了方向：我们一直在监控"系统内部的指标"，而不是"用户感受到的服务质量"。 曾经在一次某出行平台的故障复盘中，团队发现一个讽刺的事实：告警系统在故障发生 12 分钟后才触发，而用户在故障发生后 30 秒就已经开始投诉了。原因很简单——告警基于 CPU 使用率超 80% 触发，但实际故障是数据库连接池耗尽，CPU 才 35%，根本没碰阈值。 可靠性度量的本质，是把"系统稳不稳"这个问题，从主观感觉变成可量化的数字。这篇文章不讲 SLI/SLO 的基础概念（这些在 相关文章：SRE核心理念：SLI、SLO与错误预算 中已经讲透了），而是聚焦于：如何从零设计一套完整、可落地、能驱动决策的可靠性度量体系。 为什么传统监控体系不能回答"系统稳不稳" 先说结论：传统监控体系回答不了"系统稳不稳"，因为它度量的对象错了。 传统监控的三个盲区 盲区一：监控的是资源，不是用户体验 大多数团队的监控面板长这样：CPU 折线图、内存折线图、磁盘 IO 折线图、网络流量折线图。这些指标反映的是"服务器忙不忙"，而不是"用户爽不爽"。 举个真实的例子：某电商平台的订单服务，CPU 使用率常年 70%，运维觉得"不太对劲"，计划扩容。但实际上 P99 延迟 120ms，请求成功率 99.97%，用户体验完全没问题。另一个缓存服务，CPU 才 20%，看起来"很健康"，但缓存命中率从 95% 掉到 60%，导致数据库被打爆，用户实际体验已经很差了。 盲区二：没有"好"和"坏"的量化边界 “CPU 80% 算好还是算坏？"——这个问题在传统监控体系里没有答案。80% 可能是正常的批处理负载，也可能是即将打满的前兆。没有 SLO 的情况下，80% 就只是一个数字，不是判断依据。 Google SRE Book 里有一段话说得很到位：“如果你不能度量它，你就不能管理它。” 但更准确的说法应该是：如果你度量错了对象，比不度量更危险——因为你会基于错误的信号做决策。 盲区三：告警基于静态阈值，不感知业务影响 传统告警的逻辑是"指标超过阈值就报”。问题是，同样的阈值在不同业务场景下含义完全不同： 场景 CPU 80% 含义 是否需要告警 凌晨 2 点批处理任务 正常负载 不需要 大促期间核心交易服务 即将打满 紧急告警 测试环境压测中 预期行为 不需要 生产环境空闲时段 异常进程 需要排查 静态阈值无法区分这些场景，导致的结果就是：要么告警太多（告警疲劳），要么告警太晚（用户已经投诉了才报）。...

概述 告警是监控系统的"最后一公里"，也是最难做好的一环。一个常见的困境是：服务器上跑着几十个告警规则，每天产生上百条告警通知，值班工程师在微信/钉钉/邮件的轮番轰炸下逐渐麻木——真正紧急的告警被淹没在噪声中，直到客户投诉才发现系统早已出问题。 SRE 的黄金法则是：每一条告警都应该有明确的处理动作。如果一个告警收到后既不需要立即处理，也不需要记录跟踪，那它就不应该存在。从告警疲劳问题出发，详细梳理告警分级、SLO-based 告警设计、抑制与聚合策略、告警度量指标和治理方法，帮助你从"告警噪声"中提取出真正的"信号"。 参考来源：Google SRE Book《Monitoring Distributed Systems》、Prometheus 告警好的实践 一、告警疲劳：问题的根源 1.1 告警泛滥的典型表现 某团队告警统计（一周）： ┌──────────────────────────┬────────┬──────────┐ │ 告警类型 │ 数量 │ 实际处理 │ ├──────────────────────────┼────────┼──────────┤ │ CPU 使用率 > 80% │ 156 │ 3 │ │ 磁盘使用率 > 70% │ 89 │ 2 │ │ Pod 重启 │ 34 │ 5 │ │ HTTP 5xx 错误率 > 1% │ 12 │ 4 │ │ 数据库连接数 > 80% │ 8 │ 1 │ │ 证书即将过期 │ 3 │ 1 │ │ 服务不可达 │ 2 │ 2 │ ├──────────────────────────┼────────┼──────────┤ │ 总计 │ 304 │ 18 │ └──────────────────────────┴────────┴──────────┘ 有效告警率：18/304 = 5....

概述 错误预算（Error Budget）是 SRE 体系中最精妙的机制设计。它把"稳定性 vs 迭代速度"这个长期依赖口水战的矛盾，转化为一个可量化的工程决策框架：你的系统有一个"不可用额度"，花完了就得停下来修。 但实践中，很多团队定义了 SLO 和错误预算之后，就止步于仪表盘上展示一个百分比数字。预算耗尽时该怎么办？快耗尽时要采取什么行动？预算富裕时可以做什么？这些关键问题如果没有明确的策略，错误预算就只是一个好看的数字，而非真正驱动行为的工具。 详细梳理错误预算的消耗状态模型、每种状态对应的行动纲领、发布冻结的标准与流程、预算滚存与重置策略、跨团队协调机制，并配以实战案例。 本文假设读者已了解 SLI/SLO/错误预算的基本概念。如需补充，可参考 Google SRE Book - Embracing Risk 和本站 SRE核心理念：SLI、SLO与错误预算。 一、错误预算的工程本质 不只是"还剩多少额度" 很多人把错误预算理解为"这个月还能宕机多少分钟"。这只是表面理解。错误预算的工程本质是： 错误预算是创新速度与系统稳定性之间的自动调节阀。 它回答了一个在所有工程团队都存在但很难回答的问题：我们现在应该更激进地发布新功能，还是应该停下来提升稳定性？ 预算充裕 → 系统足够稳定，可以承担更多变更风险 → 加速发布 预告耗尽 → 系统已经接近可靠性边界 → 减速发布，专注稳定性 这个调节是自动的、基于数据的、不依赖个人判断和政治博弈的。 错误预算的计算 SLO = 99.9%（30天窗口） 错误预算 = (1 - SLO) × 时间窗口 = 0.1% × 43200 分钟 = 43.2 分钟/月 已消耗预算 = 实际不可用时间 剩余预算 = 43.2 - 已消耗时间 预算消耗率 = 已消耗预算 / 总预算 但"不可用"的判定不只是"服务完全宕机"。任何 SLI 违规都消耗预算：...