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

浙江移动通信有限责任公司业务支撑中心十二月份故障分析报告（12月01日-12月31日）1、关于12月4日客服部分座席多次出现被突然签出的故障（蓝）故障标题故障简明回顾说明故障现象故障原因故障标准恢复情况改进措施1、故障详细分析故障现象详细描述事件单号问题单号开始时间（系统）15:10恢复时间（系统）16:06开始时间（业务）15:10恢复时间（业务）16:06故障影响系统故障影响业务故障处理情况故障起因详述故障处理回顾1.处理后效果/遗留问题说明无是否影响集团考核否故障原因是否已在故障池内否运维故障评估故障根源系统客服系统严重程度重大严重主要一般系统开发商亚信联创故障待改进点涉及科室应用优化室（运行异常）统一权限配置配置管理客户响应室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室统一产品配置配置管理计费帐务室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室基础设施基础保障系统优化室系统能力(架构、容量)问题业支系统系统规划室经分系统经营分析室信安系统信息安全室软件质量业支系统需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室经分系统经营分析室信安系统信息安全室电渠系统客服中心电渠运维故障分析1）告警监控管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）高可用保障管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）运维操作管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）系统基础平台问题【原因分析】【改进措施】规范执行 重复问题 历史遗留问题故障后续改进故障所属域（CRM/BOSS/渠道）优化需求优化需求编号需求开发责任人需求维护跟踪人BR2014010631 系统优化室-关于客服业务系统便签发送的优化需求石永超钟储建告警监控告警调整版本号告警调整任务单号告警调整人故障预案预案名称新增/修改预案编写人高可用保障优化分析报告名新增/修改报告撰写人数据稽核数据稽核任务任务单号稽核人疑难问题专题名称专题需要的资源专题发起人改进措施落实情况运维报告撰写人钟储建，刘鹏改进措施落实监督人陈航开发故障评估故障责任小组开发故障分析故障引入需求编号和名称故障影响范围故障原因综述故障详细分析及问题解决故障解决措施改进措施（问题避免）1）需求因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）系统设计因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）软件编码因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）自测因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题开发改进措施落实情况开发报告撰写人开发改进措施落实监督人测试故障评估故障责任小组测试故障分析1）功能测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）回归测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）性能容量测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）安全性测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题5）编译因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题6）上线因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题改进措施落实情况测试报告撰写人测试改进措施落实监督人2、关于12月8日金华用户反映通过社会渠道系统充值话费未到帐的故障（蓝）故障标题关于12月8日金华用户反映通过社会渠道系统等充值话费未到帐的故障（蓝）故障简明回顾说明故障现象1、金华地区反馈通过社会渠道进行充值后，资金不能及时到账；2、部分用户反映通过积分兑换的资金也没有到账。故障原因8号当天由于日帐单表没有及时进行表分析，维护进行多次重启查询代理，导致金华地区充值入账本处理程序scoket 连接出现异常，连接查询代理失败率高，最终引发充值入账本工单积压，用户充值没有及时入账。故障标准投诉量（5，30，咨询数（30，300恢复情况重启查询代理后恢复正常。改进措施1、 运维监控能力优化：增加充值入账本程序连接查询代理失败的错误信息的监控，能够避免故障的发生；2、 梳理完善充值预案：梳理外围系统（如充值接口）的框架和相应的处理环节，对充值未到账建立详细的处理预案，针对充值未到账的问题能够及时快速的处理，缩短故障恢复时间。3、 查询代理架构优化：查询代理作为连接外围系统和实时帐务的枢纽，需要进行框架优化，具备对外围吞吐量、调用来源、成功失败数、错误类型、关键业务耗时进行有效记录，并且能够通过运维平台展现，最终达到可监可控，可视可分析。故障详细分析故障现象详细描述客服报障，反映金华地区反馈通过社会渠道进行充值后，资金未及时到账；部分用户反映通过积分兑换的资金也没有到账。通过对外围接口比对和充值后台处理步骤的核实，发现充值入账本处理程序scoket 连接有问题，入账本工单积压，用户充值不能及时到账。事件单号SD201312087506问题单号PM201312085443开始时间（系统）14：30恢复时间（系统）19:50开始时间（业务）17:00恢复时间（业务）19:50故障影响系统账务管理系统故障影响业务充值业务故障处理情况故障起因简述1、 12月8号话费增量查询手工关闭，接到客服中心要求对话费日增量查询菜单开启，后台开启查询并重启查询代理，并发现查询超时，对重新关闭日增量查询菜单并重启了查询代理；2、 故障发生以后，通过后台日志分析，从14:30开始，充值入账本的日志就开始出现大量的连接MDB出错的信息，提示连接错误，系统设置了重复连接3次的配置，充值入账本处理失败率升高，导致充值工单入账本一直积压，入账本超时，外围用户充值入账本超时；3、 19:28 接到客服反映用户充值未到账的，通过分析发现为入账本程序连接socket有问题，通过重启查询代理，故障恢复。故障处理回顾1、19:28 接到客服关于金华地区部分用户充值未到账以及通过积分兑换的资金也没有到账的报障；2、19:40 维护人员通过后台日志核实为充值工单处理入账本积压，导致入账本超时，不能正常的入账本；3、19:50 根据故障标准，由于关联投诉达到300个用户，按照故障等级升为蓝；4、19:55 重启查询代理后，所有入账本的积压工单在2分钟内完成了入账本处理，充值未到帐的问题得以恢复。处理后效果/遗留问题说明无是否影响集团考核否故障原因是否已在故障池内否运维故障评估故障根源系统严重程度重大严重主要一般系统开发商亚信故障待改进点涉及科室应用优化室（运行异常）统一权限配置配置管理客户响应室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室统一产品配置配置管理计费帐务室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室基础设施基础保障系统优化室系统能力(架构、容量)问题业支系统系统规划室经分系统经营分析室信安系统信息安全室软件质量业支系统需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室经分系统经营分析室信安系统信息安全室电渠系统客服中心电渠运维故障分析1）告警监控管理【原因分析】充值工单入账本Am_ps_payment_fast_nnn 表积压，告警系统没有生成相应告警信息。【改进措施】规范执行 重复问题 历史遗留问题核实告警配置不完善，已经协调告警维护人员重新部署入账本的监控。2）高可用保障管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）运维操作管理【原因分析】针对充值流程和各环节没有详细的分析，故障发生时维护人员对故障的定位不够准确，延缓了故障处理时长。【改进措施】规范执行 重复问题 历史遗留问题 梳理充值各环节的核查点，建立快速响应预案，能够及时处理故障。4）系统基础平台问题【原因分析】【改进措施】规范执行 重复问题 历史遗留问题故障后续改进故障所属域（CRM/BOSS/渠道）优化需求优化需求编号需求开发责任人需求维护跟踪人告警监控告警调整版本号告警调整任务单号告警调整人核实告警配置裴江华故障预案预案名称新增/修改预案编写人增加外围充值环节梳理章清云高可用保障优化分析报告名新增/修改报告撰写人数据稽核数据稽核任务任务单号稽核人疑难问题专题名称专题需要的资源专题发起人改进措施落实情况运维报告撰写人唐艳芬改进措施落实监督人蒋健开发故障评估故障责任小组开发故障分析故障引入需求编号和名称故障影响范围故障原因综述故障详细分析及问题解决故障解决措施改进措施（问题避免）1）需求因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）系统设计因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）软件编码因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）自测因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题开发改进措施落实情况开发报告撰写人开发改进措施落实监督人测试故障评估故障责任小组测试故障分析1）功能测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）回归测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）性能容量测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）安全性测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题5）编译因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题6）上线因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题改进措施落实情况测试报告撰写人测试改进措施落实监督人3、关于12月26日部分地市社会渠道客户关系管理系统登陆异常故障（黄）故障标题关于12月26日部分地市社会渠道客户关系管理系统登陆异常的故障（黄）故障简明回顾说明故障现象第一次故障：8:35分，全省代理点反映客户关系管理首页平台无法登录，无法进行业务受理和充值。 8:38 通知代理点直接通过社会渠道三个源IP访问后能正常访问。9:05分，网宿（CDN内容发布运营商）将渠道电信域名解析到源站地址5，电信用户反馈业务暂时恢复。（蓝） 第二次故障：9:53分，网管中心将割接的社会渠道、终端、CRM新渠道域名全部回退后，部分访问社会渠道、终端、CRM新渠道页面会跳转到错误页面，DNS域名解析到未知的IP；10:30,维护人员联系网管中心将社会渠道、终端、CRM新渠道域名别名记录到网宿，在网宿端将社会渠道、终端、CRM新渠道全部域名解析到源站地址；11:40，业务恢复正常。（黄）故障原因第一次故障：由于割接当晚进行社会渠道、终端、CRM新渠道系统的CDN迁移，各平台业务通过CDN缓存加速。在CDN平台迁移过程中，网宿没有配置SSL证书，造成社会渠道的https访问无法打开。第二次故障：在社会渠道、终端、CRM新渠道系统的域名回退过程中，域名被电信劫持解析成未知的IP，页面被跳转到广告页面，造成社会渠道、终端、CRM新渠道系统无法访问。故障标准重要业务2，涉及(3,6个地市或(50%,70%坐席，影响时间持续(15,30分钟；恢复情况第一次故障：8:38 通知代理点直接通过社会渠道三个源IP访问后能正常访问。9:05分，网宿将渠道电信域名解析到源站地址5，电信用户反馈业务暂时恢复。第二次故障：10:30,维护人员联系网管中心将社会渠道、终端、CRM新渠道域名别名记录到网宿，在网宿端将社会渠道、终端、CRM新渠道全部域名解析到源站地址；11:40，社会渠道、终端、CRM新渠道的域名解析到源站IP，业务恢复正常。改进措施1、 完善CDN割接测试手段：对于修改公网DNS配置的操作,需要考虑全局DNS缓存问题以及配置生效时间。2、 完善CDN割接应急预案：在割接后，确保我方故障时运维人员能进行快速切换，提供HTTPS证书,导入网宿CDN服务器，并对于远程操作的厂家，要求第二天能够有效响应。3、 考虑进行DNS 区域迁移：将zj.chinamobile区域迁移到DCN本地DNS，减少配置的复杂度并有效的管理，在进行配置迁移时快速的响应，减少故障发生的时间。（可行性进一步跟网管讨论）故障详细分析故障现象详细描述第一次故障：8:35分，全省代理点反映客户关系管理首页平台无法登录，无法进行业务受理和充值。 8:38 通知代理点直接通过社会渠道三个源IP访问后能正常访问。9:05分，网宿将渠道电信域名解析到源站地址5，电信用户反馈业务暂时恢复。（蓝） 第二次故障：9:53分，网管中心将割接的社会渠道、终端、CRM新渠道域名全部回退后，部分访问社会渠道、终端、CRM新渠道页面会跳转到错误页面，DNS域名解析到未知的IP；10:30,维护人员联系网管中心将社会渠道、终端、CRM新渠道域名别名记录到网宿，在网宿端将社会渠道、终端、CRM新渠道全部域名解析到源站地址；11:40，业务恢复正常。（黄）事件单号SD201312265953SD201312265857问题单号PM201312265546PM201312265547开始时间（系统）第一次故障：8:35第二次故障：9:53恢复时间（系统）第一次故障：9:05 第二次故障：11:40开始时间（业务）第一次故障：8:35第二次故障：9:53恢复时间（业务）第一次故障：9:05 第二次故障：11:40故障影响系统社会渠道（新）、社会渠道（旧）、终端管理系统故障影响业务社会渠道系统业务办理终端管理系统业务处理故障处理情况故障起因简述第一次故障：由于割接当晚进行社会渠道、终端、CRM新渠道系统的CDN迁移，各平台业务通过CDN缓存加速。在CDN平台迁移过程中，网宿没有配置SSL证书，造成社会渠道的https访问无法打开。第二次故障：在社会渠道、终端、CRM新渠道系统的域名回退过程中，DNS同步问题造成域名解析到未知的IP，页面被跳转到广告页面，造成社会渠道、终端、CRM新渠道系统无法访问。故障处理回顾故障处理过程1、 8:35 应用反馈全省社会渠道管理平台无法登录。2、 8:36 网络组测试(CMCC链路)社会渠道, 终端系统、CRM新渠道系统均解析到CDN地址。社会渠道管理平台通过IP能正常访问，通过域名访问失败。终端系统、CRM新渠道通过IP和域名都能正常访问。判断为CDN的问题，后经和网宿沟通确认，社会渠道为https应用，因网宿没有导入相应的渠道证书，导致应用无法访问。终端系统、CRM新渠道系统为http应用，页面访问正常。3、 8:38 通知代理点直接通过社会渠道三个源IP访问，业务恢复正常。但因渠道系统代理点众多，部分通过域名访问平台的用户仍旧无法访问。4、 8:40 联系网管中心进行DNS配置回退，但未联系上厂家。 5、 8:42联系CDN进行社会渠道域名回退，将渠道三个域名指向具体的源站IP，但CDN厂家误认为受影响业务只有社会渠道电信域名，在修改DNS配置时只将社会渠道电信域名A记录指向到源站IP 5,另外二个社会渠道域名未进行源站IP切换。DNS部署和同步时间超过20分钟。6、 9:05 CMCC测试DNS解析电信域名到源站IP，业务访问正常。但移动和网通域名DNS解析仍然为CDN CNAME记录，业务无法正常访问。部分代理商反馈业务正常。7、 9:10 因仍有部分用户业务未恢复，网络组要求网宿将渠道三个域名NS记录到DCN 智能DNS服务器（4和4）做转发，网宿反馈无法配置NS记录，只能配置A记录。这过程部署和同步时间超过30分钟。8、 9:40 CDN配置生效后，部分用户通过域名访问社会渠道页面仍然无法打开。9、 9:50 联系网管中心回退社会渠道、终端、CRM新渠道域名的配置，删除网管DNS相应的CNAME 记录，增加指向智能DNS服务器的NS记录。DNS同步时间超过40分钟。10、 9:50-10:30 在DNS配置同步过程中，维护人员页面发现访问社会渠道、终端、CRM新渠道网站会跳转到广告页面，DNS解析社会渠道域名会解析到未知IP，出现DNS劫持。11、 10:40 联系电信公司，反馈DNS被劫持的情况。12、 10:40 因网管中心全局DNS NS记录同步比较慢(同步周期2小时)，维护人员联系网管中心删除社会渠道、终端、CRM新渠道域名的NS记录，并将域名NS记录修改成网宿提供的CNAME记录，DNS配置同步时间30分钟。13、 11:10 在DNS配置同步过程中，测试终端、CRM新渠道业务在11:10页面恢复，但社会渠道业务仍然未恢复。14、 11:15 测试发现网宿误将社会渠道三个域名A记录到DCN智能DNS接口地址4和4，而非真实的源站IP。15、 11:20 联系网宿将社会渠道三个域名正确解析到A记录源站地址。DNS同步时间20分钟。16、 11:40 DNS同步完成，绝大部分社会渠道业务恢复正常，个别用户由于本地DNS同步刷新时间不同步，导致平台无法访问，已经通过IP地址访问和手工修改本地DNS为的方式解决。处理后效果/遗留问题说明是否影响集团考核否故障原因是否已在故障池内否运维故障评估故障根源系统严重程度重大严重主要一般系统开发商亚联故障待改进点涉及科室应用优化室（运行异常）统一权限配置配置管理客户响应室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室统一产品配置配置管理计费帐务室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室基础设施基础保障系统优化室系统能力(架构、容量)问题业支系统系统规划室经分系统经营分析室信安系统信息安全室软件质量业支系统需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室经分系统经营分析室信安系统信息安全室电渠系统客服中心电渠运维故障分析1）告警监控管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）高可用保障管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）运维操作管理【原因分析】应急回退操作需要网管和CDN侧来操作，处理故障时长不可控。【改进措施】规范执行 重复问题 历史遗留问题4）系统基础平台问题【原因分析】【改进措施】规范执行 重复问题 历史遗留问题故障后续改进故障所属域（CRM/BOSS/渠道）优化需求优化需求编号需求开发责任人需求维护跟踪人告警监控告警调整版本号告警调整任务单号告警调整人故障预案预案名称新增/修改预案编写人高可用保障优化分析报告名新增/修改报告撰写人数据稽核数据稽核任务任务单号稽核人疑难问题专题名称专题需要的资源专题发起人改进措施落实情况1、 已提供渠道证书,网宿已完成配置修改，测试通过2、 完善割接测试方案，割接后由运维人员和应用人员共同确认业 务系统可操作，要求网宿提供完整的测试报告3、 确保第二天现场的保障人员能快速进行配置回退和业务验证。运维报告撰写人吴天东，陈挺改进措施落实监督人陈航开发故障评估故障责任小组开发故障分析故障引入需求编号和名称故障影响范围故障原因综述故障详细分析及问题解决故障解决措施改进措施（问题避免）1）需求因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）系统设计因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）软件编码因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）自测因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题开发改进措施落实情况开发报告撰写人开发改进措施落实监督人测试故障评估故障责任小组测试故障分析1）功能测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）回归测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）性能容量测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）安全性测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题5）编译因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题6）上线因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题改进措施落实情况测试报告撰写人测试改进措施落实监督人4、关于12月27日部分地市用户充值后余额提醒短信与实际不符的故障（蓝）故障标题关于12月27日部分地市用户充值后余额提醒短信与实际不符的故障（蓝）故障简明回顾说明故障现象12月27日12点59分，接到客服的报障，反映用户充值后收到短信提醒余额与实际不符，投诉量大于300，判定为蓝色故障故障原因1、 查询优化项目对查询代理异常重试5次的机制进行调整，是此次故障的直接原因：实时计费项目为减少查询代理负荷，并加强调用日志梳理管控，剔除原查询失败重试五次的机制，由于未考虑查询代理先前错误配置情况，从而导致异常情况被扩大化，最终出现外围调用无返回，加上外围调用组装机制不合理，最终导致用户费用显示不准确。2、 查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一：查询代理外围客户端配置存在历史错误，实时账务上线以后对外围调用的配置文件进行了调整，忽略了上述CRM批量和帐管批量配置信息。但由于外围查询有相应错误处理机制，遇失败后进行端口轮询5次重试，若调用上塘主机查询失败后，会轮询调用滨江的查询代理，因此该错误一直未显现。3、 帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之一：本次故障的帐管充值短信下发模块，充值后需要查询实时账单进行模拟销账，获取用户余额进行下发用户，但当调用查询代理实时账单查询失败时，程序会自动按照实时账单为0来进行模拟销账，会导致计算得到的余额虚高，从而下发短信造成用户误解。故障标准非重要业务1，涉及大于3个地市或大于50%坐席，影响时间持续(30,60分钟；恢复情况通过维护和开发最终定位，确定是查询代理优化需求上线造成部分外围实时账单查询接口调用异常，最终导致下发用户提醒短信不准确。通过调整查询代理客户端配置信息，并且紧急修复代码最终恢复改进措施1. 完善外围查询接入管控，明确接口规范针对本次故障，首先对帐管充值下发短信生成异常处理机制进行优化，对外围应用调用其相关接口，需加强接入管控，明确接口规范，确保外围异常查询处理逻辑可靠，必须具备容错处理。2. 完善查询代理架构查询代理作为连接外围系统和实时帐务的枢纽，需要进行框架优化，具备对外围吞吐量、调用来源、成功失败数、错误类型、关键业务耗时进行有效记录，并且能够通过运维平台展现，最终达到可监可控，可视可分析。3. 梳理查询代理异常场景，加强开发人员对于账务后台框架的培训在BOSS账务开发组内进行BOSS后台框架应用开发规范的培训，针对查询代理返回错误的场景进行梳理，明确哪些错误是可以不进行5次尝试，哪些错误是需要用5次尝试来保证的。4. 明确管理职责明确系统优化室环境组为环境配置文件的责任部门，应用优化室优化组为业务配置文件的责任部门，杜绝类似配置文件历史措施的再次发生故障详细分析故障现象详细描述用户充值后收到了充值提醒短信，充值提醒短信中的余额与用户实际的余额不符，由于查询实时费用超时返回为0，导致短信中的余额=用户充值之后账本余额，而实际余额=用户充值后的账本余额-用户实时费用，即提醒短信中的余额虚高。事件单号SD201312276938问题单号PM201312275564开始时间（系统）12月27日12:59恢复时间（系统）12月28日20:00开始时间（业务）12月27日12:59恢复时间（业务）12月28日20:10故障影响系统帐管系统查询实时费用，批量业务查询用户实时费用故障影响业务充值下发短信故障处理情况故障起因简述n 查询优化项目对查询代理异常时重试5次的机制进行调整，是此次故障的直接原因在实时计费、按量计费项目过程中，一方面为有效减少查询代理负荷，并且进一步减少帐务后台压力，确保实时计费用户加载能够按时完成；一方面为有效加强查询代理调用错误日志梳理管控（要求将查询代理的调用错误日志按类型、端口入库，如果将每次重试的量也入库，会导致统计的日志不准确），项目组决定对原有调用查询代理异常时重试5次的机制进行优化，在后台服务会持续异常的场景下，如无来源标记、数据异常、计算服务异常、路由关系不存在等场景下将重试5次的机制删除，但是一来未考虑到查询代理的配置原因，二来在设计的时候，场景未考虑充分，从而导致异常情况被扩大化，最终出现外围调用无返回，加上外围调用组装机制不合理，最终导致用户费用显示不准确。n 查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一查询代理是连接外围系统和实时帐务核心系统之间的纽带，外围系统通过查询代理进行资金、余额、账单查询。查询代理目前部署架构是2台主机（上塘和滨江主机，各20个进程，每台主机对外提供3个端口供外围调用），而外围主要是CRM系统（网厅、IVR、短厅、帐管等）通过不同的接口调用，配置文件perties配置查询代理调用的域名和端口，此文件分为CRM APP、CRM批量和帐管批量三份。2012年实时帐务二期进行查询代理改造后，期间对查询代理连接进行优化调整，相应外围客户端的调用配置信息也进行调整，但却忽略了上述CRM批量和帐管批量配置信息调整，最终导致外围CRM批量和帐管批量调用上塘主机都会失败。但由于外围查询有相应错误处理机制，遇失败后进行端口轮询5次重试，若调用上塘主机查询失败后，会轮询调用滨江的查询代理，因此该错误一直未显现。n 帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之一。查询代理外围客户端众多，包括网厅、信息推送平台、华为IVR、短厅/掌厅、自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在调用查询代理异常处理机制不一，存在不完善的地方，例如本次故障的帐管充值短信下发模块，充值后需要查询实时账单进行模拟销账，获取用户余额进行下发用户，但当调用查询代理实时账单查询失败时，程序会自动按照实时账单为0来进行模拟销账，会导致计算得到的余额虚高，从而下发短信造成用户误解。故障处理回顾12月27日：12:59 总控台短信：【灰】充值提醒短信与实际余额不符；13:00 维护、账务开发、查询代理相关开发人员通过排查核实，发现充值入账日志连MDB错误量很多,比25日多很多，即使只计算一小时的量也不是一个量级（故障当天1小时有上万条报错，平时只有百来条）；13:30为避免故障升级，维护侧通知华为关闭充值提醒短信；14:30 开发确认前一晚上线的优化需求，关闭了外围查询失败重试5次的机制，改为一次；15:40总控台短信：【蓝】超60分钟，升蓝；23:00 紧急上线查询代理外围客户端（包括CRM，帐管）调用查询失败恢复重试5次的功能。12月28日：8:10 维护第二天上线跟踪发现问题依然存在，通知开发立即到现场，核实发现27日紧急上线的程序只发布了CRM EJB集群主机，营帐批量后台进程主机未发布，导致问题依然存在。10:00 再次进行故障仔细排查，最终确认故障原因是由于CRM系统中调用查询代理的配置错误，存在一定概率单次调用失败，并且此次上线取消了5次重试，从而导致外围调用查询代理错误，最终返回用户错误余额信息。13:30 紧急修复CRM系统查询代理配置文件，并对遗漏发布的营帐批量后台程序进行补发布，通过重启相关进程后生成的充值短信恢复正常。13:30 由于27日为避免故障影响范围扩大，处理过程中通过删除统一短信平台的相关模板而不进行下发，28日晚通过恢复短信模板，并重启统一短信平台后恢复。处理后效果/遗留问题说明是否影响集团考核否故障原因是否已在故障池内否运维故障评估故障根源系统CRM系统严重程度重大严重主要一般系统开发商亚联故障待改进点涉及科室应用优化室（运行异常）统一权限配置配置管理客户响应室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室统一产品配置配置管理计费帐务室软件质量需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室基础设施基础保障系统优化室系统能力(架构、容量)问题业支系统系统规划室经分系统经营分析室信安系统信息安全室软件质量业支系统需求管理业务管理室缺陷管理业务管理室架构管理系统规划室测试管理开发管理室经分系统经营分析室信安系统信息安全室电渠系统客服中心电渠运维故障分析1）告警监控管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）高可用保障管理【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）运维操作管理【原因分析】历史配置文件配置导致查询失败率高【改进措施】规范执行 重复问题 历史遗留问题1、 明确系统优化室环境组为环境配置文件的责任人，应用优化室优化组为业务配置文件的责任人，防止类似配置文件历史措施的再次发生；2、 针对本次查询代理无返回的异常情况处理，需要梳理排查，尤其是涉及到资金相关、调用量大、影响面广的渠道，需要优先进行核实。同时，查询代理还存在另一风险隐患，由于外围对查询代理返回错误代码无法处理，因而查询代理约定出错情况将返回0，该问题同样存在隐患，后续需要协调外围渠道彻底改造。4）系统基础平台问题【原因分析】【改进措施】规范执行 重复问题 历史遗留问题故障后续改进故障所属域（CRM/BOSS/渠道）优化需求优化需求编号需求开发责任人需求维护跟踪人告警监控告警调整版本号告警调整任务单号告警调整人故障预案预案名称新增/修改预案编写人高可用保障优化分析报告名新增/修改报告撰写人数据稽核数据稽核任务任务单号稽核人疑难问题专题名称专题需要的资源专题发起人改进措施落实情况运维报告撰写人唐艳芬，朱建波改进措施落实监督人蒋健开发故障评估故障责任小组开发故障分析故障引入需求编号和名称历史原因故障影响范围全省故障原因综述查询代理优化需求上线造成部分外围实时账单查询接口调用异常，最终导致下发用户提醒短信提醒余额与实际不符。通过调整查询代理客户端配置信息，并且紧急修复代码最终恢复。故障详细分析及问题解决1、查询优化项目对查询代理异常时重试5次的机制进行调整，是此次故障的直接原因。在实时计费、按量计费项目过程中，一方面为有效减少查询代理负荷，并且进一步减少帐务后台压力，确保实时计费用户加载能够按时完成；一方面为有效加强查询代理调用错误日志梳理管控（要求将查询代理的调用错误日志按类型、端口入库，如果将每次重试的量也入库，会导致统计的日志不准确），项目组决定对原有调用查询代理异常时重试5次的机制进行优化，在后台服务会持续异常的场景下，如无来源标记、数据异常、计算服务异常、路由关系不存在等场景下将重试5次的机制删除，但是一来未考虑到查询代理的配置原因，二来在设计的时候，场景未考虑充分，从而导致异常情况被扩大化，最终出现外围调用无返回，加上外围调用组装机制不合理，最终导致用户费用显示不准确。2、查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一。查询代理是连接外围系统和实时帐务核心系统之间的纽带，外围系统通过查询代理进行资金、余额、账单查询。查询代理目前部署架构是2台主机（上塘和滨江主机，各20个进程，每台主机对外提供3个端口供外围调用），而外围主要是CRM系统（网厅、IVR、短厅、帐管等）通过不同的接口调用，配置文件perties配置查询代理调用的域名和端口，此文件分为CRM APP、CRM批量和帐管批量三份。2012年实时帐务二期进行查询代理改造后，期间对查询代理连接进行优化调整，相应外围客户端的调用配置信息也进行调整，但却忽略了上述CRM批量和帐管批量配置信息调整，最终导致外围CRM批量和帐管批量调用上塘主机都会失败。但由于外围查询有相应错误处理机制，遇失败后进行端口轮询5次重试，若调用上塘主机查询失败后，会轮询调用滨江的查询代理，因此该错误一直未显现。3、帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之一。查询代理外围客户端众多，包括网厅、信息推送平台、华为IVR、短厅/掌厅、自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在调用查询代理异常处理机制不一，存在不完善的地方，例如本次故障的帐管充值短信下发模块，充值后需要查询实时账单进行模拟销账，获取用户余额进行下发用户，但当调用查询代理实时账单查询失败时，程序会自动按照实时账单为0来进行模拟销账，会导致计算得到的余额虚高，从而下发短信造成用户误解。故障解决措施1、完善外围查询接入管控，明确接口规范。针对本次故障，首先对帐管充值下发短信生成异常处理机制进行优化，如果查询实时账单接口返回有问题，则不生成下发短信，从而防止用户收到不准确的余额短信。此外，查询代理作为服务端，外围应用调用其相关接口，需加强接入管控，明确接口规范，确保外围异常查询处理逻辑可靠，必须具备容错处理，针对本次查询代理无返回的异常情况处理，需要梳理排查，尤其是涉及到资金相关、调用量大、影响面广的渠道，需要优先进行核实。同时，查询代理还存在另一风险隐患，由于外围对查询代理返回错误代码无法处理，因而查询代理约定出错情况将返回0，该问题同样存在隐患，后续需要协调外围渠道彻底改造。2、完善查询代理架构。查询代理作为连接外围系统和实时帐务的枢纽，需要进行框架优化，具备对外围吞吐量、调用来源、成功失败数、错误类型、关键业务耗时进行有效记录，并且能够通过运维平台展现，最终达到可监可控，可视可分析。3、梳理查询代理异常场景，加强开发人员对于账务后台框架的培训。在BOSS账务开发组内进行BOSS后台框架应用开发规范的培训，针对查询代理返回错误的场景进行梳理，明确哪些错误是可以不进行5次尝试，哪些错误是需要用5次尝试来保证的。改进措施（问题避免）1）需求因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）系统设计因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）软件编码因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）自测因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题开发改进措施落实情况开发报告撰写人王涛开发改进措施落实监督人王涛测试故障评估故障责任小组测试故障分析1）功能测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题2）回归测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题3）性能容量测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题4）安全性测试因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题5）编译因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题6）上线因素分析及改进【原因分析】【改进措施】规范执行 重复问题 历史遗留问题改进措施落实情况测试报告撰写人测试改进措施落实监督人5、关于12月27日客服平台系统运行缓慢的故障（红）故障标题关于12月27日客服平台出现系统运行缓慢的故障（红）故障简明回顾说明故障现象12月27日8点32分，接到客服报障，反映客服平台出现运行缓慢的现象。故障原因由于对缓存数据缺乏控制手段，随着免打扰用户、特殊名单配置的逐步增加，占用大量内存导致App内存不足，引发 APP频繁进行老年代内存回收（FULL GC），从而导致系统响应缓慢。故障标准重要业务，涉及(1,3个地市或(20%,50%坐席，影响时间持续(60,180分钟；恢复情况通过调整客服业务APP实例内存参数，由原先2G增加至3G，最终重启APP后恢复故障。改进措施1、开发质量优化（1）优化特殊名单的缓存、免打扰用户的缓存。采用JAVA BEAN替代BO BEAN，并只缓存有用的部分字段，可以有效减少缓存内存的不必要占用。（已提交优化需求，BR2014010631 系统优化室-关于客服业务系统便签发送的优化需求，BR2014010214 优化客服系统特殊名单表、免打扰用户表查询方式的需求）2、维护手段优化（1）目前的监控无法及时定位FULL GC占用时间长的场景，拟结合FULL GC次数和时间，设计和部署新的监控点，可有效提升该问题的及时发现和规避率。（2）针对核心业务，研究压力测试技术方案，在测试环境和生