一直有计划给大家整几篇关于性能调优、问题定位的实战类文章，秀一下我仅有的三板斧，之前没有找到合适的主题，因此一直搁置；正好有位小伙伴提了一个非常有意思的现状，借此机会，我们也来看一下，当出现问题之后，我们的应对步骤是哪些？

基于问题的复盘模板

按照小说的三要素，我们一般做问题分析/故障复盘时，也会有相应的几个要素;

本节内容以一个轻量的复盘形式，给大家描述一下整个问题的情况，方便有做复盘诉求小伙伴进行参考

1. 问题概要

技术派的本地耗时相比较于生产环境高很多

2. 影响范围

无实际业务影响，主要影响的是用户体验

3. 全流程回顾

时间点	事项	责任人
2023-08-26 20:49	反馈渠道：【技术派知识星球VIP微信群】 问题描述： 同一接口本地耗时远高于生产环境	@树人
2023-08-27 08:57	响应问题，尝试本地复现，然后确认问题，开始定位问题原因	@一灰
xxx	阶段性的反馈问题进展（比如什么时间点初步定位问题原因)	@一灰
xxx	阶段性的反馈问题进展（确定问题原因，开始着手解决问题)	@一灰
xxx	阶段性的反馈问题进展（问题已修复，本地测试回归)	@一灰
2023-08-27 12:34	问题修复上线，待反馈人验证	@一灰
xxx	反馈问题已处理	@xx, @一灰

全流程回顾主要是记录这个问题从发现到解决的整个周期内，各关键事件的触发时间点、相应的处理人、处理动作；

稍微现实一点，它的主要作用就是衡量故障的影响范围、事故等级、需要背锅的人/团队，以及相关责任人的能力评定

题外话：

当我们看到这个表格的时候，心里就得清楚，问题来了之后，有一点进展就要及时同步出来，表明我们现在正在努力的处理这个问题，现在这个问题的处理动作正在往前推进，这样即便你花了两天才解决问题，最终给人的感受，比你一天解决完问题然后再同步反馈人问题已经修复，要好得多

另外补充一点，要想作为一个合格的职场人，学会分锅是一项必不可少的技能（加粗，仔细揣摩）

4. 问题原因

这一节，则是主要分析为什么会出现这个问题，分表层原因（诱发这个问题的原因），根本原因（最终因为xxx导致会出现这个问题）

省略

5. 问题总结

基于上面的问题原因分析，小结一下整个故障的情况，比如有哪些做的不好的，需要改进的；有哪些做的ok的，值得推广的...

6. 改进计划

改进计划就是针对上面问题总结中，不好的地方，给出对应的改进方案，并落实到具体的执行动作，交付的时间

问题定位全过程

这一篇的重心将在这一节内容，我会将我的整个问题的分析定位及修复的过程，尽量完整的还原出来；因为这个问题确实比较简单，看下面内容的小伙伴，重点放在思考的过程上，不要拘泥于手段

1. 问题本地复现

基本上所反馈的后端相关的问题，并不是一上来就开始分析（当然也不排除某些特殊情况），通常第一步就是尝试再本地进行复现，基本上只要本地能复现的问题，那就都不会是难搞的问题

我们来实际看一下，本地的首页访问耗时情况：

通过实际对比，本地耗时确实比生产环境上要多一倍；但是上初中(或者是高中？)的小伙伴，应该知道物理中有个控制变量法的对比策略，本机与服务器差异太多了，两者的对比结果能说明的问题实际上较小

当然这也不妨碍我们认定这个问题的存在，接下来我们进入问题的分析篇

2. 问题定位分析全流程

看过技术派系列教程的小伙伴应该知道，我们借助Servlet的Filter实现了请求相关信息打印的功能，其中也记录了请求的耗时情况，我们先看一下这个耗时是否和浏览器上的表现一直