故障处理主流程
故障处理按固定流程推进：确认影响面与级别、快速止血（切换、限流、降级）、定位根因、修复并验证、复盘改进，全程记录时间线与关键操作。止血与定位可以并行：先把业务稳住，再深挖原因，两者并不冲突。
基本信息
| 主流程 | 确认、止血、定位、修复、复盘 |
|---|---|
| 贯穿全程 | 沟通与操作记录 |
| 产出 | 复盘项与改进行动项 |
| 原则 | 先恢复可用性，再谈优化 |
典型使用场景
- 实例不可用或大量超时，需要快速判断能否切换
- 内存打满触发大量淘汰，需要先扩容或限流
- 主从复制中断，读扩展失效
- 集群状态异常，部分槽位不可用
- 业务侧写入异常放量，需要限流保护实例
现场取证命令
现场取证命令
redis-cli INFO server | grep -E 'uptime_in_seconds|redis_version' # 确认是否刚重启
redis-cli INFO replication # 角色与主从链路，判断能否切换
redis-cli -c CLUSTER INFO # 集群状态，确认是否属于集群级故障
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'
redis-cli SLOWLOG GET 10 # 最近的慢命令，定位引发阻塞的调用
redis-cli CLIENT LIST | head -20 # 连接来源与状态，辅助判断异常来源阶段动作与要点
| 阶段 | 动作 | 要点 |
|---|---|---|
| 确认 | 判定影响面与级别 | 用业务视角描述，不堆技术名词 |
| 止血 | 切换、限流、降级 | 目标是恢复可用，不追求根因清晰 |
| 定位 | 指标与日志交叉验证 | 保留现场，避免重启掩盖证据 |
| 修复 | 变更加验证 | 每一步都留可回退手段 |
| 复盘 | 时间线与改进项 | 输出可执行任务，不写空泛结论 |
重启实例前尽量先采集现场证据：慢日志、客户端列表、内存与复制状态。重启会清空大量诊断信息，事后无法补采。
时间线与操作记录要在处理过程中同步写。事后回忆补记必然失真，复盘容易退化成记忆争论。
止血手段要提前预案：切换的判定标准、限流的阈值、降级的开关，临时现查会显著拉长故障时长。