产品巡检的心得体会

1背景说明

公司是平台产品及技术解决方案的提供方，在目前公司依然承接实施项目，结合项目磨炼产品及人员培训，收集一线客户需求不断充实、细化、完善公司产品及交付体系。在实际项目推进过程中，如果平台出现不稳定及间歇性不能响应的情况，就会影响用户的使用体验，此类问题需得到高度重视，否则一旦成为客户诟病之处需要花费更多时间和精力才能扭转客户对平台的认知。由于问题是间歇性发生难以实现高概率的重现，问题难以定位，因此需要对平台进行巡检排查分析平台不稳定的原因。解决相关问题，保证平台的稳定性，提升客户的满意度及体验度。
本文是结合项目实际巡检过程中的体验、经历及个人领悟的总结，为后续类似情况发生后的处理方式、方法提供参考借鉴。

2总体思路

整体工作推进过程中需要明晰当前有哪些问题，体现哪些现象，结合问题分析平台中的影响因素，分别对影响之处进行检查确认，明确问题分析情况，影响因素及解决方式。

2.1问题梳理

结合现场交付团队整理内容及客户现场表述，个人问题跟踪所发现问题的情况对问题进行梳理，明确问题的种类、优先级、责任人、时间计划、验证方式、核对负责人。此过程中重点在于收集、汇总、明确，结合问题的情况明确影响问题波动的功能代码及配置，需要对相关涉及内容进行巡检，检查是否有问题引发的隐患。

2.2架构梳理

首先：对于项目实施中的当前部署架构梳理，明晰产品部署情况、部署架构，结合实施团队提供的部署架构及问题共同分析是否存在因部署而造成的问题影响。其次：对平台功能架构梳理是否能够完全涵盖支撑当前问题中描述的场景情况。最后：对产品级、项目级的功能代码进行检查，有无因代码逻辑问题影响问题发生的影响。

3过程方法

解决问题的过程中有问题、有目标、有解决、有交付，首先需要对问题明晰，哪些是平台级别，哪些是项目级别，针对不同问题制定解决方式；结合问题分析明确每个问题的解决目标，与客户明确后，进行优化迭代至解决问题达成问题解决的目标。

3.1问题明晰

整理问题清单，包含分类、描述、优先级、提出人、时间，问题分析，解决人、时间，验证人、时间及交付补丁文件版本，根据清单问题进行分类，划分是平台级还是项目级明确相关负责人及解决时间。
平台级别：结合问题清单对访问过程中需要涉及到的相关代码进行巡检，排查是否存在问题，如：性能影响的循环中操作数据库；redis连接没有设置密码；查询数据库没有过滤条件等；
配置级别：平台配置内容进行巡检；典型包含：服务器系统本身优化参数，中间件如：Nginx、Redis层面安全及性能；产品本身性能优化内容巡检排查；
项目级别：项目实施过程中所扩展的代码巡检，巡检遵循代码巡检规范；项目级制定对接方案梳理是否存在纰漏能否涵盖全部业务场景；

3.2明确目标

结合问题清单中问题情况的分析，需要与项目团队及客户团队明确最终对应问题的解决目标，明确问题的原因、整改责任人、解决时间及客户方确认人、确认时间，保证问题的闭环，而不是自我主观臆断认为完成就关闭该问题。实际确认需要以客户方提出人明确解决为准。

3.3巡视检查

梳理部署架构及部署模式，对平台代码级别，配置级别，服务器级别分别进行巡检，针对发现问题进行逐个解决，包含代码优化、性能优化、服务器优化。
部署巡检： 部署结构、部署资源情况，部署服务器优化情况统一确认检查，明确核查内容、负责人及核查结果；
产品巡检：问题相关功能代码巡检，结合本身代码规范机制及逻辑梳理，排查问题影响因素；

3.4迭代优化

有问题、有分析后需要着手落实解决问题，对问题不断迭代优化，优化过程有整理、有记录、有验证、有对比、有分析，证明优化内容为真实有效的。

性能问题：需要对服务器、中间件、产品进行性能优化，明确各节点参数及优化结果；产品上典型为添加缓存机制，对于动态信息需要核查优化代码逻辑，减少频繁请求数据库交互；
功能问题：功能问题需要具体分析，首先需要保证功能的可用性，然后结合代码进行优化分析，有针对性的调整、验证、交付；

