中国移动浙江公司IT系统故障详细分析报告模板 - 图文

浙江移动通信有限责任公司业务支撑中心

故障详细分析及问题解决

1、查询优化项目对查询代理异常时重试5次的机制进行调整，是此次故障的直接原因。

在实时计费、按量计费项目过程中，一方面为有效减少查询代理负荷，并且进一步减少帐务后台压力，确保实时计费用户加载能够按时完成；一方面为有效加强查询代理调用错误日志梳理管控（要求将查询代理的调用错误日志按类型、端口入库，如果将每次重试的量也入库，会导致统计的日志不准确），项目组决定对原有调用查询代理异常时重试5次的机制进行优化，在后台服务会持续异常的场景下，如无来源标记、数据异常、计算服务异常、路由关系不存在等场景下将重试5次的机制删除，但是一来未考虑到查询代理的配置原因，二来在设计的时候，场景未考虑充分，从而导致异常情况被扩大化，最终出现外围调用无返回，加上外围调用组装机制不合理，最终导致用户费用显示不准确。 2、查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一。 查询代理是连接外围系统和实时帐务核心系统之间的纽带，外围系统通过查询代理进行资金、余额、账单查询。查询代理目前部署架构是2台主机（上塘和滨江主机，各20个进程，每台主机对外提供3个端口供外围调用），而外围主要是CRM系统（网厅、IVR、短厅、帐管等）通过不同的接口调用，配置文件mdb.properties配置查询代理调用的域名和端口，此文件分为CRM APP、CRM批量和帐管批量三份。

2012年实时帐务二期进行查询代理改造后，期间对查询代理连接进行优化调整，相应外围客户端的调用配置信息也进行调整，但却忽略了上述CRM批量和帐管批量配置信息调整，最终导致外围CRM批量和帐管批量调用上塘主机都会失败。但由于外围查询有相应错误处理机制，遇失败后进行端口轮询5次重试，若调用上塘主机查询失败后，会轮询调用滨江的查询代理，因此该错误一直未显现。

3、帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之一。

查询代理外围客户端众多，包括网厅、信息推送平台、华为IVR、短厅/掌厅、自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在调用查询代理异常处理机制不一，存在不完善的地方，例如本次故障的帐管充值短信下发模块，充值后需要查询实时账单进行模拟销账，获取用户余额进行下发用户，但当调用查询代理实时账单查询失败时，程序会自动按照实时账单为0来进行模拟销账，会导致计算得到的余额虚高，从而下发短信造成用户误解。 1、完善外围查询接入管控，明确接口规范。

针对本次故障，首先对帐管充值下发短信生成异常处理机制进行优化，如果查询实时账单接口返回有问题，则不生成下发短信，从而防止用户收到不准确的余额短信。

此外，查询代理作为服务端，外围应用调用其相关接口，需加强接入管控，明确接口规范，确保外围异常查询处理逻辑可靠，必须具备容错处理，针对本次查询代理无返回的异常情况处理，需要梳理排查，尤其是涉及到资金相关、调用量大、影响面广的渠道，需要优先进行核实。同时，查询代理还存在另一风险隐患，由于外围对查询代理返回错误代码无法处理，因而查询代理约定出错情况将返回0，该问题同样存在隐患，后续需要协调外围渠道彻底改造。 2、完善查询代理架构。

查询代理作为连接外围系统和实时帐务的枢纽，需要进行框架优化，具备对外

故障解决措施

浙江移动业务支撑中心第21页

浙江移动通信有限责任公司业务支撑中心 围吞吐量、调用来源、成功失败数、错误类型、关键业务耗时进行有效记录，并且能够通过运维平台展现，最终达到可监可控，可视可分析。 3、梳理查询代理异常场景，加强开发人员对于账务后台框架的培训。 在BOSS账务开发组内进行BOSS后台框架应用开发规范的培训，针对查询代理返回错误的场景进行梳理，明确哪些错误是可以不进行5次尝试，哪些错误是需要用5次尝试来保证的。 改进措施（问题避免） 1）需求因素分析及改进 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 【原因分析】 2）系统设 计因素分【改进措施】□规范执行 □重复问题 □历史遗留问题 析及改进 【原因分析】 3）软件编 码因素分【改进措施】□规范执行 □重复问题 □历史遗留问题 析及改进 4）自测因素分析及改进 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 开发改进措施落实情况 ? 开发报告撰写人 故障责任小组 王涛 开发改进措施落实监督人 测试故障评估 王涛 测试故障分析 1）功能测试因素分【改进措施】□规范执行 □重复问题 □历史遗留问题 析及改进 【原因分析】 2）回归测 试因素分【改进措施】□规范执行 □重复问题 □历史遗留问题 析及改进 3）性能容量测试因

