开发过程中难免会遇到问题，问题的原因各式各样，呈现结果大致是相似的（功能非正常运作或不运作）。我们需要根据这些呈现的形式及常见的工具去定位这些bug，分析bug原因，然后去解决它。
具体响应的过程也就是 定位、分析、解决。
实际的线上环境与生产环境的处理略微不同，但大致思路是相同的，相对于开发过程中的问题来说，线上问题通常需要更加快速的响应及恢复。
第一步：
故障恢复（若无法保证 非常短的时间内解决并不引发其他的问题，首先要做的是恢复具体故障，把损失及想象范围降到最低）
1、在限定时间内，恢复故障。（若是临时进行中的类似于抢购活动等，分析问题回滚后具体的影响范围，联系运营人员制定紧急响应策略）
保存问题现场（问题现场的保存，直接决定了问题定位的速度及具体产生原因）
2、保存问题现场。记录线上环境及对应log记录，具体功能发生场景。（问题发生时的用户数量，机器或其他服务运作情况，网络是否出现波动等）
3、综合运维人员反馈信息、上线前测试信息、开发人员详细设计信息及自测信息。
信息采集（多方的综合信息能够保证 问题正确定位及相关的影响因素）
4、查看本项目上线信息
5、检查本项目所直接依赖的项目上线信息，及对应日志中相关log
6、检查本项目直接相关项目的上线信息，及对应业务中log
第二步：
定位
保存对应的现场信息及其他第三方信息之后
1、如果是具体业务模块的开发者（如果不是尽快联系），应该能凭自己的记忆直观的对问题产生结果的推测，然后查看对应log判断是否与自己的推测一致，如果推测正确，根据问题现场实现测试环境下的问题重现。（因为记忆和直觉虽然这种情况下通常是快速且准确的，但切记根据log进行分析验证，且进行测试环境下的问题重现）
2、如果推测失误，首先分析问题发生是否由于代码逻辑外因素影响导致（1、硬件问题 2、网络问题 ），如果是，联系相关人员解决。
3、上述并未定位问题的话，根据对应逻辑及接口信息结合对应问题现场的log信息进行问题的仔细排查。具体排查过程为：（首先缩小引发问题的异常点所在的范围，然后分析引发异常的原因）
0、结合对应上线信息（线上异常通常是由最近上线代码导致的，生产环境中可对应为最近修改的代码）
1、分析问题现场的各接口数据，确定正确信息的接口，确定异常信息的接口。根据具体逻辑 将问题定位到具体的模块中。
2、根据具体逻辑信息，以函数为单位进行验证分析，常见的工具例如mock 再进一步缩小问题范围。
3、根据业务逻辑信息及相关使用的技术信息进行异常点分析，得出最终结论。（结论得出过程中 需要进行大量的结论的正确性验证，如关键的测试用例及问题现场的信息进行异常点的验证）
与此同时测试人员，分析现有测试方案为何存在纰漏，测试用例是否完备，进一步完善对应的方案。
分析
确定引发问题的异常点之后
1、根据详细设计的阐述，相关代码的注释等，对代码的业务逻辑进行对应的分析，判断是否由代码逻辑导致。
2、检查代码的检查项、异常处理等方式是否正常等
解决
确定异常点及异常原因后，对代码进行修改。
1、确定初步修改方案，是否能对问题达到修复效果
2、确定方案不会产生其他影响（根据对应接口中的详细设计通常能够确定）
3、编码
4、单元测试，保证修改后代码块的正确性。模块的功能测试，检查是否解决问题，并且是否引发其他问题。
5、确定修改后代码的影响范围后，根据改进后的测试方案进行对应测试。
6、重新上线
第三步
case study
对问题进行综合的归纳及分析，检查是否存在相同的可能引发问题但未发现的代码。
附录：
常见技能：
1、log 日志
1、打印规范的日志信息
2、熟练使用日志分析工具
3、使用awk等对于小规模数据进行手动分析（正则表达式什么的必须要非常熟练啊，直接决定你的效率）
2、数据分析
1、接口数据
2、数据库数据
3、网络数据（抓包啦什么的）
4、debug 过程中的参数数据
3、养成问题记录的习惯
别让相似的问题绊倒两次，得学会举一反三，避免以后发生，且检查先有隐藏bug。
4、养成自己排查问题的综合方案，虽然大家大致相似，但仍然会有差异，有自己习惯的且高效的方式很重要。
ps：
1、断言、log什么的一定要规范使用啊。
2、一定要关注代码最近产生的变化，问题通常就出在这里。
日常的一点建议：
1、扩展自己的知识面及深度，对问题能产生下意识直观的反应。
2、熟知自己维护模块的业务逻辑，详细设计大量看，根据逻辑多看看代码。对非自己维护的相关模块，最好也要了解相关接口信息及最近产生的变动，保持沟通。
3、开发过程中碰到相关技术问题时，善于利用搜索引擎，90%这个问题别人也遇到过。事后记住深入对应技术点，没事儿看看源码，深入下原理，带着问题学习效率更高。
4、对于有经验的同事，多沟通多请教，不管是技术上还是逻辑上。
