SRE

概述 凌晨三点，手机震动。你从被窝爬起来，打开电脑，SSH 上去，发现某个服务 CPU 飙升。Kill 进程，重启服务，12 分钟搞定——但你彻底清醒了。四点半又来一条告警：磁盘使用率超 85%。又爬起来，du -sh 定位，删掉过期日志，15 分钟。 这是无数运维工程师的日常。监控做了，告警配了，脚本也写了——但最后一步还是人在跑。而且偏偏在凌晨。 根据 Google SRE Book 的数据，一个典型的 SRE 团队每天接收 50-100 条告警，其中 80% 是噪音，超过 60% 的告警是重复处理过的已知问题。 告警自动化的目标不是消灭告警，而是把人的判断和操作转化为系统的自动响应。我将从告警降噪、分级路由、Runbook 自动化、自愈平台架构、AI 辅助治理五个维度，详细梳理如何构建告警自动化处理体系。 告警现状：为什么需要自动化 告警风暴的根源 告警风暴通常不是监控配置不足，而是配置泛滥的产物。以下是生产环境中最常见的告警问题模式： 问题模式 典型表现 根因 告警泛滥 每天 100+ 条告警，80% 无需人工介入 静态阈值过敏感，缺少聚合和去重 告警疲劳 工程师忽略告警通知，真正故障被淹没 信号噪声比太低，缺少优先级分级 重复告警 同一问题触发多条告警，不同监控视角 缺少告警关联和聚合机制 响应延迟 从告警到人工处理平均 15-30 分钟 缺少自动化响应，依赖人工介入 重复劳动 超过 60% 的告警处理流程完全相同 没有将已知操作沉淀为自动化 Runbook 告警生命周期的五个阶段 一个成熟的告警自动化系统应该覆盖告警的完整生命周期： ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 1. 产生 │────▶│ 2. 降噪 │────▶│ 3....

概述 故障不可避免，但故障响应的质量决定了影响范围和持续时间。一个成熟的故障响应框架能够在混乱中建立秩序——让正确的人在做正确的事，让信息流向该去的地方，让恢复速度尽可能快。 很多团队在故障发生时面临的真实场景是：告警轰炸、群消息刷屏、不知道谁在负责、重复排查同一个问题、对外信息不一致、故障恢复后说不清楚做了什么。这些问题的根因不是技术能力不足，而是缺乏结构化的响应框架。 从故障分级、响应角色分工、escalation 路径设计、通信模板、时间线记录到恢复策略，详细梳理如何构建一个可执行的故障响应框架。 关于故障响应的系统方法论，可参考 Google SRE Book - Managing Incidents 和 Atlassian Incident Management Handbook。 一、故障分级标准 为什么需要分级 没有分级的故障管理等于没有管理。如果所有故障都按最高优先级处理，结果就是没有真正的最高优先级。故障分级的本质是资源调度优先级——在有限的人力下，让最严重的故障优先获得资源。 SEV 分级标准 采用业界通行的 SEV1-SEV4 四级分类： 级别 定义 影响范围 响应时效 升级条件 示例 SEV1 生产服务完全不可用或核心功能失效 全量或大量用户受影响，营收直接损失 立即响应，<5min 15min 无进展自动升级 支付服务宕机、数据库不可用、核心 API 全部 5xx SEV2 核心功能严重降级 部分用户受影响，业务功能受损 <15min 30min 无进展自动升级 支付成功率下降 20%、P99 延迟劣化 5 倍 SEV3 非核心功能降级或潜在风险 少量用户受影响或无直接影响 <30min（工作时间） 无需自动升级 某非核心服务异常、磁盘水位 80% SEV4 优化建议或已知问题 无用户影响 下一工作日 无需升级 告警阈值优化、文档补充 分级判定要素 故障分级需要考虑多个维度，不是单一指标决定的： # 故障分级判定矩阵 severity_matrix: dimensions: - user_impact: # 用户影响 none: 0 minimal: 1 # <1% 用户受影响 moderate: 2 # 1-10% 用户受影响 significant: 3 # 10-50% 用户受影响 severe: 4 # >50% 用户受影响 - business_impact: # 业务影响 none: 0 low: 1 # 非核心功能，无营收影响 medium: 2 # 核心功能降级，营收轻微影响 high: 3 # 核心功能失效，营收明显损失 critical: 4 # 全站不可用，营收严重损失 - duration: # 持续时间（已持续或预计） unknown: 3 # 未知持续时间按高风险处理 brief: 1 # <5 分钟 short: 2 # 5-30 分钟 medium: 3 # 30 分钟 - 2 小时 long: 4 # >2 小时 # 最高维度决定 SEV 级别 rule: "max(user_impact, business_impact) + duration_bonus" # duration_bonus: 如果持续时间 > 预期，SEV 上调一级 自动分级 理想状态下，故障级别应该能通过告警规则自动确定：...

概述 错误预算（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 设计的起点是业务目标，而不是技术指标。业务目标回答的问题是：这个服务对业务的价值是什么？...