解决技术问题思路

一、前言

作为技术人员，每天都在于bug打交道，不在解bug，就是在写bug，总有解不完的问题。对于新手而言，由于缺乏经验，面对问题常常没有思路，而对于老手而言，有经验，解决问题快很多。这里的经验又过于抽象，经验是什么？即依靠过往遇到过该问题，它只能解决“重复的坑”问题，面对重复问题，根据之前经验，提供一些分析方向。但是仅凭经验会有如下问题：

1、面对新问题无从下手（此时不受控，技术老手也难免惊慌）

2、依赖经验，容易在错误的道路上越走越远。同样的表现可能是不同的问题，依赖经验可能把你带偏。

所以整理一套分析解决问题的范式就很重要，提高分析问题的效率，以及降低面对新问题的恐慌，做到心中有数，胸有成竹。

二、问题解决思路

1、 问题生命周期

一个问题的生命周期，其实也对应我们解决问题的过程，作为技术人员，我们往往更专注问题分析和解决过程。其实现象收集和问题复盘同样重要。下面从技术人员更常规的问题分析和解决方案入手，然后到工程实践中如何收集现场信息，以及研发不同阶段问题有不同的工程化处理方案，比如用户市场反馈问题就需要考虑先快速恢复用户使用，然后再进行调试信息收集。

问题产生 - 现象收集 - 影响评估 - 问题分析 - 问题解决 - 问题复盘

2、几种问题解决方向

技术人员一般说的解决问题，是指找到根因解决问题，不过经常遇到的问题解决方式，有如下3个level：

• 短期解决方案（快速恢复）： 用户现场异常，需要快速恢复用户使用，比如重启、关掉某个功能等。

• 长期解决方案：

  1） 正面解决：根因排查，彻底解决问题。

​ 2）规避手段（WALK AROUND）：根据问题现象，提供规避手段，降低问题出现时影响或者减少问题出现概率。

3、常规问题分析步骤

我们拿到一个技术问题，需要通过现象，进行调试，找到根因并解决。这里和在学校做实验的步骤是一样的，分析问题找到根因就是一个做实验的过程。

问题描述(现象收集) -- 现象分析 -- 产生猜想 -- 验证猜想 -- 定位问题根因 -- 解决方案 

这里其实可以大体分为两步：

1）定位问题

2）解决问题

定位问题是难点，问题定位后，解决方案其实就呼之欲出了。

3.1 问题描述（现象收集）

复现频率

我们通常将复现频率高的问题称为“必现问题”，对于复现频率低的问题称为“偶现问题”，那这两类问题其实界限比较模糊，到底什么样的复现频率才能称为“必现问题”？我认为这两类问题的分类，至少从如下两个方面区分：

1、复现频率

对于研发人员可操作性的恢复手段，可以进行复现收集调试信息。并不是说100%复现的问题才是必现问题，比如10/1的概率，操作10次就可以复现，那也属于“必现问题”，对于复现步骤实施的时间不同，对于复现频率的定义也不同，这个具体问题具体分析。

2、是否有明确的复现步骤

必现问题有明确的复现步骤，而偶现问题，我们通常只能知道哪个业务出问题了，但是复现条件不明，有时操作A能复现，有时操作B能复现，或者只出现过1次，后面无法复现等。

对于我们技术人员而言，通常“必现的问题，都不是问题”，必现问题，明确复现条件，收集调试信息，进行分析即可。而对于偶现问题，由于没有明确的复现条件，现象收集且现场稍纵即逝，对于我们问题定位增加了许多障碍。

• 偶现问题分析

1. 默认偶现

遇到问题，默认为偶现问题处理，收集一手现场信息，否则没有现场无从分析起。

2. 缩小复现条件

收集现场信息后，可以通过实验，逐渐明确复现的条件，将问题描述的的越来越精细，定语加到足够多，比如如下步骤，通常将一个问题描述清楚，也就定位到问题了。

1、设置led时会导致按键无法响应
2、设置led为闪烁时才导致按键无法响应
3、设置led为闪烁时，并且按键为按下状态时，才会导致按键无法响应

随着问题复现条件逐渐明确的过程，一个“偶现问题”其实也就变成了一个“必现问题”，那也可以这样说：必现问题是复现条件明确的偶现问题。

3. 加严测试（多机压力测试）

