掘金者说-第11期-硬核之复盘管理

第一季-思想篇

追求卓越，努力超越；持续进取，同创共享。

Hi,大家好！我是Lucky。今天掘金者说和您分享自己小本本笔记的文章，关于复盘更好的理解之一。

先给小伙伴讲一个词叫做复盘。复盘这个词，它是围棋当中的一个术语，就是当你一盘棋下完之后，再将我们前面的这盘棋，重新来回顾一遍，看看哪些棋下的好，哪一步棋下得不好，还有哪几步棋是可以下得更好的。把复盘运用到企业当中，可以保证我们的结果能够更好的达成，也可以让我们在执行过程中，能够更好的纠偏和优化的作用。运用到个人的工作中，可以让我们工作更加追求卓越，努力超越；持续进取，同创共享。

在开源小伙伴讨论群里、波波极客星球01和pig版本等群中，大大小小的问题，也有耐心回答的：大侠、大仙、大佬、大神的角色人物的帮助。现在，我讲述一个问题排查定位，大概思路方法，依据每个人可以进行借鉴调整参考。不希望重蹈覆辙，希望自我教训鞭策。

生产部署项目应用给用户使用，用户填写的身份证或者时间之后提交，后面在列表详情页面展示时，时间提前的一天;用户直接进行投诉反馈;根据生产环境，我们验证确实存在。联调开发环境，我们录入信息身份证信息填写之后保存数据，查验数据库是正常的。但是，传递给前端的时候，出现问题;紧急且重要的事情马上处理，后面小伙伴快速排出定位解决。

问题处理流程

问题解决步骤

生产案例回顾

例子1:用户无法登陆

这个问题，项目部署完成后，进行用户登录，根本无法登录，后台也未出现任何问题异常日志输入。小幸运在微信反馈内容：

我本机是正常，能想到两个方向:
1、redis密码排查
2、访问映射排查
可能方向不对，大佬一起看看

后来，大佬说映射没问题，那就确定了是密码问题。后面通过沟通、协调、配合及时的处理上线。

例子2:日期少一天

这个问题，搜索就发现解决方法。但是，就是不告诉我们如何快速分析定位排查解决。那么，我现在就复盘预演：

问题->反馈->复现->排查->定位->分析(思路)->解决(方法)->验证

发现生产问

原本正确：1995-05-29
前端显示：1995-05-28

提前后端定位，我们进行模拟复现问题;发现确实后端出现问题，使用Jackson的@JsonFormat注解时出现少一天，确定时区问题，解决：

比如数据库存的日期是1995-05-29,转成json则变成了1995-05-28
解决:
    @JsonFormat(pattern="yyyy-MM-dd")
	private Date birthday;
改成:
    @JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT+8")
	private Date birthday;
加上时区即可,中国是东八区

前端验证后正常、生产验证正常；推导其他可能性，后面修改类似问题：

    @JsonFormat(pattern="yyyy-MM-dd HH:mm:ss",timezone="GMT+8")
	private Date createTime; // '提交时间',
改成:
    @JsonFormat(pattern="yyyy-MM-dd HH:mm:ss",timezone="GMT+8")
	private Date createTime; // '提交时间',

例子3:内存泄漏了

这个问题，首先我定要从自身找原因，检查的自己写的相关代码，能看到的是时间输出写法和新建对象导致，其他一时没有发现“深知”代码没问题，觉得是第三方技术支持方那边，反馈帮忙查看后，他们指点一二，我们瞬间感觉：临表涕零，不知所言。常言道：当局者迷，旁观者清。观棋不语真君子,落子无悔大丈夫！我们忽略压测后的数据对数据查询造成的压力，后面修正代码缺陷。

例子4:空指针异常

这个问题，老生常谈。百闻不如一见，但是，我们往往忽略可能性，犯下低级错误，不要忧伤，不要焦虑，从中找原因复盘。

好了，就先到这里...