Appearance
生产问题
这里优先按“故障现象 -> 止血动作 -> 根因收敛 -> 长期治理”来组织，而不是先背一堆命令。
如果线上真的出问题，建议先按症状落点：
应用运行时异常适合先处理 CPU 飙升、Full GC、线程池打满、接口 RT 抖动这类应用层问题。数据与基础设施故障适合先处理数据库连接、网关 502、磁盘打满、缓存热点、消息积压和检索变慢。事故复盘模板适合后续把每一次止血、定位、回滚和治理动作沉淀成统一格式，长期积累会更整齐。
更稳的排障顺序通常是：
- 先判断影响范围，分清是不是全站故障、单链路故障还是单机异常。
- 先止血，优先保住核心交易和核心接口。
- 再区分问题是在应用层、数据层、网关层还是基础设施层。
- 最后把根因和治理动作沉淀下来，避免只解决这一次。
如果你把这里当成长期事故库来用，更推荐按下面这三组方式积累：
先看止血类案例适合先收录 CPU 飙升、线程池打满、接口 RT 抖动、数据库连接打满这类需要快速止血的问题。再补根因类案例适合沉淀死锁、热点、消息积压、查询变慢这类需要复盘链路和结构性原因的问题。统一复盘格式每篇尽量固定为现象、影响范围、止血动作、根因、修复、长期治理，后面会越来越清楚。
现在这套事故库更适合优先沉淀 4 类内容：
- 应用运行时异常：CPU、GC、线程池、接口超时。
- 数据链路故障：MySQL 连接、死锁、Redis 热 Key、MQ 积压。
- 网关与基础设施问题：Nginx 502、磁盘打满、Kubernetes 运行异常。
- 复盘型文章：一次事故里真实的发现顺序、误判点和长期治理动作。