知识卡片

已获取信息的定量与归类分析,价值远超笼统描述

普通读书笔记卡

内容

排查问题时最容易获取的一类线索(”想知道并且已经拿到手”的信息,如服务表现、系统状态、硬件指标)本身价值有限,真正决定这类信息能不能发挥作用的,是有没有对它做进一步的定量和归类分析。一句笼统的描述”不是全部请求都出错”或者”刚才数据库和服务都出问题了”,和一句经过定量归类的描述”线上请求有1/3出错,都是电信用户的请求”或者”Web服务18:12:11开始报异常,数据库18:12:30开始出现慢请求”,两者对排查的实际帮助天差地别——前者几乎没有指向性,后者已经隐含了具体的比例、共同特征和精确的时间先后关系,这些信息本身就是排查方向上极有价值的线索。一个真实案例很好地说明了这一点:线上未读数偶发清不掉的问题,起初没有发现明显异常,重启前端服务也没有效果;转折点是团队统计了1分钟内出现问题的请求占正常请求的比例,发现大约是1/8,而这个服务依赖的另一个服务正好有8个实例——这个”18”的比例和”8个实例”的对应关系不是巧合,进一步统计后发现出问题的请求确实都调用到了同一个实例,下掉这个实例后服务立刻恢复。这个案例提示了一条排查方法论:面对”已经拿到手但看起来杂乱”的信息,不要止步于描述现象本身,而要主动去做定量统计(占比是多少)和归类分析(这些出问题的样本有什么共同特征),这类分析经常能揭示出仅凭直觉描述完全看不出来的规律(比如”18”这个比例恰好对应到”8个实例中的1个”),从而把排查方向从”漫无目的地翻查日志”收窄到”精确定位到某个具体的故障点”。

参考来源

- 位置:《高可用架构(第1卷)》第5章《运维保障》"5.4 微博在大规模、高负载系统问题排查方法"节,"5.4.2 排查方法及线索"(源文件:_epub-src/OEBPS/Text/Chapter5_4_3.xhtml) - 结论依据:原文举例对比"不是全部请求都出错"与"线上请求有1/3出错,都是电信用户的请求"的效果差异,并详述未读数清不掉的案例("统计了1分钟内出现问题的请求占正常请求的比例,大约是1/8,而这个服务依赖的另一个服务正好是8个实例……出问题的请求,果然都调用到了同一个实例"),直接支撑本卡片结论。 - 原始内容:如果换成"线上请求有1/3出错,都是电信用户的请求"或者"Web服务18:12:11开始报异常,数据库18:12:30开始出现慢请求",效果是不一样的……统计了1分钟内出现问题的请求占正常请求的比例,大约是1/8,而这个服务依赖的另一个服务正好是8个实例,于是我们进一步统计出问题的请求,果然都调用到了同一个实例。