随着项目功能越来越重后，很多业务的深度耦合以及业务流程的冗长，导致出现的线上问题越来越多并且很难直接定位原因。此外，笔者负责的业务又是IM模块，线上问题的表现形式更是千奇百怪。在处理了诸多问题后，有必要把处理线上问题的过程固定下来，整理出相对通用的流程。
第一步：明确问题
线上问题不是已经上报了吗？为什么还需要明确线上问题呢？一般而言，线上问题都是由用户反馈的，用户对具体的业务模块和专业术语基本不了解，甚至问题的展示方式都描述不清楚。这时候，在拿到线上BUG时，应该先确认用户提供的信息是否能够确定具体的场景？发生问题的大致时间？出现问题时登录的账号？等等。
第二步：分析问题
在明确了问题后，我们的心里应该已经对问题有了一个初步的判断，比如这个问题是可能是接口数据问题或是前端展示逻辑异常，缓存数据出错等等。在有了初步的判断后，就可以拉取用户的日志，查阅用户的接口日志等数据来验证是否符合预期。
有了初步判断及获取到用户的日志信息后，下一步就是在各种日志中摸清楚用户的操作流程，消息流转也好数据处理也好，要把这些流程一步一步的分解，把每一步的数据做验证，最终尝试得出问题出错的可疑点
第三步：复现问题
尝试复现问题是解决线上问题非常高效且是验证问题原因的重要一步。
（1）如果对疑难问题分析艰难，用户日志获取不到等场景下，可以先针对该业务场景进行问题复现，当然也可以咨询用户的详细操作流程，我们来个情景再现。
（2）如果我们对问题已经有了初步的原因分析，那么可以直接尝试改动代码或是Mock数据，去主动的复现问题
（3）复现问题也可以帮助我们在问题处理后回归验证是否已经真的解决了BUG
第四步：解决问题
这里可以分为两个场景
- 找到BUG了：如果已经确认问题原因，那么在自行修复，场景回归后，还应该对自己的改动记录做影响范围分析，code Review,并不是说问题就一定要立马修复，也考虑成本，对功能的影响范围等。当然，最后一步必须是找测试再回归相关场景
- 没找到BUG：很多时候疑难问题是无法立马找到原因的，那就放任不管吗？当然不行。我们在问题分析及排查后，至少应该知道大致的问题场景，不能定位BUG的情况下，应该对整个链路流程进行 日志添加，如果问题再现时能够更好的解决问题。
第五步：归因问题，复盘总结
尝试把问题划分类型，对出现问题的原因进行复盘总结，当然我们是只针对BUG，不针对任何研发。
网友评论