运维问题排查能力提升专项-01-通用软件处理流程

一、前言

年初与xxx分公司系统总工沟通，今年如何让本地化研发团队与分公司配合的更密切，应该做些什么才能让本地化团队更大的发挥他的优势。但毕竟本地化研发也是近两年才刚起步，处于牙牙学语的婴儿时代，可供借鉴的成熟经验不多，所以我们一起商量今年实验性的搞一波《现场问题排查能力提升专项》工作。考虑到失败是成功他娘，但经验可以互相分享，特此将过程中的一些资料po上来，供大家讨论，谨慎拍砖->毕竟故意伤害是可以入刑的（手动狗头）。

本篇没什么干货，主要是尝试从研发和驻地的角度分别分析一下，正常的一个问题处理生命周期应该是怎么样的，并且整理了一下工单描述及解决方案的模板，尽量做到同一个问题不要（ying）重复出现。

二、推荐通用流程

2.1、现象分析

2.1.1、确认问题现象

• 问题提出人是谁
• 问题现象是什么
• 是否有特定场景

2.1.2、确认操作步骤

• 问题所在系统、模块是什么
• 哪个账号在什么时间操作了什么
• 是否有关联的前置业务流程

2.1.3、尝试复现问题

• 当前现象是否依然可以复现
• 是否为已知业务流程或操作步骤问题
• 是否为其他已知问题

2.2、场景分析

• 当前流程涉及哪些产品及应用
• 操作流程及应用间关系梳理
• 分析涉及应用环境近期是否存在变更（如某个系统升级）

2.3、内部排查

• 个人既往经验
• 论坛及FAQ等知识库（需持续保持技术敏感度，有个模糊的记忆，需要时模糊搜索即可）
• 查看应用日志
  • logback.xml或logback-spring.xml控制日志输出
  • jdbc为数据库相关日志（系统慢时可第一时间使用正则寻找是否存在慢sql）
  • err为错误日志，根据问题复现时间点观察是否存在明显错误
  • stdout为标准输出日志，大而全，但内容较多
• 寻求团队内支持（师傅、高工）
• 寻求产品专项负责人支持（一般情况下每个高热产品都会有一个专项负责人）

2.4、反馈研发（工单）

• 现象及场景描述
• 简述前置排查思路及结论
• 辅助研发定位并解决问题
• 持续跟进问题进度及风险，并及时升级

2.5、典型问题总结及分享

• 论坛发帖
• 经验分享
• FAQ清单维护
• 重点问题专项活动
• 自我提升、榜样的力量、定级加分

三、参考资料

3.1、运维同学参考模板

反馈问题时应尽量详细地描述过程及现象（有的工单描述就是几个字“卷宗打开报错”。是所有人打开卷宗都报错吗？在哪个系统打开会报错呢？报什么错呢？什么时候发现的这个问题呢？等等很多疑问没有澄清，沟通成本也蛮高的）
【版本号】程序类问题的版本号很重要，否则双方都会付出较多的无效时间
【问题描述】要把问题描述清楚
【操作步骤】尤其是多系统交互等复杂场景，一定要梳理出来，否则有时候研发也不知道应该去哪儿查
【现场分析情况】现场已进行的努力有哪些，有时候这一步可以为双方节省很多时间浪费

3.2、研发（或二线）同学参考模板

一个是总结性的文字一定可以让自己不断的学习到新的知识，另外让别人一目了然的知晓该问题的前因后果。有些人的解决方案就是四个字，“远程解决”，对后来者来说毫无用途，后来者甚至包括自己（两三个月后遇到一个相同的问题，没有资料留存的话你还能想起来多少有用的信息？）
【问题补充】一句话澄清问题（非必填。主要是用于补充工单描述与实际问题严重不符时澄清问题现象）
【根因描述】一句话描述根本原因（必填。不宜过长，推荐后来者必看）
【解决方案】该问题的最终解决方案，要清晰（必填。详细描述问题的最终解决方案或当前的临时解决方案，虽然说详细，但也不宜过长，推荐后来者必看）
【排查过程】尽量详细的描述排查思路和过程，要包含排查过程中的核心注意事项（必填。精简各阶段主要步骤，摘重点，不要记流水账，推荐后来者有时间的话看一遍）
【后续计划】若有后续待办则在此处描述（非必填。若未彻底解决，则推荐书写工单处理人针对此工单的后续跟进计划，主要用作给自己提醒）

3.3、工单解决方案参考

3.3.1、解决方案参考一

【根因描述】老卷宗获取卷宗目录结构存在死循环逻辑导致
【排查过程】
查看工单描述（反馈新版本有问题，还原回老版本就没问题），发现工单附件已经包含【cpu死锁排查过程.docx】，遂下载查看（有的时候现场给的附件真的对排查问题很有帮助）
根据文件内容确认排查过程没问题，但对ftp服务相关代码出现死锁的结论持怀疑态度（根据文档中信息来看，最耗cpu的确实是ftp相关逻辑处理）
远程现场单独按照CPU飙升过程排查，依然定位到与工单附件中相同的问题代码堆栈
查看对应代码提交记录，发现提交记录顶部有个解决死循环的合并，死循环肯定会引起CPU飙升的，跟问题修改人确认代码已经整合至4.5.5M1
再次查看代码修改位置，原while(path.startsWith("/")){path = path.substring(path.indexOf("/"));}代码的indexOf后面增加了个+1，书写Test类验证路径开头为/时，原逻辑确实会造成死循环，查询现场数据库，确认生产库中存在部分协议中路径属性为/开头的记录（转义后为%2F）
待用户下班后现场升级新版本，经验证问题未复现，同时持续观察一段时间，工单先申请关闭
【解决方案】现场升级新版本解决（新版本已解决存在死循环逻辑的问题）
【后续计划】整理发帖

3.3.2、解决方案参考二

【根因描述】卷宗主表和文书表丢失主键索引导致
【排查过程】近期发现多地因文书表主键索引丢失导致应用缓慢，直接给现场脚本查询文书表是否存在主键索引，现场确认确实丢失了对应索引，添加索引后验证效率恢复
【解决方案】删除主键冲突的垃圾数据，并创建丢失的主表、子表索引解决
【后续计划】总结会上跟其他团队反馈一下若收到卷宗慢的问题，先确认一下卷宗主表和文书表是否主键约束丢失，并收集jdbc日志使用正则表达式排查是否存在慢sql

3.3.3、解决方案参考三

【根因描述】配置中心配置错误导致
【排查过程】
现场反馈研判跳转卷宗页面空白，F12报错，看截图是调用/rest/xxx/xxx接口报错500
要到后台日志，看到获取new.xxx.url配置NPE，要求现场配置该值（配置为xxx-web服务地址）
重启后现场报错404，在dev环境查看地址为xxx服务，现场修改后重启，依然404
按照dev环境核对现场配置，发现xxx-web、xxx、setting服务地址未配置，配置后重启解决
【解决方案】配置中心配置ui.xxx.url（xxx-web卷宗前端服务）、new.xxx.url（xxx卷宗后台服务）、new.xxx.pz.url（setting配置服务）对应值，并重启
【后续计划】月度复盘时传递此类跳转通用配置常见问题，并讨论是否应对外统一入口，内部自行匹配，降低现场配置带来的复杂度。