有些偶现问题，复现频率低，或者无法复现，这里就需要进行压力测试，目的是摸底概率，以及进行影响评估，如果压力测试无法复现，则评估不需要修复，如果一个问题复现的概率极低，那这个问题没有修复的意义，投入产出比不成正比，比如flash的擦写频率是100w次，而常规用户最多使用几千次，那这就不算是个问题。

现场收集

现场需要收集哪些信息，通常有如下共性的，具体业务具体分析。

1、log信息

2、挂起的coredump信息

3、业务的状态信息，调试命令等

3.2 影响评估

影响评估二象限，根据核心业务+复现条件。

核心业务+ 必现，影响最严重，需要最高优先级跟进。影响评估最重要的步骤，解决投入的优先级和人力资源，严重市场反馈问题，需要通知上级知晓问题情况，以及最高优先级跟进。

3.3 问题定位

解决问题是一个实验性科学，根据现象进行猜想很重要，通过分析现象，然后现象对应的业务代码走读，业务分析后，产生可能的猜想，注意猜想的逻辑链条很重要，不能凭空猜想，猜想的可能原因概率由高到低，进行实验验证猜想。逐步缩小范围，明确原因。结合现象再次分析，进行一轮轮的循环和反馈之后，定位原因。

正面跟进和侧面跟进

问题跟进方向：

• 正面跟进

对于现象明确，直接根据现象，分析代码，然后验证猜想等，上文所说步骤即为正面跟进。

• 侧面跟进

1、历史解决问题，避免重复的路，是否已经解决过。

2、历史提交排查对比

3、回退提交验证(narrow)，正常和异常软件之间的差异

使用范围：偶现问题，现象不明，正面排查受阻的情况。

对于所有问题，首先要尝试正面跟进，尤其简单问题，先进行代码分析，对于正面分析受阻，不要死磕，尝试从侧面进行跟进。

一些技巧：

1、 对比大法：对比正常和异常情况、软件、现场log等信息

2、正面跟进和侧面跟进

3、历史问题排查

4、narrow down(回退提交验证)

5、 大脑重置原理：

被动重置：有些问题睡一觉起来就解决了，突显灵感，就解决了。

主动重置：分析问题“广度优先” ，切勿深度优先，一条路走到黑，及时折返，尝试其他路径。

4、一个矛盾点

在用户问题处理时，收集信息与恢复手段存在矛盾和冲突，用户角度想要赶紧解决当下问题，而研发人员角度则想要收集更多信息，找到根因解决，避免影响其他用户。如何在这两者之间平衡是一门学问，需要经验，比如：

用户路由器wifi出问题无法上网，先保留异常路由器现场，给用户替换一台正常路由器使用，这样即保证了用户正常使用，也保留现场方便调试。

5、问题分类

在研发活动的不同过程中产生的问题，影响递增，获取第一现场越难，矛盾越大，影响和投入成本越大。问题流入用户手中，对于品牌形象都会有一定影响，所以问题暴漏越早越好。

1、研发自测 (研发环境)

2、测试问题 (测试环境)

3、上线部署（工厂生产环境）

4、市场反馈 (用户环境)

这里主要讲一下，各问题的处理注意事项：

• 研发自测

这里测试用例要完善，并且要跟踪执行到位情况，以及做好跟踪，避免研发问题丢失，未跟进的情况。

• 测试问题

这里第一现场要跟进，避免现场错过，问题无法复现，或者重复复现，浪费人力。

• 上线部署

这里需要优先跟进，保证上线流程，并且工厂人员知识水平有限，认知有一定差距，需要沟通清楚现场情况，以及调试手段可能有限，准备调试工具和命令。

• 市场反馈

市场反馈问题跟进注意：

1. 明确严重程度，第一时间评估影响
2. 紧急恢复手段，防止客诉，同时保留现场
3. 现场调试手段，调试信息收集

影响评估后，对于严重问题：

1、通知上级知晓

2、紧急动作: 出货管控，下架软件等等

三、问题复盘

1、产生原因，各责任人的哪些方面没做好，后续避免此类问题。从流程上、习惯上推行一些可执行的方案。

2、全面排查，同类问题一网打尽，不能case by case解决问题。

3、本次跟进哪些方面没处理好，增长哪些经验，后续处理此类问题如何处理得更好。