学徒浅析Android——根本原因分析

什么是直接原因和根本原因。

一个问题，可以停留在表面，也可以深究到根源。我们常说的直接原因其实是表面原因，而根本原因是指出导致出现该差异、缺陷或风险的原因，因此根本原因可能不在业务中。针对系统级问题，最好的解决方式就是从根源解决。而针对根源进行的根本原因分析的一个特点是当出现问题时，不仅要解决业务问题，还要解决人员问题和组织问题。这里本文只从业务问题层面来分享下如何分析根本原因。

根本原因分析步骤：

1、定义问题

为了推进根本原因分析，首先需要澄清要找出原因的问题，也就是重新定义问题。确定应用正在发生哪些异常现象，相关参数是如何与当前现象产生关联，在此基础才能展开根本原因分析。

我们平时接收到的问题可以分为两类：

1、崩溃异常型问题

问题本身直接指向代码执行异常的位置，多见于白盒测试，系统异常日志。

2、现象描述型问题

问题本身看不出问题所致，只是描述了和期望表现不一致的现象。多见于用户，监控平台，测试用例等反馈的使用报告。

针对第一种类型，我们可以很直白的定位到哪一行或那个类出现了异常。这样问题就变成了了为什么这个代码段或参数异常。

针对第二种类型，如果我们不是该功能模块的开发者，很难第一时间判断出哪个标记值或参数出现异常。此时就需要查看具体的方法段、关键日志节点或咨询第一开发者，在此基础上将现象描述转化为某个代码段或参数异常。这样问题类型就变成了上述的第一种问题类型。

2、收集信息

有了第一步的基础，围绕问题代码段展开数据信息的收集。包含问题发生过程中时序图所处阶段、问题代码段原有的业务逻辑，问题发生时间段内设备的全量日志（堆栈信息，进程信息等）等。信息的收集是围绕问题点层次递进的，是一个持续进行的过程，每次收集信息也可能会推翻原有的结论，正是这个持续的过程，保障了第三步和第四步的进行。

收集的信息应围绕问题发生点按时间顺序进行组织，并以易于使用的形式进行展示。比如我们常用的notepad++检索模式，wireshark等各种特定的日志解析工具。

3、确定可能的问题发生因素

组织信息后，我们想知道为什么出现问题，首先要从发生频率开始分类，应用层面的发生频率可以分为如下几点：

问题是否必现？如果是偶现，多是调用时机（生命周期、回调时机、线程执行顺序等）

如果是必现，且不区分设备，多是数据或业务处理（数据有无、参数内容等）

如果是特定设备必现或特定环境必现，多是运行环境相关（ROM型号、当前网络状态、内存状态等）。

这一步发现的因素（基于分类结果查找相关信息），可能需要重新执行第二步加以佐证，也可能会直接得出根本原因。也可能直接推翻先前自己得出的结论。但是不要担心新发现的因素和结论的不一致性，这正是找到根本原因的必经之路。

4、确定问题的根本原因

完成分析和现场调查后，我们将根据到目前为止的信息和数据找出问题的根本原因。验证结论的方式就是重构问题发生场景。对于难以复现的问题的场景，可以采用图表的方式来展示，不建议使用文字叙述方式，这个主要在于大段文字不便于让他人快速理解。

帮助此过程的工具是因果关系图或者流程图，当前使用EdrawMax可以很容易创建出一个因果关系图或流程图，剩下的就是将自己的过程结果填入就行，当然单纯的脑图也行。总之找到一个适合自己风格的图标展示方式。

这里需要强调下根本原因不一定是一个。 由于可能涉及多个根本原因，因此请仔细创建和检查自己的图标是否正确的表示了问题场景。

5、采取措施防止再次发生

问题发生后，需要重视的是采取措施防止同样的问题再次发生。一旦我们制定了防止此类事件再次发生的措施，我们首先要考虑如下四点：

1）措施是否容易实施。

2）是否是最优措施。

3）是否是改动最小的措施。

4）如果实施，预期效果是什么。

理想的措施方案是不产生衍生问题，只影响问题发生所处的业务。例如同事曾经修改过一个弹窗展示的问题单，一个悬浮弹窗在横竖屏切换过程中出现了文字遮挡的现象，常见情况下会去在onSaveInstanceState/ onRestoreInstanceState中进行控件的重绘或者分别配置两套横竖屏布局文件。但如果涉及到包大小或者系统弹窗场景呢，针对兼容性设备多样的情况下，增加布局文件意味着增加了包大小并要重新调试，修改生命周期有点大材小用。所以该问题经过短暂讨论，既然文字展示不全，只要TextView的高度自适应或者支持特定高度内滚动即可，这样既可以不变更原业务逻辑，也不会增加包大小。

6、分析结果归档：

记录根本原因分析中发现的问题的原因和解决方案非常重要。 通过记录，项目组内部可以积累业务FAQ。 对于个人可以积累专业知识，减少新项目的工作量并降低成本。

推荐一种分析模板：N-Whys

丰田最先推出的这个模板，叫5-whys，富士通采用的是7-whys。但实际上N不是一个固定数值，它取决于所面对问题的可探究深度。每问一次为什么，就是一轮原因分析，直到分析结果达到一个边界，比如达到系统API的某个具体方法，框架的某个服务状态，某个接口的返回节点等。边界的设定避免无效深究造成的成本浪费和目标偏离。也可以避免被提问者抄起键盘砸向你。

例如，在某个定位不准的情况下使用分析模板：

“为什么天气定位不准？”

因为提供的经纬度有偏差

“为什么获取到的经纬度有偏差？”

因为使用了缓存位置

“为什么使用了缓存位置？”

因为系统接口上报了缓存位置

“为什么系统接口上报了缓存位置？”

因为此时网络扫描失败，没有生成新的位置。

“为什么网络扫描失败？”

因为设备处于室内并在弱网环境下。

所以定位不准的根本原因是设备所处环境问题。它的直接原因是用了缓存位置。很显然，这个问题并不需要立刻着手优化，和用户合理沟通即可。

参考和常用工具：

1、Log.getStackString(new Throwable())  打印堆栈信息，比较堆栈变化。

2、使用Layoutviewer，使用adb shell dumpsys activity XXXX

3、日常搜集关键日志。比如自己建立一个关键日志汇总表，关键接口人表等。

4、使用特定的辅助工具。profile、notepad++、BeyondCompare、AOSPXRef 等