章节摘要:性能故障和刑事案件一样,第一反应决定成败——慌乱重启等于毁尸灭迹。本章建立全书的办案框架:一次线上延迟事故的标准取证流程、性能指标体系(延迟/吞吐/利用率/饱和度)如何构成证据链,以及观测工具本身带来的"观察者效应"如何污染现场。读完本章,你面对故障时将有一套可复用的动作序列,而不是靠直觉乱撞。
现场会蒸发:连接池耗尽的那一刻、内存暴涨的那三分钟,过去了就再也看不见。取证的第一原则是抢时间留档。
从一个真实的 P99 翻倍事故走完整流程,看每一步该跑什么命令、留什么证据。
五类核心指标如何互相印证,为什么单独看 CPU 使用率会误判。
观测工具本身是嫌疑人之一:strace 让程序慢 10 倍、加日志让竞态消失,怎么权衡。
1.1 给出流程骨架(做什么、什么顺序) │ ▼ 1.2 补充证据标准(什么是合格的证据、指标怎么组合) │ ▼ 1.3 提出警示(证据采集本身可能污染现场)
三节从"流程"到"标准"再到"边界",构成方法论的完整闭环。后续章节的所有工具,都是这套流程里某个环节的装备。
取证式性能分析区别于"重启试试"的关键,在于动作有先后、结论有证据。本章四节构成一条完整方法论:立案一节给出从事故告警到根因确认的标准动作序列,核心是"会消失的证据先抢救";证据链一节定义什么样的指标能构成可信证据——口径对齐、有基线、能被统计检验支持;观察者效应一节处理测量本身的干扰,给出采样率与开销的权衡实验。以下命令是本章的日常速查:
# 现场抢救(会消失的证据) cat /proc/$PID/stack; ss -tanp | grep $PID; pidstat -p $PID -w 1 5 # 资源粗判(时间序列而非瞬时值) vmstat 1 10; iostat -x 1 10
第一次接触性能排查的读者按节序读,先建立"保全现场→采集证据→假设→定罪"的流程直觉;有三年以上后端经验、被事故复盘折磨过的读者,可直接从证据链与观察者效应两节入手,重点看统计检验与开销量化实验——这两块是把排查从手艺变成工程的部分。团队落地时建议把本章的取证脚本与结案报告模板直接抄进值班手册,方法论只有变成可执行的命令和表单才能存活。
取证式流程并非所有场景都需要:纯粹的容量不足(流量翻倍、资源线性吃满)走扩容路径更快,不需要完整立案;但任何"指标异常而原因不明"的案件,都值得按流程走一遍,哪怕最终结论是"测量误差"。团队经验里最贵的教训往往不是没破案,而是没立案——凭直觉重启、改配置后指标碰巧回落,根因被永久掩埋,同样形态的事故每隔几个月回来一次。把立案门槛写清楚(影响窗口、放大倍数、持续时长三要素),既防小题大做,也防大题小做。
与后续章节的关系上,本章是全书的总纲:第二章讲采集机制决定证据的物理形态,第三章给单机工具箱,第四章按资源给出定罪命令,第五章处理正确性案件,第六章把视野扩展到容器与跨服务,第七章沉淀为工程规范。任何一章遇到"证据不足"的困境,回本章补取证纪律。