4验证交付

问题交付后需要说明功能验证方式，调整内容，输出整体巡检调整过程，问题分析梳理交付产物交付客户，持续跟进5~7天是否重现问题至关闭。

4.1验证方式

问题验证划分几个阶段，负责人内测、项目团队测试、客户验证测试、跟进观察测试，如果问题解决稳定运行一周内依然没有复现则视为问题关闭。
负责人内测：功能负责人完成功能调整需自身对功能进行单元测试，保证功能的可用性；整理交付内容以邮件的方式发送升级补丁包；
项目团队测试：项目团队需要对交付客户功能负责，对开发人员交付功能进行复测，能否满足问题解决目标，然后转交客户验证测试；
客户验证测试：客户验证测试作为问题闭环的重要环节，根据用户验证反馈总结记录问题验证人及时间，标志问题进一步状态；
跟进观察测试：对客户反馈通过验证的问题跟进观察如果7天内没有再次重现则标志着问题关闭，实现问题的闭环；

4.2输出产物

输出整体排查过程，对平台部署架构、巡检过程、记录发现问题、对应的解决方案及验证监控进行总结记录，输出相关产物作为上一节点的总结输出；典型交付内容如下：
部署架构说明：项目中产品部署体系、部署架构说明文档，包含部署架构图、服务器IP、部署目录地址及服务器配置信息等；
巡检状态说明：结合巡检过程的巡检内容的状态说明，如：服务器状态、中间件日志状态、集群状态、产品性能状态等；
巡检问题清单：巡检过程中发现的问题及客户使用过程中发现的问题清单，主要明确责任人、时间、验证人、时间；
总体巡检报告：结合整体过程输出巡检的报告，包含解决方案，验证方案、结果及跟进监控状态；

4.3跟进观察

问题验证后不是真实意义上的问题关闭，验证后需要紧密跟踪观察相关问题是否依然有反复出现或连带影响其他业务场景的使用，对于问题紧密观察跟进7天后，如果没有再次复现问题则标记问题为关闭状态，如果出现场景涵盖不全情况需要进一步迭代优化至连续7天不再重现，标记问题关闭。

5写在最后

再成熟的产品也会出现挂万漏一的情况，项目交付过程好比人生，过程中出现问题、挫折是常态，有问题并不可怕关键的是如何快速的响应、解决问题，不要让问题发酵、膨胀，出现问题直面应对、把握时机、响应解决。

5.1有理有据

对于问题的原因有的理解分析及对应的解决方案，且能够与客户交流清楚具体的原因及问题以及相应的解决方案；有理有据的说明问题原因所在，不是自身的问题需要明晰相关责任人共同推进；自身问题也不推诿积极响应解决，提供解决问题的计划及时间节点，推进下一步工作，且工作进度同步客户实现工作推进的透明化。

5.2积极应对

面对用户的反馈不要消极反馈，而是积极应对，让客户安心，增加客户的信心，客户对平台的信心是需要逐步累积及建立的，客户反馈的问题需要高度重视，不要拖沓，把握问题解决的时机有效建立客户对平台的信任度及认可度。如果平台出现问题，团队承认缺不积极响应则会造成客户的信任度不断的降低，当客户认知形成固式后，需要花费更大的精力、心力才能扭转认知。

5.3资源协调

领导也是一种资源，不要畏惧领导的评价为不反馈突出问题的重要性。现场团队是以实际项目最终结果论成败的，团队成员需要以实际项目走向为驱动，为项目争取优质资源推进项目发展，而不是因个人畏惧而任由项目“铤而走险”。当然资源是解决问题的一种有效途径，却不是必要途径，不能产生依赖心理，需要自身从内心直面问题、分析问题、分析解决方案，进一步落实解决。

5.4跟进关闭

有开始就要有结束，问题最终是需要被关闭处理的，而团队反馈问题后需要对问题进度有跟进，接收交付验证后需要推动客户进一步确认，持续跟进问题的复发情况，至问题关闭，形成问题的闭环。而不是只反馈不跟进这样问题会越来越多无论是对项目交付还是客户认证均是无任何益处的。