最近招了好些新人，发现一些共同问题。

开发过程中，出现问题，诊断排查没有章法，非常耗时。自己很受挫，绩效也很低。

首先明确一点，绩效低是错的。不能无休止的黑灯瞎火去所谓的解决问题。其实毫无绩效。我们只看结果的。如果过程不对导致绩效低，那是要批评的。

我们有个原则，30 分钟没有头绪，务必整理问题分析报告文档。

这个分析报告文档，是 ppt 格式，从现象出发，检查时间点的日志，并分析日志。

如果没有日志，就需要补充日志。如果条件允许，可以打上短点，直接疑点代码的执行逻辑为什么不合理。

如果是底层出错，对日志不明白，就需要搜索检索。搜索的时候，一定注意搜索英文站点，可以通过 bing 来搜索。

日志的分析，需要明确问题的故障点。我们需要回到设计领域，明确系统架构工作原理，这样方便分析问题到底在哪里。

明确故障点，通常采用采用折半查找法，对每个接口数据的输入输出进行检查，看看是否正常。这个折半查找其实和维修家用电器差不多，对电路每个节点检查，看看电压波形输入输出是不是正常。只是在软件中的接口是数据，需要经常接口数据是否有问题。如果有问题，就往源头方向查，最终定位到代码。

所以要排查定位问题，需要理解系统架构，需要学会查看前后端各种日志，需要明确接口含义。

所有这个分析过程，都需要记录在 ppt 上，边分析边记录，好脑筋不如烂笔头。记录下来，一方面是方便自己回顾分析，不至于在各种问题现象中迷失错乱。另外一方面，如果不能解决，可以拿着这个排查报告求助他人，可以高效得到支持。因为任何一个分析失误，都可能引导到错误方向，空对空说自己的分析结论毫无意义，必须看原始现象日志才能做出结论。

排斥解决问题，是作为开发人员首先必须过关的一个技能，这是作为职业工程师的第一步。必须学会固化这个套路，这样才能建立战胜问题的信心，才能提高工作效率，才能进入追求卓越的正循环。

很多人被问题打败，甚至觉得自己不是做这一行的，对问题产生惧怕，看到问题慌乱，这是走向崩溃的负面。必须严格基于上面的套路来做，及时寻求抗投诉服务器帮助，不断高效解决问题，才能重获信心，重新进入追求卓越正循环。
Good.

能不能给个 PPT 优秀实例，给参考下？

PPT 要素：
1 、现象（截图+描述）
2 、时间点的日志（日志详情、自己对日志的分析），还有什么是补充日志？重现现象然后关注日志？
3 、要是能单步跟踪...其实很多问题基本能解决吧....除了多线程这种不太好跟踪的情况
“日志的分析，需要明确问题的故障点”，故障点都找不到呢？
“我们需要回到设计领域，明确系统架构工作原理”这个是前辈要做好的事吧？新人难道能凭空了解吗？
“折半查找法”我看你的描述就是单步跟踪调试....

面向 bing 编程

你好像被降权了，回复收不到。
这个 ppt 调试法是微博上看到的。