SRE基础

概述 错误预算（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 违规都消耗预算：...

概述 很多团队在实践 SRE 时遇到的第一个困境是：知道 SLO 是什么，但不知道怎么设。要么照搬 Google 的 99.99%，要么随便拍一个 99.9%——然后发现这个数字既不反映用户体验，也无法驱动工程决策。 好的 SLO 不是拍脑袋拍出来的，而是从业务目标出发，经过用户旅程分析、指标选择、数值校准、多层级设计、定期评审等一系列工程方法推导出来的。详细梳理 SLO 设计的完整方法论，帮助你建立从"业务目标"到"技术指标"的完整映射链路。 本文假设读者已了解 SLI/SLO 的基本概念。如需补充，可参考 Google SRE Workbook - Service Level Objectives 和本站 SRE核心理念：SLI、SLO与错误预算。 一、SLO 设计金字塔 SLO 设计不是孤立的技术活动，而是从上到下的分层推导过程： ┌─────────────┐ │ 业务目标 │ "我们的服务需要做到什么程度？" └──────┬──────┘ │ ┌──────▼──────┐ │ 用户体验 │ "用户关心什么？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLI 定义 │ "我们怎么衡量用户体验？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLO 目标值 │ "这个指标要做到多少？" └──────┬──────┘ │ ┌──────▼──────┐ │ 告警与行动 │ "不达标时怎么办？" └─────────────┘ 第一层：业务目标 一切 SLO 设计的起点是业务目标，而不是技术指标。业务目标回答的问题是：这个服务对业务的价值是什么？...