Appearance
生产问题文章模板
这个模板不是讲某一个具体技术点，而是给后续新增“生产问题”文章时直接复用的写法骨架。
如果你以后要持续记录线上事故、性能问题和排查经验，尽量按这套结构写，会比只贴一堆命令和日志更有复用价值。
推荐 frontmatter
yaml
---
title: 生产问题：这里写故障标题
date: 2026-04-19
updated: 2026-04-19
description: 用一句话说明这个问题最典型的现象和排查范围。
tags:
- 线上排障
- MySQL
- 连接池
scene: 线上排障
kind: 案例排障
difficulty: 深入
---推荐正文结构
md
# 生产问题：这里写故障标题
先用一两句话描述这次故障最核心的现场。
## 一、现象
- 用户或业务侧看到什么
- 监控上先暴露出什么
- 有没有明显时间点
## 二、先说结论
- 最终根因是什么
- 这类问题第一时间先看什么
- 最容易踩的误区是什么
## 三、现场信息
- 服务指标
- 线程池、连接池、CPU、内存、磁盘、RT
- 关键日志或关键 SQL
## 四、排查路径
1. 第一步先看什么
2. 第二步怎么缩小范围
3. 第三步如何确认根因
## 五、根因分析
- 真正的问题点
- 为什么会被放大
- 为什么当时没有提前暴露
## 六、止血动作
- 当时临时怎么恢复
- 恢复动作的风险是什么
## 七、长期治理
- 代码层要改什么
- 配置层要改什么
- 监控报警要补什么
- 以后怎么避免再发生
## 八、复盘要点
- 这次最关键的经验是什么
- 下次再遇到同类问题，优先顺序应该怎么走写案例时最值得补的 5 个点
时间线：问题什么时候开始、什么时候放大、什么时候恢复。排查顺序：不要只写结果，要写是怎么一步步缩小范围的。证据：关键监控、关键日志、关键 SQL、关键线程栈，至少保留一类。止血和根治分开：很多线上动作只能先恢复，不代表根因已经解决。长期治理：案例真正的价值在这里，不然下次还是会重来一遍。
最适合收录到生产问题域的内容
- 接口 RT 飙升、线程池打满、Full GC 频繁、CPU 异常
- MySQL 连接数打满、慢 SQL 放大、死锁、主从切换问题
- Redis 热 Key、大 Key、缓存击穿、缓存不一致
- Kafka 积压、重复消费、重试失控
- Nginx 502、磁盘打满、机器负载异常
最后一个建议
如果一篇文章更偏“原理解释”，就优先放到对应技术专题里；如果它是从真实故障现象切入、按排查路径组织的，就更适合落到 生产问题 这个领域里。