【原因分析】 【原因分析】 浙江移动业务支撑中心第22页

浙江移动通信有限责任公司业务支撑中心 素分析及改进 4）安全性测试因素分析及改进 5）编译因素分析及改进 6）上线因素分析及改进 【改进措施】□规范执行 □重复问题 □历史遗留问题 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 改进措施落实情况 ? 测试报告撰写人 测试改进措施落实监督人

5、关于12月27日客服平台系统运行缓慢的故障（红）

故障标题 关于12月27日客服平台出现系统运行缓慢的故障（红） 故障简明回顾说明 故障现象 12月27日8点32分，接到客服报障，反映客服平台出现运行缓慢的现象。 由于对缓存数据缺乏控制手段，随着免打扰用户、特殊名单配置的逐步增加，引发 APP频繁进行老年代内存回收（FULL GC），故障原因 占用大量内存导致App内存不足，从而导致系统响应缓慢。 故障标准 重要业务，涉及(1,3]个地市或(20%,50%]坐席，影响时间持续(60,180]分钟； 恢复情况 通过调整客服业务APP实例内存参数，由原先2G增加至3G，最终重启APP后恢复故障。 1、开发质量优化 （1）优化特殊名单的缓存、免打扰用户的缓存。采用JAVA BEAN替代BO BEAN，并只缓存有用的部分字段，可以有效减少缓存内存的不必要占用。（已提交优化改进措施 需求，BR2014010631 系统优化室-关于客服业务系统便签发送的优化需求，BR2014010214 优化客服系统特殊名单表、免打扰用户表查询方式的需求） 2、维护手段优化 （1）目前的监控无法及时定位FULL GC占用时间长的场景，拟结合FULL GC次浙江移动业务支撑中心第23页

浙江移动通信有限责任公司业务支撑中心 数和时间，设计和部署新的监控点，可有效提升该问题的及时发现和规避率。 （2）针对核心业务，研究压力测试技术方案，在测试环境和生产环境予以部署，可有效提升类似问题的及时发现和规避率。 3、系统架构优化 （1）将现网客服APP小机和JDK产品替换为X86刀片和Jrockit； （2）可考虑充分利用MEMCACHE，优化缓存实现方式，进一步提高缓存效率。 4、加强人员能力培养，知识传递 （1）协调亚联研发骨干和原厂技术专家来杭授课，组织现场运维、测试、开发核心人员进行有针对性的技术培训，积累进一步的监控、分析、故障定位方法和故障预案； （2）在后续团队建设中考虑加大对架构人才的培养力度。 故障详细分析 12月27日8点32分，接到客服报障反映客服平台出现运行缓慢，12点22分故障现象业务恢复，影响客服的坐席数量超过2/3。由于影响客服坐席>50%，影响时间详细描述 大于180分钟，故判定为红色故障。 事件单号 开始时间（系统） 开始时间（业务） 故障影响系统 故障处理情况 12月27日早上，客服APP实例Java内存回收FULL GC频繁,造成应用响应效率明显下降是故障的直接原因。故障时实例FULL GC时间消耗从前一天的1%上升到33%。 1、 现有缓存机制存在缺陷:缓存数据量过大造成内存资源不足频繁FULL GC，是技术层面造成故障的主要影响因素。通过对现有缓存数据的分析，发现特殊名单的缓存、免打扰用户的缓存数据特别多，分别达到了近24万多和10万多的数据量，在实现方式上通过全字段缓存，并且使用了BO BEAN的对象，这种方式的内存相对较高，存在后续优化的必要。在现有APP的内存老年区大小约为1.2G，而各种缓存数据合计已经超过700M，主要组成部分是特殊名单和免打扰用户缓存，超过600M。 2、 业务量增长是造成故障的客观触发原因：据统计，特殊名单客户、免打扰用户数量持续增加，两类客户数据长时间处于连续上升趋势，近半年来更是每月净增数万（详细参见附录）。为保持客服的正常接续速度，这部分数据每天凌晨均会以缓存的形式自动刷新到APP内存,以上两个因素的结合，最终导致故障发生。 3、 JDK的垃圾回收机制问题较为底层，本地开发、测试、维护人员控制力较弱:该问题较为底层涉及到JDK的垃圾回收机制，本地开发、测试、维护人员能力不足，是本次故障未能及时准确定位，造成故障时间长的主要原因。现场开发、测试团队基本没有JDK方面的专家，运维团队仅系统室环境组对JDK底层机制有一定了解，在团队整体能力、故障预案储备、定位手段SD201312276833 8:15 8:32 客服业务 问题单号 恢复时间 （系统） 恢复时间 （业务） 故障影响业务 PM201312275561 12:22 12:22 客服系统相关业务 故障起因简述 浙江移动业务支撑中心第24页