有一位农技专家发现自己辖区内高压线下的麦田产量比没有高压线的地区要明显高一些，于是十分兴奋地申报了科研项目，开展了一个关于高压辐射对小麦产量影响的研究课题。他研究了很久，一直没有突破。有一天从一个老农那里听到一句话：“高压线上总是站满了各种鸟”，他突然想到是不是鸟粪提高了土地的肥力，从而导致了这种变化呢？很快他就通过分析搞清楚了这件事，这个课题也就变成了一个笑话。
事实上，我们很多时候也像是这位研究高压电辐射的农技专家，从一个十分片面的“事实”作为起点去看一件事，忽略了一些看似和这件事无关的影响要素，从而经常陷入误区。更可怕的事情是很多时候我们还能把这些片面的现象解释得很圆满，从而误导了更多的人。
我在给客户做服务的时候特别怕遇到很较真的人，总觉得他们经常胡搅蛮缠，对我给的报告刨根问底。不过有时候这种刨根问底真的会发现我的分析报告中的问题。有一次我帮一个用户分析了一个ORA-600[kcbcxx_1]导致的故障，把问题定位到某个常见的BUG上了。客户的主管都已经认可了这份报告，不过有个小组长就非要死缠烂打地对报告中的每个细节进行确认。他问我看BUG报告这个故障很容易触发，为什么以前我们系统没有遇到这样的BUG，按你的报告所述，这种场景我们经常会遇到的。
当时这件事虽然敷衍过去了，不过我回去后还是又仔细分析了一下这个BUG的诱因，仔细分析后，我也对自己的报告也不那么自信了。于是我把收集上来的TFA上传到MOS，开了一个SR。通过CUS的分析，最终定位故障是一个和我报告中的BUG八竿子打不着的原因导致的。
从上面的案例也可以看出，很多问题的原因可能和看似相关的因素无关。当专家的经验陷入误区的时候，我们很可能在往一个错误的方向前进，但是我们很可能并不知道这种情况的发生。我们在做自动化诊断工具的时候也经常遇到这样的问题，当专家模型没有覆盖到某个场景的时候，分析看似合理，但是很可能并不正确。
“泛化分析”这种智能化分析的手段往往是解决专家误区的有效方案，通过泛化分析，可以自动关联到一些原本专家系统中并未关联到的路径，从而弥补专家能力的不足。三年前我给一个用户远程分析一个系统性能问题，执行计划、表数据、索引等都没有异常，但是执行时间从5分钟加大到了30分钟。后来在智能运维工具的报告中看到了一个疑点，那就是网络丢包率与前几天相比出现了明显异常。后来换了根网线就搞定了这个故障。
不过这种泛化分析很可能无法十分明确地指出问题所在，其分析结果只能大致指出一个方向，因此可能只有专家才能看懂分析结果。因此大多数智能运维工具要想让普通运维人员就能很好地使用，还有不小的距离，这也是我们未来的重要工作任务。
