1. 问题排查总纲与性能优化框架

问题排查与性能优化不是临阵磨枪的救火动作，而是一套可重复、可度量、可改进的系统工程。本章将建立整门课程的骨架：从故障树基本结构出发，串联六步排查流程，再铺开性能指标体系，最终落到优化目标分解。后续每一章都在这个框架上填充具体技术栈的细节。

1.1 故障树基本结构

故障树（Fault Tree）是一种自上而下的逻辑树：顶层是失效现象，中间层是可能的直接原因，底层是根本原因。每个节点用“与门/或门”连接，支持定量概率分析。在实际排查中，我们更常用简化故障树作为思考模板：

• 顶层事件：用户或监控观察到的异常现象（如“API响应超时”）。
• 中间事件：导致顶层事件的候选原因分组（如“网络延迟”、“服务端排队”、“数据库慢查询”）。
• 底事件：可验证的具体根因（如“DNS解析超时”、“线程池耗尽”、“索引缺失”）。

1.2 六步排查流程

所有排查活动都应遵循统一的闭环流程。下表列出每一步的输入、输出和关键动作：

1.3 性能指标体系

性能优化必须以可量化指标为靶心。体系分为三类：

• 前端/用户体验指标：首屏时间（FCP）、交互时间（TTI）、页面加载时间（LCP）。
• 后端服务指标：响应时间（P50/P95/P99）、吞吐量（RPS/QPS）、错误率。
• 基础设施指标：CPU 使用率、内存占用、磁盘 I/O 延迟、网络带宽占用。

1.4 优化目标分解

将模糊的“系统变快”分解为可执行的子目标：

1. 降低延迟：缓存热点数据、优化 SQL 查询、减少序列化开销。
2. 提高吞吐：水平扩展、连接池调优、异步化处理。
3. 减少资源消耗：消除内存泄漏、压缩大对象、合理分配线程数。

每个子目标必须绑定一个可测量的指标变化量，例如“将 P99 延迟从 800ms 降至 200ms”。

1.5 总体框架图

下图将前四节的核心元素整合为一张行动指南：

1.6 排查判断规则示例

在“原因定位”阶段，可使用预定义的判断规则快速过滤低概率分支。以下是一个基于故障树的 YAML 规则片段：

rules:
  - name: "API 响应超时排查"
    symptom: "P95 延迟 > 500ms 且错误率上升"
    branches:
      - condition: "CPU 使用率 > 90%"
        likely: true
        action: "检查 CPU 热点进程，分析慢函数"
      - condition: "数据库连接池耗尽"
        likely: false
        action: "检查连接池活跃数，执行 SHOW PROCESSLIST"
      - condition: "外部依赖（第三方 API）超时"
        likely: true
        action: "查看上游调用链，设置熔断降级"
    fallback: "对本次请求录制全链路 Trace，进行详细分析"