无意间翻到五年前的工作笔记

今天在拿U盘拷贝一个东西，发现了16年的一个工作笔记。我记得我是11月17日入职，入职以后就开始处理各种问题。简单的扫描了一眼，发现了一些问题，当时作为核心开发，视界还是不够宽。

1，一直在处理问题，遇到一个处理一个，并没有沉淀成知识推广出去；

2，缺少培养人的思维；

3，缺少规范流程；

4，当时没有就那些问题进行深入研究；

那个时候是真拼，除了保证自己有很高效率，还处理了这么多组内的问题，不过也是因为那两年的积累，才能在后来形成各种的规范和checklist。

时间	问题	备注
2015/11/18	修改协议空指针异常
2015/11/20	定时器里创建线程池，信审一天就得因为cpu过高重启一次，	将线程池创建剥离
2016/2/19	总结生产问题	1）配置因素      1.1 risk项目，dbcp连接池初始大小，最大链接数没有配置（为默认大小8）；   1.2 运营商链接超时时间为30秒，在程序中调用了两次查询运营商数据，tomcat配置链接超时时间为30秒；   1.3 钱包那里配置的图片上传错误（第三方配置以后需要确认，环境变更通过邮件通知）；   2）历史遗留因素      2.1 测试环境数据库和正式环境数据库不一致（字段数量和字段编码）；   3）人为因素      3.1 测试数据库开发调试时修改过，没有提供sql脚本；   3.2 后期流程变更，获取运营商数据，没有在loan中变更调用risk的等待时间（调用运营商等待超时为30秒）；   4）其他因素      4.1 第三方接口不稳定；
2016/2/25	当两个slb的项目之间有交互时，且交互的项目在同一台服务器上，将不能互通
2016/2/26	生产问题总结	1. 数据量大的通话记录，通讯录运营商未加索引，导致查询过慢 2. 获取闪银运营商原始数据过慢 3. 定时任务项目部署时，不能再tomcat/conf/server.xml中配置Context指向项目
2016/3/1	重复工单问题解决	增加分布式锁
2016/3/2	处理生产数据，保持一致性
2016/3/3	防止重复用户（钱包推送）
	钱包后台调用slb无法分发问题	slb默认配置了会话保持
2016/6/6	项目sql优化
2016/3/10	卡牛上线时出现的问题解决	上线后卡牛的正式环境接口用get无法请求到 分析日志后卡牛出现的问题 1.出现问题最多的是，调用外部数据接口字段过长，无法入库问题(第三方提供的接口文档不详细，运营商，淘宝，卡牛终端数据) 2. 第三方有些字段类型变更无通知（运营商） 3. 空指针异常(运营商，推工单) 4.一些脚本导致数据库被锁(删除批次信用卡数据) 5.第三方给的数据字符编码不统一，无法入库(淘宝和运营商) 6.第三方接口不稳定，连接被拒或者读取超时(数据中心，查明原因，服务器重启没通知)
2016/3/15	1）单表数据量数据达到7000w，在使用多线程分页获取数据是速度过慢，通过改造多线程计算每批次获取的最大主键，以大于主键值去limit获取分页数据，效率提升非常多 2）ots服务器记录日志，日志文件过大拖累迁移速度	我记得当时只开发了一天，就开始迁移数据了；
2016/3/18	1）linux和windows上mysql驱动查询出的字段大小写不一致 2）gson在数据量大的时候转换效率较低
2016/4/12	信审代付接口裸奔解决
2016/4/19	post请求参数最大值为2mb，大于将无法上传，修改tomcat server.xml中的Connector maxPostSize 的值；
2016/5/13	kill进程部署，导致数据中断，用户数据残缺	禁止使用kill，优先使用shutdown
2016/5/18	贷后报盘过慢问题排查，将6小时报盘跑批优化到1小时内	数据量过大，关联表查询： 1，增加临时表，将数据按id，一次+2w抽入临时表 2，再以临时表关联大表
2016/5/26	运营查询视图导致锁表	屏蔽后台sql查询功能
2016/5/30	排查64服务器cpu及内存占用过高的问题 需要排查所有的同步代码块，占用内存比较大
2016/6/1	调用黑灰名单异常，非接口问题，已确定是封装的工具类中静态方法调用静态方法造成的线程非安全问题，解决方案一：降低线程数 二：重写工具类
2016/6/6	外部黑灰和芝麻调用这块，并发超过15个就挂，服务器承受压力较小
2016/6/16	三体上线问题排查	两台服务器jdk版本不一致,导致有些类找不到
2016/6/17	排查贷后抽数一直抽同一批数据的问题	同一个事物中出现查询缓存，暂时解决了该问题，具体原因还需要深入分析
2016/6/21	三体线上无法访问问题排查	微信推文，一下子涌入的用户太多，用户首页较大，一下子拖垮了服务器，已经tomcat调优
2016/6/27	排查信审打开页面过慢问题
2016/6/28	信审环境并发比较大，sql语句比较复杂，未做优化，导致cpu利用率飙升到99%，其他sql受到影响
2016/6/30	线上问题排查	营销推广给力，服务器定时获取运营商额度，无法及时给出用户额度，一方面系统资源调配问题，一方面第三方接口获取数据问题
2016/7/5	gson序列化int转double问题排查
2016/7/6	排查项目访问过慢问题，阿里云服务器问题
2016/7/7	重复推单问题排查	由于推单过程时间较长，事物未提交，还需要更新表的缓存，导致表被锁
2016/7/7	排查线上问题	数据库压力大，将非业务查询切到从库
2016/7/8	分析现有系统过慢原因，将对日志输出以及数据库方面做相对调整
2016/7/11	解决线上日志过大问题
2016/7/14	信审有一条sql卡数据库
2016/7/17	定时任务： 1)不能全部获取要处理的数据，预估处理速度，设置每次轮询的最大值； 2)不能重复获取（有的定时在积压数据时会重复获取数据）； 3)将对定时进行分散，及时性要求不高的处理，放到A,B机中处理，C机只处理及时性比较高的任务。
2016/7/28	解决redis无法获取资源问题	获取jedis对象时，优先从ThreadLocal中获取，防止重复获取新的占用资源
2016/8/8	排查api线上问题	1. 高并发情况下lo4f死锁问题，提升log的级别（ log4j升级到2.x） 2. 调用外部黑灰名单导致json转换死循环，栈溢出 3. 实名接口等待时间过长，同步代码块出现死锁
2016/8/9	api gson问题排查，高并发问题
2016/9/21	数据统计项目sql优化
2016/10/11	解决数据量大导出慢，使用SXSSFWorkbook
2016/10/12	数据统计导出cpu利用率200%多排查	数据统计导出数据量大，创建的对象过多，导致jvm gc操作比较频繁，已经对应的gc日志输出，后期监控
2016/10/13	排查app生产服务器内存+cpu过高问题	日志文件过大，没有做日志分隔
2016/10/25	日志过大会影响系统性能（磁盘io过大，影响cpu）	非必要日志不输出
2016/10/26	短信接口被攻击（ 多个ip来源利用程序频繁调用）	按人，按ip限流
2016/11/8	生产主库cpu 100%问题排查	信审慢sql拖挂，后续将授信库剥离
2016/11/11	生产环境只读实例延迟问题处理	数据部门统计数据一条sql停留了20000多秒
2016/11/17	排查信审系统线上问题
2016/11/22	排查93未进工单的问题	调用火眼接口，报500错误，无法过黑灰名单，导致无法进单
2016/12/6	生产日志过大问题解决
2016/12/6	魔蝎导致cpu过高问题排查