5.3 性能优化与故障排查

5.3 性能优化与故障排查

本节摘要：排障的一半是方法一半是病历。方法上，用「先分层、再下钻」的决策树代替乱点乱试：界面、接口、数据、环境四层各有症状与检查项。病历上，给出高频病症的处方：首页变慢、列表卡顿、工作流积压、偶发五类错误。读完你能把 4.4 的材料学兑换成手上功夫。

5.2 的仪表报了异常，接下来怎么查？这一节给一套不依赖灵感的排障框架。先立规矩：每一次排查都从复现和定位开始，从验证结束——跳过定位直接开药，治好的是运气，治坏的是系统。

一、分层决策树：先定位、再下钻

图 5-2 排障决策树：从症状到病根

二、病历一：首页越用越慢

某团队上线三个月后抱怨「打开首页要等好几秒」。按决策树先定位：个别页面卡、刷新时区块逐个出现——界面层嫌疑。进编辑模式数了数：首页堆了八块区块，其中一块图表区块在整表聚合，一块看板没有默认筛选。处方：砍到三块区块，图表聚合限定时间范围，看板绑定数据范围。十分钟的手术，首页回到秒开。

这例的价值在「防复发」：慢不是一夜之间发生的，是每次有人加区块时涨一点的。把「首页区块上限」写进团队的装配纪律（2.3 的三条纪律再补一条），比每次事后开刀便宜。

三、病历二：列表导出把库拖慢

第二个病历更隐蔽：一张十几万行的跟进记录表，有人点了导出全量，随后半小时全站接口都慢。定位过程：代理日志显示慢请求集中在同一接口、同一时间段；查该时段的资源水位，数据库读负载顶满——数据层病根，导出的全量查询当了放大器。处方三联：导出强制带时间范围；给常用筛选字段补索引（包括行级权限条件引用的字段——它藏在每个查询里，最容易被漏掉）；把批量导出挪到非高峰时段并限制单次行数。

# 数据库侧的两条诊断手法（以 PG 为例，试验环境先练熟）
# 1. 看当前耗时靠前的查询，确认慢在哪个语句
SELECT pid, now() - query_start AS 耗时, left(query, 80) AS 语句
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY 耗时 DESC
LIMIT 5;

# 2. 看某表有哪些索引，确认筛选字段是否在列
SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'follow_ups';
​

四、病历三：工作流执行量骤降

第三本病历是巡检清单抓到的：某天流程执行笔数掉到基线的一成，没有任何报错。按决策树过一遍：环境层正常、接口层无异常、数据层也正常——最后在流程引擎的运行状态里发现一条核心流程被停用了：头天有人做插件调整，顺手停了流程，改完忘了启用。这例的教训写进了 5.2 的巡检：执行笔数骤降同样是告警，没有错误日志不代表没有事故——「安静地坏着」是低代码平台特有的故障形态，因为太多环节是配置开关。

⚠️ 常见坑：在生产环境直接试药。排障动作里，「重启容器」「改环境变量」「临时关插件」都属于变更，生产上的变更要么可秒回退、要么先去试验环境演练。没有回退预案的变更，本质是在赌。

💡 关键直觉：好的排障手册不是命令大全，是病历本。每次事故记下症状、定位路径、根因、处方、复发条件，半年后这本病历就是团队最值钱的运维资产。

病历四：附件偶尔打不开

第四本病历换个味道——不是慢，是「偶尔」。有用户反馈附件下载时好时坏，刷新几次又能打开。定位路径：所有用户偶发、跨页面出现，先怀疑环境层与存储层；查磁盘水位正常、容器无重启；再看存储目录所在盘的空间与权限，最终发现是备份任务的 rsync 在业务高峰抢占磁盘 IO，附件读取被拖慢超时。处方：备份窗口挪到凌晨，rsync 限速。「偶发」类病症的共同点是难复现，病历的价值在于把「偶尔」归因到「定时撞车」这类规律上——偶发不等于无规律，只是规律藏在时间表里。

偶发病症的排查模板：
  1. 收集样本：何时、谁、哪个动作，至少攒五例
  2. 找时间规律：是否集中在固定时段（备份、批处理、高峰）
  3. 找人群规律：是否集中在同一网络、同一角色
  4. 对照定时任务表：时间点重合即头号嫌疑
  5. 验证：错峰观察一周，消失即结案
​

把排障记录编进周报

病历要发挥复利，得有固定的回读节奏。最轻的做法是给运维周报加一个固定栏目——本周排障三行： symptom（症状）、root cause（根因）、action（处置与防复发）。三行写不了长文，但坚持一个季度，团队对「哪类问题反复出现」就有了量化体感，防复发的工程投入（加索引、改窗口、补文档）就有了排期依据。周报栏目的另一个隐性收益是新人的教材：入职第一个月把三个月的周报排障栏读一遍，胜过半个月的口口相传。

周报排障栏样例：
  周二  导出全量拖慢接口    根因：无时间范围的全表查询
        处置：导出强制带范围；补 follow_ups 时间索引
  周四  请假流程执行量为零  根因：流程被误停用
        处置：执行量进巡检；停用流程须双人确认
​

性能预算：把「快」写成数字

性能优化的止境不好把握，容易陷入没完没了的微调。给关键路径定性能预算，把「快」变成可验收的数字：登录后首页可交互不超过三秒、常用列表查询不超过两秒、保存操作反馈不超过一秒、附件下载启动不超过两秒。预算定在蓝图阶段，装配时对着数字选型——表格列数、区块数量、默认筛选，都是预算的执行手段。上线后巡检按预算抽查，超标即进排障队列。

性能预算卡（蓝图阶段定，验收时对表）：
  首页可交互：____ 秒        常用列表：____ 秒
  保存反馈：____ 秒          附件下载启动：____ 秒
  抽查方式：非缓存状态、真实数据量、常用网络环境
​

预算思维的真正好处是把性能从「上线后用户投诉驱动的救火」变成「蓝图里就写好的验收项」。数字不必拍得激进，贴着用户感知定即可——多数中后台应用，用户对两三秒的等待并无怨言，对时快时慢的不稳定反而零容忍。

装配要点回顾

• 决策树纪律：症状先归四层（界面、接口、数据、环境），再层内下钻，禁止跳步开药；
• 首页慢开界面层刀，减区块、限聚合、绑范围；
• 导出是大查询放大器，强制时间范围、补索引（含权限条件字段）、错峰限行；
• 安静地坏着：流程执行量骤降进巡检，配置开关类故障没有报错日志；
• 变更三问：可回退吗、演练过吗、有必要现在做吗；
• 收尾复盘：根因归属、巡检加项、病历归档，三问收尾；
• 下一步：5.4 把运维手艺的巅峰动作练熟——不停车换件。