7.3 性能评估与问题诊断

7.3 性能评估与问题诊断

本节摘要：有了仿真与实测的数据，还得会读、会判、会修。本节讲用性能指标口径做评估（横向比、纵向看、锁定命中），再走一遍"评估发现不达标→定位归因→改参数→再评估"的诊断闭环，把链路预算账上"哪里最紧、改哪里最值"一次性审清楚。

承接 7.1 的仿真与 7.2 的实测，本节把"怎么用数据拍板"补齐：前两节给数据，本节给判断；数据只会被报，判断才让优化闭环转起来。

数据到手只是开始，会不会"判断"才是真功夫

仿真跑出曲线、外场采回样本之后，最容易出现的一种痛快是"报个漂亮数字就散会"。可前两节辛苦攒下的数据若只停在"报数"，优化闭环就永远转不起来。真正拉开工程师差距的，不是你手上有没有一组数据，而是你会不会拿这组数据做判断：跟谁比、怎么控、判到哪一步该动手改。判断，才是把数据变成效益的最后一公里。

当你拿到一堆性能数据，第一个问号不该是"快不快"，而是"和谁比"。这里有三招要依次走：横向比——和同类配置、同类站点比，看有没有掉队；纵向看——和自己过去比，检测是稳定、缓慢恶化还是忽高忽低；对账定位——把最差的那个指标，一路对回第 2.4 章的链路预算主表，盯住"哪个科目失衡了"。三招走完，模糊的"好像有点慢"就会被钉成一句可操作的"这里余量低了、该改了"。

最难也最见功力的，是最后那一步对账定位。真正的排查，是顺着链路预算把"性能差"逼到某个具体科目——比如"边缘上传差"，就先看接收功率够不够（灵敏度与损耗），再查干扰底噪高不高（干扰管理）,再看调度是否偏心（排队饿死了谁）。一层层剥下去，直到"该改功率、改天线、改干扰协调还是改调度"水落石出。能把一句笼统的抱怨逼上主表的某一行，你才算真正学会了用这整本账去诊断问题。

学习目标

• 用横向对比、纵向变化的评估方法判断一次优化是否有效。
• 列出一个不足问题定位到"链路预算某一行"的排查链条。
• 走通"评估—诊断—改参—再评估"的闭环并指出迭代终止条件。

数字会报，判断才是功夫

拿到一堆性能数据，第一个问题不是"快不快"，而是"和谁比、怎么比"。

• 横向比：和同类配置/同类站点比，看有没有掉队。
• 纵向看：和自己过去比，连续几天是稳定还是忽高忽低。
• 对账定位：把最差的指标对回第 2.4 章链路预算主表，盯住"哪个科目失衡"。

三招走完，就知道该往哪修：是边缘覆盖（余量低）、还是干扰（底噪高）、还是调度（队列堵）。

诊断要走到"某一行的账"

真正的排查功夫，是顺着链路预算把"性能差"逼到某个具体科目。比如边缘上传差，通常的排查链是：先看接收功率够不够（灵敏度/损耗），再看干扰底噪高不高（干扰管理），再看是不是调度偏心（排队饿死谁是角度）。一层层剥到"该改功率、改天线、改干扰协调还是改调度"，这才能进入对症下药。

用一张闭环把"评估与诊断"串起来

评估、诊断、改参、再评估，是一个该反复转的圈，画出来最清楚它是怎么自我纠偏的。

闭环的核心纪律是"一次只改一笔、看得到因果"：把功率、天线、调度拆开各自验证，改一次记一次效果，才能把"哪个参数有效"审清楚。一把乱调好几个，账就成了一笔糊涂账，永远归不到因。

一次闭环的小演练

用一段脚本模拟"调参→评估→再调"的收敛节奏：

def performance(param):
    # 模拟某个参数下某指标(越高越好)
    return max(0, 92 - (param - 4)**2)

best, best_score = None, -1
for p in [2, 3, 4, 4.5, 5, 5.5]:
    s = performance(p)
    if s > best_score:
        best, best_score = p, s
        print(f"改到参数 {p} 分 -> 评估 {s:.1f} 分 (更优, 采纳)")
    else:
        print(f"改到参数 {p} 分 -> 评估 {s:.1f} 分 (回落, 退回{best})")
print(f"收敛: 参数 {best} 分是最优, 达标即止")
​

输出一路"采纳更优、退回回落"，最后停在最优参数——这正是闭环里"评估驱动向前、诊断指导取舍"的微缩模型。

把评估与诊断放回全书那张账的收尾处，你会看到它其实是给你前面每一章做的一次"总了结"：第 2.4 章铺开主表，第 3 到 6 章往里填增益、减损耗、做系统级取舍——但一块设计到底靠不靠谱，最终都要本节这套"评估—对账定位—改参—再评估"的闭环来拍板。它最可贵的，是把工程师从"猜"里解放出来：与其靠感觉说"好像不太对"，不如顺着指标一路对回主表的那一行，指认"功率余量偏低了、干扰底噪抬高了、调度把边缘用户饿着了"，再一次性只改一笔、看一次因果、复评一次。一张能自我纠偏的设计，才是能真正落地的设计；而这套闭环，正是让这本链路预算账从"写得好"走到"验得实"的最后一公里。

最后给你一张"评估前的自检清单"，避免一上来就报数：第一问口径——这组数据是均值、中位数还是峰值，跟谁比要同口径；第二问对照组——有没有"优化前后、同条件"的基线可对，没有基线就是自嗨；第三问因果——改的是不是一个变量，能不能把效果归到它的头上；第四问收敛——这轮改完是变好了还是只是碰运气，要不要再复验一轮。四问走完，你才能说"这组数据可信"。把这张清单养成习惯，你在第 7 章之外的所有章节里做任何性能判断时，都会少踩许多"被漂亮数字带偏"的坑。

诊断还有一个收尾功夫值得练：把"结论"与"证据"分开写。排查到最后，哪怕你已经笃定是某一行失衡，也建议把"是什么现象、测得哪些数、怎么归到这一行、还要再验什么"分开列清楚。这样既方便别人复核，也防住自己"先下结论再找理由"的本能。能把一次排查写成一页"证据链完整、可以对着复验"的结论，你的问题诊断就从"凭感觉"正式进阶成了"可追溯的专业环节"。

易踩的坑

常见坑：把"一次漂亮评估"当"优化成功"。没有"改前改后对照、同口径可比"的评估都是自娱；没有"一次只动一笔"的迭代都是瞎撞。闭环要的是可追溯的因果，不是热闹的数字。

本节要点回顾

• 评估三招：横向比同类、纵向看走势、对账定位到主表某行。
• 诊断到行：把"差"逼到功率/干扰/调度的某一笔，才谈对症。
• 闭环自律：评估—诊断—改参—再评估反复转，一次只动一笔。
• 终止条件：指标达标或改善趋缓，即收敛定夺，别无限折腾。