SEV

概述 故障不可避免，但故障响应的质量决定了影响范围和持续时间。一个成熟的故障响应框架能够在混乱中建立秩序——让正确的人在做正确的事，让信息流向该去的地方，让恢复速度尽可能快。 很多团队在故障发生时面临的真实场景是：告警轰炸、群消息刷屏、不知道谁在负责、重复排查同一个问题、对外信息不一致、故障恢复后说不清楚做了什么。这些问题的根因不是技术能力不足，而是缺乏结构化的响应框架。 从故障分级、响应角色分工、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 上调一级 自动分级 理想状态下，故障级别应该能通过告警规则自动确定：...