BAM(Bug Analysis Method) Bug分析方法 之 TPAF

行为分析小组 (Behavioral Analysis Unit,BAU)是美国联邦调查局国家暴力犯罪分析中心(NCAVC)下设的一个部门。该部门旨在运用行为科学分析来协助犯罪调查。国家暴力犯罪分析中心和行为分析小组的主要任务是提供行为基础调查和/或通过将案例经验、调查和训练应用到时效性的罪案中以提供作战保障,特别是涉及到有暴力倾向的案件。

之所以提到BAU, 我认为Bug分析和行为分析有类似的方法。

TPQF是指我总结的Bug分析的方法,分别是:Time(时间), Probability(概率), Area(面积), Feature(特征)

1. BAM 目标

Bug分析的最终目标并不仅仅是解决Bug,而是在解决Bug的基础上记录问题日志,找到问题的触发器,建立对应的问题处理模型。

  • 记录: 记录一切可以记录的内容,包括且不限于截图,日志,视频,连天记录。记录这些内容的,可以让你不再每次都需要去重现问题,记录日志。
  • 触发器: 找到Bug的触发器往往最重要的一个环
  • 模型: 建立Bug模型,为以后的问题提供更快的解决思路

2. Time(时间)

问题的时间点有三个,是务必确定要记录的。

  1. Bug发生的时间点: 很多日志依赖于这个时间点去查询
  2. 往前正常的时间点: 例如今天出现bug, 那昨天正常吗? 今天12点出现的Bug, 那今天10点正常吗? 确定这两个点,那么这两点之间发生的事情,很可能就是引发Bug的原因。例如昨天正常的服务,今天出现了Bug,如果昨天和今天之间,某些服务更新了,那么很可能是因为某个服务更新而引起的Bug。

时间除了要确定问题出现的区间之外,最重要的时间的紧迫性。线上生产环境突发的严重问题,是在解决不了的话,要尽快重启服务,以降低客户的损失为首要目的,而不是把时间花在分析Bug上。

3. Probability(概率)

问题的概率是针对于单个客户端而言的。概率是指单个客户端出现问题的概率。有以下两个主要可能性。

  1. 偶然事件 偶然事件是一种小概率事件,很难找到Bug的触发器,也无法重现,只能通过查询相关日志获取才有可能发现一点蛛丝马迹
  2. 必现事件 必然事件是100%出现的事件,找到概率的可能性比较大

4. Area(面积)

Bug影响的面积有三种模型

  • 单点: 现在服务的架构一般都是CS结构,单个客户端出现问题,往往是客户端的问题
  • 部分: 部分客户端的问题,如果该部分是同一区域的,那么很可能是该区域网络的问题。如果该区域使用同一个服务端,那么可能是单个服务节点出现问题
  • 全部: 全部都出现问题,基本上都是服务端出现了问题

5. Feature(特征)

  • 线性特征: 随时间缓慢增长。可能是内存泄露
  • 指数特征: 还没想到
  • 对数特征: 快速打到一定程度后,不再增长。可能是连接池溢出
  • 时间特征: 某个时间端内快速增长,过了该时刻快速下降。例如每天8到9点是用户激增的时间范围

6. 更远的未来

目前我们的编程都是这样的:定义规律,给出输入,拿到输出

1
2
3
4
5
6
7
8
9
// 定义规律
f
// 喂入输入
x
// 计算出输出
y

// 给出输入
y = f(x)

大数据与人工智能时代:给出输入和输出,训练出规律

1
2
3
4
5
// 喂入 输入x 或 输出 y
x or y

// 训练出
f

或许有一天,直接给出Bug相关信息,计算机会告诉我们,Bug在哪里,如何修复。