大家好，我是G探险者！
像滴滴、阿里、腾讯、华为、字节等大型互联网公司都会对线上故障（事故）进行分级管理，以便快速响应、统一调度、追责复盘。
下面我给你系统性地介绍一下——常见的互联网公司故障分级标准（P0~P4），并结合滴滴、阿里等企业的实践来说明：
🚨 一、故障分级的总体目标
通过分级来 量化故障影响范围与严重程度，从而决定响应等级、通知机制、处理时限与复盘流程。
一般采用的分级体系如下：
| 等级 | 典型名称 | 严重程度 | 典型响应要求 | 影响范围 |
|---|---|---|---|---|
| P0 | 特级故障 / 灾难级故障 | 🔥🔥🔥🔥🔥 | 立即全员响应（7x24小时），高层汇报，最高优先级抢修 | 核心业务全面不可用、用户大面积中断 |
| P1 | 一级故障 / 严重故障 | 🔥🔥🔥🔥 | 分分钟级响应，部门总监级跟进 | 影响核心功能、较多用户受影响 |
| P2 | 二级故障 / 一般故障 | 🔥🔥🔥 | 小范围影响，主要影响部分功能或少数用户 | 普通应急响应 |
| P3 | 三级故障 / 次要问题 | 🔥🔥 | 用户体验问题或非核心系统异常 | 按计划修复 |
| P4 | 四级问题 / 低优先级缺陷 | 🔥 | 不影响业务，可待下个版本修复 | 无需紧急处理 |
🧭 二、各等级的典型判断标准
P0（特级故障）
🚨 一般被称为 “全网级事故”、“平台级灾难”。
典型特征：
- 平台核心链路全部中断，比如滴滴打车下单全量失败；
- 核心数据库、MQ、注册中心、支付系统瘫痪；
- 无法紧急切换或恢复；
- 涉及用户数 > 50%；
- 严重影响公司品牌形象或合规风险（如泄露隐私、资金损失）。
响应要求：
- 5分钟内启动全线应急；
- 高层介入（CTO、SRE负责人、值班总监）；
- 1小时内必须恢复核心功能；
- 后续形成P0复盘报告、专项整改。
比如滴滴的P0事件：
2023年一次P0级事故：由于配置错误导致订单系统核心链路不可用，全国范围内无法下单，持续约30分钟，影响数千万用户。
P1（一级故障）
典型特征：
- 核心功能部分受限（如支付异常、下单成功率骤降）；
- 单个核心服务宕机或延迟严重；
- 影响较大区域用户（10%~30%）；
- 可通过手动切换、重启、降级方案缓解。
响应要求：
- 值班工程师立即处理；
- 10分钟内汇报并拉群；
- 部门级跟踪；
- 2小时内恢复或降级稳定。
P2（二级故障）
典型特征：
- 次核心模块出错（例如地图展示异常、推送延迟）；
- 个别城市、业务线受影响；
- 不影响主流程；
- 可临时规避。
响应要求：
- 工作时间内跟进；
- 1个工作日内修复；
- 可合并入下次迭代发布。
P3（三级故障）
典型特征：
- 小范围体验类问题；
- 日志报警但无用户反馈；
- 业务可用性不受影响；
- 不影响数据准确性。
响应要求：
- 排期修复；
- 一般通过日常巡检、监控告警发现。
P4（四级问题）
典型特征：
- 优化建议；
- 无实际影响的配置错误；
- 代码规范或潜在风险问题。
响应要求：
- 纳入后续优化计划；
- 不做应急响应。
📊 三、对应的响应与复盘流程（以滴滴/阿里为例）
| 等级 | 响应时效 | 通知范围 | 是否复盘 | 是否需高层通报 |
|---|---|---|---|---|
| P0 | 5分钟内响应，1小时内初步恢复 | 全公司及管理层 | ✅ 必须复盘 | ✅ |
| P1 | 10分钟内响应，2小时内恢复 | 相关业务部门、SRE | ✅ 必须复盘 | ✅ |
| P2 | 30分钟内响应，1天内修复 | 业务线内部 | ✅ 可选复盘 | ❌ |
| P3 | 1天内响应 | 模块负责人 | ❌ | ❌ |
| P4 | 无需应急 | 团队内部 | ❌ | ❌ |
⚙️ 四、配合机制（高可用体系中）
大厂一般都有配套机制支持快速分级响应：
- 监控告警系统：自动识别P0/P1级故障并触发电话/短信通知；
- 应急预案库：针对不同模块都有预案（比如“Redis挂了”、“Kafka延迟高”）；
- 故障演练（Chaos Engineering）：定期注入故障验证容错能力；
- 事后复盘制度（Postmortem）：每次P0/P1故障必须有“五问分析”（根因、检测、处置、预防、学习）。
🧩 五、总结一句话记忆：
| 等级 | 核心描述 | 关键词 |
|---|---|---|
| P0 | 全国挂了 | “救火” |
| P1 | 核心功能出问题 | “紧急修” |
| P2 | 局部问题 | “当天搞定” |
| P3 | 小问题 | “排期修” |
| P4 | 优化建议 | “后续再说” |
