故障报告
-
2023年2月28日发(作者：大秦赋下载)浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第1页
十二月份故障分析报告（12月01日-12月31日）
1、关于12月4日客服部分座席多次出现被突然签出的故障（蓝）
故障标题
故障简明回顾说明
故障现象
故障原因
故障标准
恢复情况
改进措施
1、
故障详细分析
故障现象
详细描述
事件单号问题单号
开始时间
（系统）
15:10
恢复时间
（系统）
16:06
开始时间
（业务）
15:10
恢复时间
（业务）
16:06
故障影响
系统
故障影响业务
故障处理情况
故障起因
详述
故障处理
回顾
1.
处理后效
果/遗留问
题说明
无
是否影响
集团考核
否
故障原因
是否已在
故障池内
否
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第2页
运维故障评估
故障
根源系统
客服系统严重程度
□重大
□严重
□主要
■一般
系统
开发商
亚信联创
故障待改
进点涉及
科室
■应用优化室
（运行异常）
统一权限配置
配置管理□客户响应室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
统一产品配置
配置管理□计费帐务室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
基础设施
基础保障■系统优化室
系统能力(架
构、容量)问题
业支系统□系统规划室
经分系统□经营分析室
信安系统□信息安全室
软件质量
业支系统
需求管理□业务管理室
缺陷管理■业务管理室
架构管理□系统规划室
测试管理■开发管理室
经分系统□经营分析室
信安系统□信息安全室
电渠系统□客服中心电渠
运维故障分析
1）告警
监控管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）高可用
保障管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）运维
操作管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）系统
基础平台
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第3页
问题【改进措施】□规范执行□重复问题□历史遗留问题
故障后续改进
故障所属域（CRM/BOSS/渠道）
优化需求
优化需求编号需求开发责任人需求维护跟踪人
BR2014010631系统优化
室-关于客服业务系统便签
发送的优化需求
石永超钟储建
告警监控
告警调整版本号告警调整任务单号告警调整人
故障预案
预案名称新增/修改预案编写人
高可用保
障
优化分析报告名新增/修改报告撰写人
数据稽核
数据稽核任务任务单号稽核人
疑难问题
专题名称专题需要的资源专题发起人
改进措施落实情况
➢
运维报告
撰写人
钟储建，刘鹏改进措施落实监督人陈航
开发故障评估
故障责任
小组
开发故障分析
故障引入
需求编号
和名称
故障影响范围
故障原因
综述
故障详细
分析及问
题解决
故障解决
措施
改进措施（问题避免）
1）需求因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第4页
2）系统设
计因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）软件编
码因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）自测因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
开发改进措施落实情况
➢
开发报告
撰写人
开发改进措施
落实监督人
测试故障评估
故障责任
小组
测试故障分析
1）功能测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）回归测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）性能容
量测试因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）安全性
测试因素
分析及改
进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
5）编译因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
6）上线因
素分析及
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第5页
改进【改进措施】□规范执行□重复问题□历史遗留问题
改进措施落实情况
➢
测试报告
撰写人
测试改进措施
落实监督人
2、关于12月8日金华用户反映通过社会渠道系统充值话费未到帐的故障（蓝）
故障标题关于12月8日金华用户反映通过社会渠道系统等充值话费未到帐的故障（蓝）
故障简明回顾说明
故障现象
1、金华地区反馈通过社会渠道进行充值后，资金不能及时到账；
2、部分用户反映通过积分兑换的资金也没有到账。
故障原因
8号当天由于日帐单表没有及时进行表分析，维护进行多次重启查询代理，导
致金华地区充值入账本处理程序scoket连接出现异常，连接查询代理失败率
高，最终引发充值入账本工单积压，用户充值没有及时入账。
故障标准投诉量（5，30]，咨询数（30，300]
恢复情况重启查询代理后恢复正常。
改进措施
1、运维监控能力优化：增加充值入账本程序连接查询代理失败的错误信息的
监控，能够避免故障的发生；
2、梳理完善充值预案：梳理外围系统（如充值接口）的框架和相应的处理环
节，对充值未到账建立详细的处理预案，针对充值未到账的问题能够及时
快速的处理，缩短故障恢复时间。
3、查询代理架构优化：查询代理作为连接外围系统和实时帐务的枢纽，需要
进行框架优化，具备对外围吞吐量、调用来源、成功失败数、错误类型、
关键业务耗时进行有效记录，并且能够通过运维平台展现，最终达到可监
可控，可视可分析。
故障详细分析
故障现象
详细描述
客服报障，反映金华地区反馈通过社会渠道进行充值后，资金未及时到账；部
分用户反映通过积分兑换的资金也没有到账。通过对外围接口比对和充值后台
处理步骤的核实，发现充值入账本处理程序scoket连接有问题，入账本工单
积压，用户充值不能及时到账。
事件单号SD2问题单号PM2
开始时间
（系统）
14：30
恢复时间
（系统）
19:50
开始时间
（业务）
17:00
恢复时间
（业务）
19:50
故障影响
系统
账务管理系统故障影响业务充值业务
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第6页
故障处理情况
故障起因
简述
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分钟内完成了入账本处
理，充值未到帐的问题得以恢复。
处理后效
果/遗留问
题说明
无
是否影响
集团考核
否
故障原因
是否已在
故障池内
否
运维故障评估
故障
根源系统
严重程度
□重大
□严重
□主要
■一般
系统
开发商
亚信
故障待改
进点涉及
科室
■应用优化室
（运行异常）
统一权限配置
配置管理□客户响应室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
统一产品配置
配置管理□计费帐务室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
基础设施
基础保障□系统优化室
系统能力(架
构、容量)问题
业支系统□系统规划室
经分系统□经营分析室
信安系统□信息安全室
软件质量业支系统
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第7页
测试管理□开发管理室
经分系统□经营分析室
信安系统□信息安全室
电渠系统□客服中心电渠
运维故障分析
1）告警
监控管理
【原因分析】
充值工单入账本Am_ps_payment_fast_nnn表积压，告警系统没有生成相应告
警信息。
【改进措施】□规范执行□重复问题□历史遗留问题
核实告警配置不完善，已经协调告警维护人员重新部署入账本的监控。
2）高可用
保障管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）运维
操作管理
【原因分析】
针对充值流程和各环节没有详细的分析，故障发生时维护人员对故障的定位不
够准确，延缓了故障处理时长。
【改进措施】□规范执行□重复问题□历史遗留问题
梳理充值各环节的核查点，建立快速响应预案，能够及时处理故障。
4）系统
基础平台
问题
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
故障后续改进
故障所属域（CRM/BOSS/渠道）
优化需求
优化需求编号需求开发责任人需求维护跟踪人
告警监控
告警调整版本号告警调整任务单号告警调整人
核实告警配置裴江华
故障预案
预案名称新增/修改预案编写人
增加外围充值环节梳理章清云
高可用保
障
优化分析报告名新增/修改报告撰写人
数据稽核
数据稽核任务任务单号稽核人
疑难问题
专题名称专题需要的资源专题发起人
改进措施落实情况
➢
运维报告
撰写人
唐艳芬改进措施落实监督人蒋健
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第8页
开发故障评估
故障责任
小组
开发故障分析
故障引入
需求编号
和名称
故障影响范围
故障原因
综述
故障详细
分析及问
题解决
故障解决
措施
改进措施（问题避免）
1）需求因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）系统设
计因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）软件编
码因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）自测因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
开发改进措施落实情况
➢
开发报告
撰写人
开发改进措施
落实监督人
测试故障评估
故障责任
小组
测试故障分析
1）功能测
试因素分
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第9页
析及改进【改进措施】□规范执行□重复问题□历史遗留问题
2）回归测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）性能容
量测试因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）安全性
测试因素
分析及改
进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
5）编译因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
6）上线因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
改进措施落实情况
➢
测试报告
撰写人
测试改进措施
落实监督人
3、关于12月26日部分地市社会渠道客户关系管理系统登陆异常故障（黄）
故障标题关于12月26日部分地市社会渠道客户关系管理系统登陆异常的故障（黄）
故障简明回顾说明
故障现象
第一次故障：8:35分，全省代理点反映客户关系管理首页平台无法登录，无法
进行业务受理和充值。8:38通知代理点直接通过社会渠道三个源IP访问后
能正常访问。9:05分，网宿（CDN内容发布运营商）将渠道电信域名
解析到源站地址122.224.123.75，电信用户
反馈业务暂时恢复。（蓝）
第二次故障：9:53分，网管中心将割接的社会渠道、终端、CRM新渠道域名全
部回退后，部分访问社会渠道、终端、CRM新渠道页面会跳转到错误页面，DNS
域名解析到未知的IP；10:30,维护人员联系网管中心将社会渠道、终端、CRM
新渠道域名别名记录到网宿，在网宿端将社会渠道、终端、CRM新渠道全部域
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第10页
名解析到源站地址；11:40，业务恢复正常。（黄）
故障原因
第一次故障：由于割接当晚进行社会渠道、终端、CRM新渠道系统的CDN迁移，
各平台业务通过CDN缓存加速。在CDN平台迁移过程中，网宿没有配置SSL证
书，造成社会渠道的https访问无法打开。
第二次故障：在社会渠道、终端、CRM新渠道系统的域名回退过程中，域名被
电信劫持解析成未知的IP，页面被跳转到广告页面，造成社会渠道、终端、CRM
新渠道系统无法访问。
故障标准重要业务2，涉及(3,6]个地市或(50%,70%]坐席，影响时间持续(15,30]分钟；
恢复情况
第一次故障：8:38通知代理点直接通过社会渠道三个源IP访问后能正常访问。
9:05分，网宿将渠道电信域名解析到源站地
址122.224.123.75，电信用户反馈业务暂时恢复。
第二次故障：10:30,维护人员联系网管中心将社会渠道、终端、CRM新渠道域
名别名记录到网宿，在网宿端将社会渠道、终端、CRM新渠道全部域名解析到
源站地址；11:40，社会渠道、终端、CRM新渠道的域名解析到源站IP，业务
恢复正常。
改进措施
1、完善CDN割接测试手段：对于修改公网DNS配置的操作,需要考虑全局DNS
缓存问题以及配置生效时间。
2、完善CDN割接应急预案：在割接后，确保我方故障时运维人员能进行快速
切换，提供HTTPS证书,导入网宿CDN服务器，并对于远程操作的厂家，要
求第二天能够有效响应。
3、考虑进行DNS区域迁移：将obile区域迁移到DCN本地DNS
，减少配置的复杂度并有效的管理，在进行配置迁移时快速的响应，减少
故障发生的时间。（可行性进一步跟网管讨论）
故障详细分析
故障现象
详细描述
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第11页
第一次故障：8:35分，全省代理点反映客户关系管理首页平台无法登录，无法
进行业务受理和充值。8:38通知代理点直接通过社会渠道三个源IP访问后
能正常访问。9:05分，网宿将渠道电信域名
解析到源站地址122.224.123.75，电信用户反馈业务暂时恢复。（蓝）
第二次故障：9:53分，网管中心将割接的社会渠道、终端、CRM新渠道域名全
部回退后，部分访问社会渠道、终端、CRM新渠道页面会跳转到错误页面，DNS
域名解析到未知的IP；10:30,维护人员联系网管中心将社会渠道、终端、CRM
新渠道域名别名记录到网宿，在网宿端将社会渠道、终端、CRM新渠道全部域
名解析到源站地址；11:40，业务恢复正常。（黄）
事件单号
SD2
SD2
问题单号PM2
PM2
开始时间
（系统）
第一次故障：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新渠道系统均解
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第12页
析到CDN地址。社会渠道管理平台通过IP能正常访问，通过域名访问失
败。终端系统、CRM新渠道通过IP和域名都能正常访问。判断为CDN的问
题，后经和网宿沟通确认，社会渠道为https应用，因网宿没有导入相应
的渠道证书，导致应用无法访问。终端系统、CRM新渠道系统为http应用，
页面访问正常。
3、8:38通知代理点直接通过社会渠道三个源IP访问，业务恢复正常。但因
渠道系统代理点众多，部分通过域名访问平台的用户仍旧无法访问。
4、8:40联系网管中心进行DNS配置回退，但未联系上厂家。
5、8:42联系CDN进行社会渠道域名回退，将渠道三个域名指向具体的源站
IP，但CDN厂家误认为受影响业务只有社会渠道电信域名，在修改DNS配
置时只将社会渠道电信域名A记录指向到源站IP122.224.123.75,另外二
个社会渠道域名未进行源站IP切换。DNS部署和同步时间超过20分钟。
6、9:05CMCC测试DNS解析电信域名到源站IP，业务访问正常。但移动和网
通域名DNS解析仍然为CDNCNAME记录，业务无法正常访问。部分代理商
反馈业务正常。
7、9:10因仍有部分用户业务未恢复，网络组要求网宿将渠道三个域名NS记
录到DCN智能DNS服务器（211.138.127.44和122.224.123.74）做转发，
网宿反馈无法配置NS记录，只能配置A记录。这过程部署和同步时间超
过30分钟。
8、9:40CDN配置生效后，部分用户通过域名访问社会渠道页面仍然无法打
开。
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因网管中心全局DNSNS记录同步比较慢(同步周期2小时)，维护
人员联系网管中心删除社会渠道、终端、CRM新渠道域名的NS记录，并将
域名NS记录修改成网宿提供的CNAME记录，DNS配置同步时间30分钟。
13、11:10在DNS配置同步过程中，测试终端、CRM新渠道业务在11:10页面
恢复，但社会渠道业务仍然未恢复。
14、11:15测试发现网宿误将社会渠道三个域名A记录到DCN智能DNS接口
地址211.138.127.44和122.224.123.74，而非真实的源站IP。
15、11:20联系网宿将社会渠道三个域名正确解析到A记录源站地址。DNS同
步时间20分钟。
16、11:40DNS同步完成，绝大部分社会渠道业务恢复正常，个别用户由于本
地DNS同步刷新时间不同步，导致平台无法访问，已经通过IP地址访问
和手工修改本地DNS为8.8.8.8的方式解决。
处理后效
果/遗留问
题说明
是否影响
集团考核
否
故障原因
是否已在
故障池内
否
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第13页
运维故障评估
故障
根源系统
严重程度
□重大
□严重
■主要
□一般
系统
开发商
亚联
故障待改
进点涉及
科室
■应用优化室
（运行异常）
统一权限配置
配置管理□客户响应室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
统一产品配置
配置管理□计费帐务室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
基础设施
基础保障■系统优化室
系统能力(架
构、容量)问题
业支系统□系统规划室
经分系统□经营分析室
信安系统□信息安全室
软件质量
业支系统
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
经分系统□经营分析室
信安系统□信息安全室
电渠系统□客服中心电渠
运维故障分析
1）告警
监控管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）高可用
保障管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）运维
操作管理
【原因分析】应急回退操作需要网管和CDN侧来操作，处理故障时长不可控。
【改进措施】□规范执行□重复问题□历史遗留问题
4）系统
基础平台
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第14页
问题【改进措施】□规范执行□重复问题□历史遗留问题
故障后续改进
故障所属域（CRM/BOSS/渠道）
优化需求
优化需求编号需求开发责任人需求维护跟踪人
告警监控
告警调整版本号告警调整任务单号告警调整人
故障预案
预案名称新增/修改预案编写人
高可用保
障
优化分析报告名新增/修改报告撰写人
数据稽核
数据稽核任务任务单号稽核人
疑难问题
专题名称专题需要的资源专题发起人
改进措施落实情况
1、已提供渠道证书,网宿已完成配置修改，测试通过
2、完善割接测试方案，割接后由运维人员和应用人员共同确认业务系统可操作，要求网
宿提供完整的测试报告
3、确保第二天现场的保障人员能快速进行配置回退和业务验证。
运维报告
撰写人
吴天东，陈挺改进措施落实监督人陈航
开发故障评估
故障责任
小组
开发故障分析
故障引入
需求编号
和名称
故障影响范围
故障原因
综述
故障详细
分析及问
题解决
故障解决
措施
改进措施（问题避免）
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第15页
1）需求因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）系统设
计因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）软件编
码因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）自测因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
开发改进措施落实情况
➢
开发报告
撰写人
开发改进措施
落实监督人
测试故障评估
故障责任
小组
测试故障分析
1）功能测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）回归测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）性能容
量测试因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）安全性
测试因素
分析及改
进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
5）编译因
素分析及
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第16页
改进【改进措施】□规范执行□重复问题□历史遗留问题
6）上线因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
改进措施落实情况
➢
测试报告
撰写人
测试改进措施
落实监督人
4、关于12月27日部分地市用户充值后余额提醒短信与实际不符的故障（蓝）
故障标题关于12月27日部分地市用户充值后余额提醒短信与实际不符的故障（蓝）
故障简明回顾说明
故障现象
12月27日12点59分，接到客服的报障，反映用户充值后收到短信提醒余额
与实际不符，投诉量大于300，判定为蓝色故障
故障原因
1、查询优化项目对查询代理异常重试5次的机制进行调整，是此次故障的直
接原因：实时计费项目为减少查询代理负荷，并加强调用日志梳理管控，
剔除原查询失败重试五次的机制，由于未考虑查询代理先前错误配置情况，
从而导致异常情况被扩大化，最终出现外围调用无返回，加上外围调用组
装机制不合理，最终导致用户费用显示不准确。
2、查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一：
查询代理外围客户端配置存在历史错误，实时账务上线以后对外围调用的
配置文件进行了调整，忽略了上述CRM批量和帐管批量配置信息。但由于
外围查询有相应错误处理机制，遇失败后进行端口轮询5次重试，若调用
上塘主机查询失败后，会轮询调用滨江的查询代理，因此该错误一直未显
现。
3、帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之
一：本次故障的帐管充值短信下发模块，充值后需要查询实时账单进行模
拟销账，获取用户余额进行下发用户，但当调用查询代理实时账单查询失
败时，程序会自动按照实时账单为0来进行模拟销账，会导致计算得到的
余额虚高，从而下发短信造成用户误解。
故障标准非重要业务1，涉及大于3个地市或大于50%坐席，影响时间持续(30,60]分钟；
恢复情况通过维护和开发最终定位，确定是查询代理优化需求上线造成部分外围实时账
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第17页
单查询接口调用异常，最终导致下发用户提醒短信不准确。通过调整查询代理
客户端配置信息，并且紧急修复代码最终恢复
改进措施
1.完善外围查询接入管控，明确接口规范
针对本次故障，首先对帐管充值下发短信生成异常处理机制进行优化，对外
围应用调用其相关接口，需加强接入管控，明确接口规范，确保外围异常查询
处理逻辑可靠，必须具备容错处理。
2.完善查询代理架构
查询代理作为连接外围系统和实时帐务的枢纽，需要进行框架优化，具备
对外围吞吐量、调用来源、成功失败数、错误类型、关键业务耗时进行有效记
录，并且能够通过运维平台展现，最终达到可监可控，可视可分析。
3.梳理查询代理异常场景，加强开发人员对于账务后台框架的培训
在BOSS账务开发组内进行BOSS后台框架应用开发规范的培训，针对查询
代理返回错误的场景进行梳理，明确哪些错误是可以不进行5次尝试，哪些错
误是需要用5次尝试来保证的。
4.明确管理职责
明确系统优化室环境组为环境配置文件的责任部门，应用优化室优化组为
业务配置文件的责任部门，杜绝类似配置文件历史措施的再次发生．
故障详细分析
故障现象
详细描述
用户充值后收到了充值提醒短信，充值提醒短信中的余额与用户实际的余额
不符，由于查询实时费用超时返回为0，导致短信中的余额=用户充值之后账本
余额，而实际余额=用户充值后的账本余额-用户实时费用，即提醒短信中的余
额虚高。
事件单号SD2问题单号PM2
开始时间
（系统）
12月27日12:59
恢复时间
（系统）
12月28日20:00
开始时间
（业务）
12月27日12:59
恢复时间
（业务）
12月28日20:10
故障影响
系统
帐管系统查询实时费用，批量
业务查询用户实时费用
故障影响业务充值下发短信
故障处理情况
故障起因
简述
查询优化项目对查询代理异常时重试5次的机制进行调整，是此次故障的
直接原因
在实时计费、按量计费项目过程中，一方面为有效减少查询代理负荷，并且
进一步减少帐务后台压力，确保实时计费用户加载能够按时完成；一方面为有
效加强查询代理调用错误日志梳理管控（要求将查询代理的调用错误日志按类
型、端口入库，如果将每次重试的量也入库，会导致统计的日志不准确），项目
组决定对原有调用查询代理异常时重试5次的机制进行优化，在后台服务会持
续异常的场景下，如无来源标记、数据异常、计算服务异常、路由关系不存在
等场景下将重试5次的机制删除，但是一来未考虑到查询代理的配置原因，二
来在设计的时候，场景未考虑充分，从而导致异常情况被扩大化，最终出现外
围调用无返回，加上外围调用组装机制不合理，最终导致用户费用显示不准确。
查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第18页
查询代理是连接外围系统和实时帐务核心系统之间的纽带，外围系统通过查
询代理进行资金、余额、账单查询。查询代理目前部署架构是2台主机（上塘
和滨江主机，各20个进程，每台主机对外提供3个端口供外围调用），而外围
主要是CRM系统（网厅、IVR、短厅、帐管等）通过不同的接口调用，配置文件
ties配置查询代理调用的域名和端口，此文件分为CRMAPP、CRM
批量和帐管批量三份。
2012年实时帐务二期进行查询代理改造后，期间对查询代理连接进行优化
调整，相应外围客户端的调用配置信息也进行调整，但却忽略了上述CRM批量
和帐管批量配置信息调整，最终导致外围CRM批量和帐管批量调用上塘主机都
会失败。但由于外围查询有相应错误处理机制，遇失败后进行端口轮询5次重
试，若调用上塘主机查询失败后，会轮询调用滨江的查询代理，因此该错误一
直未显现。
帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之
一。
查询代理外围客户端众多，包括网厅、信息推送平台、华为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日紧急上线的程序只发布了CRMEJB集群主机，营帐批量后台进程主机未
发布，导致问题依然存在。
10:00再次进行故障仔细排查，最终确认故障原因是由于CRM系统中调用查询
代理的配置错误，存在一定概率单次调用失败，并且此次上线取消了5次重试，
从而导致外围调用查询代理错误，最终返回用户错误余额信息。
13:30紧急修复CRM系统查询代理配置文件，并对遗漏发布的营帐批量后台程
序进行补发布，通过重启相关进程后生成的充值短信恢复正常。
13:30由于27日为避免故障影响范围扩大，处理过程中通过删除统一短信平
台的相关模板而不进行下发，28日晚通过恢复短信模板，并重启统一短信平台
后恢复。
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第19页
处理后效
果/遗留问
题说明
是否影响
集团考核
否
故障原因
是否已在
故障池内
否
运维故障评估
故障
根源系统
CRM系统严重程度
□重大
□严重
□主要
■一般
系统
开发商
亚联
故障待改
进点涉及
科室
■应用优化室
（运行异常）
统一权限配置
配置管理□客户响应室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
统一产品配置
配置管理□计费帐务室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
基础设施
基础保障□系统优化室
系统能力(架
构、容量)问题
业支系统□系统规划室
经分系统□经营分析室
信安系统□信息安全室
软件质量
业支系统
需求管理□业务管理室
缺陷管理■业务管理室
架构管理□系统规划室
测试管理□开发管理室
经分系统□经营分析室
信安系统□信息安全室
电渠系统□客服中心电渠
运维故障分析
1）告警
监控管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）高可用
保障管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）运维
操作管理
【原因分析】
历史配置文件配置导致查询失败率高．
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第20页
【改进措施】□规范执行□重复问题□历史遗留问题
1、明确系统优化室环境组为环境配置文件的责任人，应用优化室优化组为
业务配置文件的责任人，防止类似配置文件历史措施的再次发生；
2、针对本次查询代理无返回的异常情况处理，需要梳理排查，尤其是涉及
到资金相关、调用量大、影响面广的渠道，需要优先进行核实。同时，
查询代理还存在另一风险隐患，由于外围对查询代理返回错误代码无法
处理，因而查询代理约定出错情况将返回0，该问题同样存在隐患，后
续需要协调外围渠道彻底改造。
4）系统
基础平台
问题
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
故障后续改进
故障所属域（CRM/BOSS/渠道）
优化需求
优化需求编号需求开发责任人需求维护跟踪人
告警监控
告警调整版本号告警调整任务单号告警调整人
故障预案
预案名称新增/修改预案编写人
高可用保
障
优化分析报告名新增/修改报告撰写人
数据稽核
数据稽核任务任务单号稽核人
疑难问题
专题名称专题需要的资源专题发起人
改进措施落实情况
➢
运维报告
撰写人
唐艳芬，朱建波改进措施落实监督人蒋健
开发故障评估
故障责任
小组
开发故障分析
故障引入
需求编号
和名称
历史原因故障影响范围全省
故障原因
综述
查询代理优化需求上线造成部分外围实时账单查询接口调用异常，最终导致下
发用户提醒短信提醒余额与实际不符。通过调整查询代理客户端配置信息，并
且紧急修复代码最终恢复。
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第21页
故障详细
分析及问
题解决
1、查询优化项目对查询代理异常时重试5次的机制进行调整，是此次故障的
直接原因。
在实时计费、按量计费项目过程中，一方面为有效减少查询代理负荷，并且进
一步减少帐务后台压力，确保实时计费用户加载能够按时完成；一方面为有效
加强查询代理调用错误日志梳理管控（要求将查询代理的调用错误日志按类型、
端口入库，如果将每次重试的量也入库，会导致统计的日志不准确），项目组决
定对原有调用查询代理异常时重试5次的机制进行优化，在后台服务会持续异
常的场景下，如无来源标记、数据异常、计算服务异常、路由关系不存在等场
景下将重试5次的机制删除，但是一来未考虑到查询代理的配置原因，二来在
设计的时候，场景未考虑充分，从而导致异常情况被扩大化，最终出现外围调
用无返回，加上外围调用组装机制不合理，最终导致用户费用显示不准确。
2、查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一。
查询代理是连接外围系统和实时帐务核心系统之间的纽带，外围系统通过查询
代理进行资金、余额、账单查询。查询代理目前部署架构是2台主机（上塘和
滨江主机，各20个进程，每台主机对外提供3个端口供外围调用），而外围主
要是CRM系统（网厅、IVR、短厅、帐管等）通过不同的接口调用，配置文件
ties配置查询代理调用的域名和端口，此文件分为CRMAPP、CRM
批量和帐管批量三份。
2012年实时帐务二期进行查询代理改造后，期间对查询代理连接进行优化调整，
相应外围客户端的调用配置信息也进行调整，但却忽略了上述CRM批量和帐管
批量配置信息调整，最终导致外围CRM批量和帐管批量调用上塘主机都会失败。
但由于外围查询有相应错误处理机制，遇失败后进行端口轮询5次重试，若调
用上塘主机查询失败后，会轮询调用滨江的查询代理，因此该错误一直未显现。
3、帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之
一。
查询代理外围客户端众多，包括网厅、信息推送平台、华为IVR、短厅/掌厅、
自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在调用
查询代理异常处理机制不一，存在不完善的地方，例如本次故障的帐管充值短
信下发模块，充值后需要查询实时账单进行模拟销账，获取用户余额进行下发
用户，但当调用查询代理实时账单查询失败时，程序会自动按照实时账单为0
来进行模拟销账，会导致计算得到的余额虚高，从而下发短信造成用户误解。
故障解决
措施
1、完善外围查询接入管控，明确接口规范。
针对本次故障，首先对帐管充值下发短信生成异常处理机制进行优化，如果查
询实时账单接口返回有问题，则不生成下发短信，从而防止用户收到不准确的
余额短信。
此外，查询代理作为服务端，外围应用调用其相关接口，需加强接入管控，明
确接口规范，确保外围异常查询处理逻辑可靠，必须具备容错处理，针对本次
查询代理无返回的异常情况处理，需要梳理排查，尤其是涉及到资金相关、调
用量大、影响面广的渠道，需要优先进行核实。同时，查询代理还存在另一风
险隐患，由于外围对查询代理返回错误代码无法处理，因而查询代理约定出错
情况将返回0，该问题同样存在隐患，后续需要协调外围渠道彻底改造。
2、完善查询代理架构。
查询代理作为连接外围系统和实时帐务的枢纽，需要进行框架优化，具备对外
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第22页
围吞吐量、调用来源、成功失败数、错误类型、关键业务耗时进行有效记录，
并且能够通过运维平台展现，最终达到可监可控，可视可分析。
3、梳理查询代理异常场景，加强开发人员对于账务后台框架的培训。
在BOSS账务开发组内进行BOSS后台框架应用开发规范的培训，针对查询代理
返回错误的场景进行梳理，明确哪些错误是可以不进行5次尝试，哪些错误是
需要用5次尝试来保证的。
改进措施（问题避免）
1）需求因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）系统设
计因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）软件编
码因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）自测因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
开发改进措施落实情况
➢
开发报告
撰写人
王涛
开发改进措施
落实监督人
王涛
测试故障评估
故障责任
小组
测试故障分析
1）功能测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）回归测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）性能容
量测试因
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第23页
素分析及
改进
【改进措施】□规范执行□重复问题□历史遗留问题
4）安全性
测试因素
分析及改
进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
5）编译因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
6）上线因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
改进措施落实情况
➢
测试报告
撰写人
测试改进措施
落实监督人
5、关于12月27日客服平台系统运行缓慢的故障（红）
故障标题关于12月27日客服平台出现系统运行缓慢的故障（红）
故障简明回顾说明
故障现象12月27日8点32分，接到客服报障，反映客服平台出现运行缓慢的现象。
故障原因
由于对缓存数据缺乏控制手段，随着免打扰用户、特殊名单配置的逐步增加，
占用大量内存导致App内存不足，引发APP频繁进行老年代内存回收（FULLGC），
从而导致系统响应缓慢。
故障标准重要业务，涉及(1,3]个地市或(20%,50%]坐席，影响时间持续(60,180]分钟；
恢复情况
通过调整客服业务APP实例内存参数，由原先2G增加至3G，最终重启APP后
恢复故障。
改进措施
1、开发质量优化
（1）优化特殊名单的缓存、免打扰用户的缓存。采用JAVABEAN替代BOBEAN，
并只缓存有用的部分字段，可以有效减少缓存内存的不必要占用。（已提交优化
需求，BR2014010631系统优化室-关于客服业务系统便签发送的优化需求，
BR2014010214优化客服系统特殊名单表、免打扰用户表查询方式的需求）
2、维护手段优化
（1）目前的监控无法及时定位FULLGC占用时间长的场景，拟结合FULLGC次
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第24页
数和时间，设计和部署新的监控点，可有效提升该问题的及时发现和规避率。
（2）针对核心业务，研究压力测试技术方案，在测试环境和生产环境予以部署，
可有效提升类似问题的及时发现和规避率。
3、系统架构优化
（1）将现网客服APP小机和JDK产品替换为X86刀片和Jrockit；
（2）可考虑充分利用MEMCACHE，优化缓存实现方式，进一步提高缓存效率。
4、加强人员能力培养，知识传递
（1）协调亚联研发骨干和原厂技术专家来杭授课，组织现场运维、测试、开发
核心人员进行有针对性的技术培训，积累进一步的监控、分析、故障定位方法
和故障预案；
（2）在后续团队建设中考虑加大对架构人才的培养力度。
故障详细分析
故障现象
详细描述
12月27日8点32分，接到客服报障反映客服平台出现运行缓慢，12点22分
业务恢复，影响客服的坐席数量超过2/3。由于影响客服坐席>50%，影响时间
大于180分钟，故判定为红色故障。
事件单号SD2问题单号PM2
开始时间
（系统）
8:15
恢复时间
（系统）
12:22
开始时间
（业务）
8:32
恢复时间
（业务）
12:22
故障影响
系统
客服业务故障影响业务客服系统相关业务
故障处理情况
故障起因
简述
12月27日早上，客服APP实例Java内存回收FULLGC频繁,造成应用响
应效率明显下降是故障的直接原因。故障时实例FULLGC时间消耗从前一天的
1%上升到33%。
1、现有缓存机制存在缺陷:缓存数据量过大造成内存资源不足频繁FULLGC，
是技术层面造成故障的主要影响因素。通过对现有缓存数据的分析，发现
特殊名单的缓存、免打扰用户的缓存数据特别多，分别达到了近24万多和
10万多的数据量，在实现方式上通过全字段缓存，并且使用了BOBEAN的
对象，这种方式的内存相对较高，存在后续优化的必要。在现有APP的内
存老年区大小约为1.2G，而各种缓存数据合计已经超过700M，主要组成部
分是特殊名单和免打扰用户缓存，超过600M。
2、业务量增长是造成故障的客观触发原因：据统计，特殊名单客户、免打扰
用户数量持续增加，两类客户数据长时间处于连续上升趋势，近半年来更
是每月净增数万（详细参见附录）。为保持客服的正常接续速度，这部分
数据每天凌晨均会以缓存的形式自动刷新到APP内存,以上两个因素的结
合，最终导致故障发生。
3、JDK的垃圾回收机制问题较为底层，本地开发、测试、维护人员控制力较
弱:该问题较为底层涉及到JDK的垃圾回收机制，本地开发、测试、维护人
员能力不足，是本次故障未能及时准确定位，造成故障时间长的主要原因。
现场开发、测试团队基本没有JDK方面的专家，运维团队仅系统室环境组
对JDK底层机制有一定了解，在团队整体能力、故障预案储备、定位手段
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第25页
等方面均对JVM的FULLGC问题准备不足。目前，对JDK底层机制问题具
备较强问题分析能力的只有亚联极个别研发骨干。
4、其他影响因素：现有客服ＡＰＰ运行在ＨＰ小型机上，且采用较老版本的
ＨＰJDK1.6.0版本。架构较为传统，成本较高，效率较低，ＢＵＧ风险
较大，内存利用率也不够优化。可考虑替换为Ｘ８６刀片和Jrockit版本。
附录：
特殊名单客户业务场景：
针对那些存在高频投诉、恶意骚扰等不良行为的用户号码，进行名单沉淀并屏
蔽，使其无法正常拨入10086进行投诉。
特殊名单的标签有A、B、C、D、Y、H等，用户被打上特殊名单的标签后，有
一定的持续期，如果在持续期内无不良行为则进行释放，若还存在不良行为，
则进行延期。
特殊名单的判断口径由客户服务部（如A/B/C/D类别）和客服中心(如Y/H等其
他类别)提供，后台程序根据统计的口径每天和每月进行捕获，大部分捕获的用
户被程序判为特殊名单用户进行沉淀，对于小部分疑似用户信息，由人工进行
干预确认（如客服的质检人员、地市人员），确认为特殊用户，客服中心接口
人以任务单的形式，由支撑二线维护人员进行后台插入。
每月特殊名单新增用户量趋势：
免打扰客户业务场景：
用户不想被10086下发的营销推荐短信或者10086的外呼电话所打扰，通过营
业厅或者10086投诉等方式进行投诉处理。由一线人员通过前台页面进行逐个
号码添加至免打扰用户清单中。
免打扰用户数据是只增不减的，没有清退或失效的机制存在。
每个月免打扰用户新增用户量趋势：
0
10000
20000
30000
40000
50000
60000
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第26页
故障处理
回顾
1.8点15分，运维人员接到客服业务系统WEB有2个集群线程过载告警（瞬
时，之后有零星实例过载告警）；应用、中间件、数据库、网、主机等运维
团队均开始介入，紧急对过载实例进行分析；
2.8点23分，通知客服业务系统开发人员到场支持；同时，经过分析故障现
象怀疑与数据库存在少量死锁有关，开始对死锁进行处理；
3.8点29分，死锁处理完成，业务未回复；由于数据库问题已经排除，数据
库容灾切换预案未启用；
4.8点32分，接到客服报障，反应部分客服坐席平台出现运行缓慢的情况,
灰色事件；
5.8点39分，通过对告警线程的ThreadDump分析判断是客服APP线程繁忙，
开始分批对客服业务系统APP进行重启操作；8点58分重启完成，业务未
恢复；
6.8点57分，由于处理时间超过15分钟，升级为蓝色事件。
7.9点整，分析发现客服APP日志有调用CRMREMOTE接口的超时报错，怀疑
是CRMREMOTE接口问题，对CRMREMOTE接口进行ThreadDump和日志分析，
并对CRM提供给客服的REMOTE接口进行重启；9点03分，REMOTE接口重
启完成，业务未恢复；
8.9点14分，由于处理时间超过30分钟，升级为黄色事件。
9.9点20分，将CRM提供给客服的APP集群切往G19，G20备用集群，并开
始分批重启CRM提供给客服的APP集群，业务未恢复；
10.9点30分，怀疑可能跟昨晚上线的部分内容有关，紧急对渠道协同上线的
权限脚本回退，业务未恢复；
11.9点52分，继续对CRM权限Memcached缓存服务重启，业务未恢复；继续
分批对客服使用的CRM系统WEB集群进行重启，10点25重启完成，业务
未恢复；
12.9点54分，由于处理时间超过60分钟，升级为橙色事件。
13.11点40分，在亚联研发团队远程协助下，现场团队对客服APP实例GC消
耗进行了分析，发现APP内存FULLGC频繁，而且开销很大；
14.11点42分，开始对客服所有APP实例内存参数进行调整，由原来的2G
调整为3G，然后并对所有APP进行分批重启。
0
5000
10000
15000
20000
25000
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第27页
15.12点22分，APP重启完成，业务恢复。
处理后效
果/遗留问
题说明
优化缓存机制
是否影响
集团考核
否
故障原因
是否已在
故障池内
否
运维故障评估
故障
根源系统
客服业务严重程度
■重大
□严重
□主要
□一般
系统
开发商
亚联
故障待改
进点涉及
科室
■应用优化室
（运行异常）
统一权限配置
配置管理□客户响应室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
统一产品配置
配置管理□计费帐务室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
基础设施
基础保障■系统优化室
系统能力(架
构、容量)问题
业支系统□系统规划室
经分系统□经营分析室
信安系统□信息安全室
软件质量
业支系统
需求管理□业务管理室
缺陷管理■业务管理室
架构管理□系统规划室
测试管理■开发管理室
经分系统□经营分析室
信安系统□信息安全室
电渠系统□客服中心电渠
运维故障分析
1）告警
监控管理
【原因分析】
目前的监控无法及时定位FULLGC占用时间长的场景。
【改进措施】□规范执行□重复问题□历史遗留问题
后续计划结合FULLGC次数和时间，设计和部署新的监控点，提升该问题的及
时发现和规避率。
2）高可用
保障管理
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第28页
【改进措施】□规范执行□重复问题□历史遗留问题
3）运维
操作管理
【原因分析】
JDK的垃圾回收机制问题较为底层，本地开发、测试、维护人员控制力较弱。
【改进措施】□规范执行□重复问题□历史遗留问题
协调原厂、第三方专家组织进行JVM内存控制机制专题知识交流培训。
4）系统
基础平台
问题
【原因分析】
现有客服APP运行在HP小型机上，且采用较老版本的ＨＰJDK1.6.0版本。架
构较为传统，成本较高效率较低，BUG风险较大，内存利用率也不够优化。
【改进措施】□规范执行□重复问题□历史遗留问题
后续考虑替换为X86刀片和Jrockit版本。
故障后续改进
故障所属域（CRM/BOSS/渠道）
优化需求
优化需求编号需求开发责任人需求维护跟踪人
（1）BR2014010214优化
客服系统特殊名单表、免打
扰用户表查询方式的需求
（2）BR2014010631系统
优化室-关于客服业务系统
便签发送的优化需求
石永超钟储建
告警监控
告警调整版本号告警调整任务单号告警调整人
故障预案
预案名称新增/修改预案编写人
高可用保
障
优化分析报告名新增/修改报告撰写人
数据稽核
数据稽核任务任务单号稽核人
疑难问题
专题名称专题需要的资源专题发起人
改进措施落实情况
➢
运维报告
撰写人
钟储建，刘鹏改进措施落实监督人陈航，唐涛
开发故障评估
故障责任
小组
开发故障分析
故障引入
需求编号
和名称
故障影响范围
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第29页
故障原因
综述
故障详细
分析及问
题解决
故障解决
措施
改进措施（问题避免）
1）需求因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）系统设
计因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）软件编
码因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）自测因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
开发改进措施落实情况
➢
开发报告
撰写人
开发改进措施
落实监督人
测试故障评估
故障责任
小组
测试故障分析
1）功能测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）回归测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）性能容
量测试因
【原因分析】
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第30页
素分析及
改进
【改进措施】□规范执行□重复问题□历史遗留问
4）安全性
测试因素
分析及改
进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
5）编译因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
6）上线因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
改进措施落实情况
➢
测试报告
撰写人
测试改进措施
落实监督人
6、关于12月30日全省部分用户通过充值卡充值未到账的故障（蓝）
故障标题关于12月30日全省部分用户通过充值卡充值未到账的故障（蓝）
故障简明回顾说明
故障现象
各地市部分营业厅、代理渠道点操作人员在CRM前台进行有价卡类等相关操作
提升失败，具体表现为：全国充值卡查询时提示验证充值卡状态失败，调用10S
超时；进行全国充值卡充值时提示：全国有价卡销售出错！null!；进行全国卡
POS券打印销售时提示：BOSS销售登记失败：11。同时，部分收到前台反馈成
功的，实际上并没有充值成功，用户投诉充值卡充值未到帐。
故障原因
在CRM前台进行全国充值卡查询、充值、销售登记时，需从营业侧通过新
统一开通与网管侧VC进行交互，获取全国充值卡的相关信息进行卡校验，经核
实当网元在不稳定的情况下，由于统一开通实时接口处理程序机制不完善（开
通实时接口通过计数器进行连接控制，但当CRM接口超时，会断开连接同时触
发开通实时接口程序释放消息，但在释放消息的时候存在BUG，没有将计数器
递减，从而计数器达到阀值后，当前连接不再向网元发送消息），从而导致CRM
调用无法过来，从而影响全国充值卡相关操作调用10S超时，因此有价卡类相
关操作都无法成功。
此外，由于营业侧调用统一开通实时接口的超时时间为40S，为保障月末
和月初系统高峰期的成功率，统一开通在月初三天、月末三天存在特殊逻辑，
当统一开通超过40S未应答，则营业侧将作为成功处理（此业务逻辑为历史逻
辑）。因为上述逻辑，在开通实时接口异常的情况下，返回给用户成功实际上却
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第31页
未成功，所以造成用户全国卡充值后提示成功实际上却并没有成功，从而造成
批量用户投诉充值未到帐投诉。（此外，该开通实时接口同样影响了家庭亲情网、
虚拟网的办理，造成了大量和网管数据不一致问题）
故障标准非重要业务1，涉及大于3个地市或大于50%坐席，影响时间持续(15,30]分钟；
恢复情况
1、临时解决措施：维护人员通过不定期重启统一开通实时接口，释放计数器，
保证CRM前台业务能够正常受理。
2、彻底解决措施：12月31号晚上紧急上线修复程序代码，彻底解决此问题，
系统恢复正常。
改进措施
1、加强开通实时接口优化改进：针对开通实时接口，优化完善处理机制，确
保既作为服务端，又作为客户端的消息调用保护机制。
2、加强开通实时接口测试规范：加强服务实时接口压力测试，模拟网络侧异
常情况下，对CRM的调用进行测试。
3、运维监控能力优化：通过程序优化改造，加强计数器合理值的监控告警，
同时部署实时接口探测程序，在异常情况下促发告警。（开发进行解决）
4、开通实时接口月末月初特殊逻辑优化：近期召开多方讨论，针对特殊逻辑
处理进行优化。
故障详细分析
故障现象
详细描述
各地市部分营业厅、代理渠道点操作人员在CRM前台进行全国充值卡查询时提
示验证充值卡状态失败，调用10S超时；进行全国充值卡充值时提示：全国有
价卡销售出错！null!；进行全国卡POS券打印销售时提示：BOSS销售登记失
败：11。以上业务操作部分成功，部分失败。
事件单号SD2问题单号PM2
开始时间
（系统）
2013-12-3014:32:36
恢复时间
（系统）
2013-12-3017:44:22
开始时间
（业务）
2013-12-3014:32:36
恢复时间
（业务）
2013-12-3018:26:22
故障影响
系统
CRM故障影响业务
CRM平台全国充值卡查询、
销售
故障处理情况
故障起因
简述
在CRM前台进行全国充值卡查询、充值、销售登记时，需从营业侧通过新统一
开通与网管侧VC进行交互，获取全国充值卡的相关信息进行卡校验，经核实当
网元在不稳定的情况下，由于统一开通实时接口处理程序机制不完善（开通实
时接口通过计数器进行连接控制，但当CRM接口超时，会断开连接同时触发开
通实时接口程序释放消息，但在释放消息的时候存在BUG，没有将计数器递减，
从而计数器达到阀值后，当前连接不再向网元发送消息），从而导致CRM调用无
法过来，从而影响全国充值卡相关操作调用10S超时，最终引发上述故障。
故障处理
回顾
1、14:32接到报障通知，反馈部分前台操作全国卡充值失败，操作全国卡的销
售和赠送失败，充值卡网管综合查询出错。
2、提取前台报错的应用和web日志进行分析，并通知crm侧检查开通处理情
况。发现资源库一个实例的监听存在异常，数据库组重启监听后恢复正常，
并重启VC接口相关服务。
3、经分析日志，初步定位为页面方法处理超时，采取调长超时时限的方案进
行紧急恢复，恢复效果不明显。（约在15:20完成，配置调整从10秒调整
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第32页
到20秒，app服务重启）。
4、15:30初步判断为开通系统处理问题，重启开通实时接口服务后，故障现象
未再现，通知前台进行验证。
5、15:14验证未通过，地市仍有异常，收到阶段通知。
6、16:12故障升级为蓝色。
7、16:30初步定位为营业调开通系统时走了配置的40秒超时，引起前台处理
超时。修改超时时间为5秒后，统一开通实时接口服务重启，app服务重启，
前台不再报错。
8、17:05重新将5秒改回40秒，统一开通实时接口服务重启，app缓存刷新。
前台无超时报错。
9、17:45验证业务恢复正常。
----次日----
10、8：56前台全国充值卡查询，充值报空值、报10秒超时，重启APP服务，
空值正常，报10秒超时仍然存在。
11、9:46统一开通实时接口服务重启，前台报错消失，系统恢复。
12、10:30，统一开通项目组核实当网元存在不稳定的情况下，统一开通实时接
口处理程序机制不完善（有个计数器没有清），导致CRM调用无法过来，从而影
响全国充值卡相关操作调用10S超时。经领导审批于当晚8:00紧急上线修复程
序代码。
处理后效
果/遗留问
题说明
通过不定时重
启统一开通实
时接口，使业务
正常，同时紧急
上线修改程序
是否影响
集团考核
否
故障原因
是否已在
故障池内
否
运维故障评估
故障
根源系统
CRM系统严重程度
□重大
□严重
□主要
■一般
系统
开发商
亚联
故障待改
进点涉及
科室
■应用优化室
（运行异常）
统一权限配置
配置管理□客户响应室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
统一产品配置
配置管理□计费帐务室
软件质量
需求管理□业务管理室
缺陷管理□业务管理室
架构管理□系统规划室
测试管理□开发管理室
基础设施
基础保障□系统优化室
系统能力(架
构、容量)问题
业支系统□系统规划室
经分系统□经营分析室
信安系统□信息安全室
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第33页
软件质量
业支系统
需求管理□业务管理室
缺陷管理■业务管理室
架构管理□系统规划室
测试管理■开发管理室
经分系统□经营分析室
信安系统□信息安全室
电渠系统□客服中心电渠
运维故障分析
1）告警
监控管理
【原因分析】
无部署监控告警。
【改进措施】□规范执行□重复问题□历史遗留问题
通过程序优化改造，加强计数器合理值的监控告警，同时部署实时接口探测程
序，在异常情况下促发告警。（开发进行解决）
2）高可用
保障管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）运维
操作管理
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）系统
基础平台
问题
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
故障后续改进
故障所属域（CRM/BOSS/渠道）
优化需求
优化需求编号需求开发责任人需求维护跟踪人
告警监控
告警调整版本号告警调整任务单号告警调整人
故障预案
预案名称新增/修改预案编写人
高可用保
障
优化分析报告名新增/修改报告撰写人
数据稽核
数据稽核任务任务单号稽核人
疑难问题
专题名称专题需要的资源专题发起人
改进措施落实情况
➢
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第34页
运维报告
撰写人
章清云改进措施落实监督人蒋健
开发故障评估
故障责任
小组
统一开通项目组
开发故障分析
故障引入
需求编号
和名称
故障引入需求编
号和名称
故障原因
综述
现在的系统业务逻辑为：营业开通调用统一开通实时接口的超时时间系统统一
设置为40S，统一开通与在月初三天、月末三天如果统一开通超过40S未应答，
那么营业将作为成功处理（历史业务逻辑）。即出现了如充值操作超时，那么
CRM对用户会显示成功，但实际后端处理结果不确定，最终导致充值未到账问
题的产生
故障详细
分析及问
题解决
1、全国卡充值渠道很多，业务流程一般有两个步骤：查询、充值。这两个操
作的详细流程都一致：
非月初前三天和月末后三天时，接口调用为实时接口，无特殊逻辑，真实反
映充值的成功与否
1)业务受理渠道发起操作，请求转发到CRMAPP。
2)CRMAPP通过营业开通模块组向统一开通发起实时调用。
3)统一开通平台组指令向全国卡充值平台发起请求。
4)全国卡充值平台处理后应答统一开通。
5)统一开通向营业开通应答结果。
6)营业开通向上游发起方应答结果。
月初前三天和月末后三天特殊逻辑如下
营业开通调用统一开通实时接口的超时时间为40S，统一开通与在月初三天、
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第35页
月末三天如统一开通超过40S未应答，那么营业将作为成功处理（此业务逻
辑为历史逻辑）。对于后端是否真实处理成功不做稽核和后续处理。
统一开通实时进程BUG
统一开通实时进程在12月31日确认存在1个问题：当CRM接口超时时间<
网元超时时间设置时，由于CRM超时断开连接触发开通实时接口程序释放消息，
在释放消息的时候开通系统存在BUG，没有将队列计数器减1。
统一开通共有8个进程与网元连接，每个进程最多允许并发10个请求，当
某个进程累计达到10次超时，计数器的值为10，且一直无法减少，此时，营
业送开通发来请求，如果分配给此进程，开通不会做任何处理，40s超时后返
回，同时营业送开通会向前台返回成功，但用户并未成功充值。
营业送开通的超时时间原本设置为40秒，在全国卡充值平台正常的情况下
超时的可能性基本不存在，错误代码也不会被执行到。故障发生后，超时时间
修改为5s，在一定程度上提高了问题的发生概率。
故障解决
措施
统一开通将计数器的bug逻辑修改正确，当营业开通超时时，将计数器减1，
保证业务逻辑正确，已于12月31日上线完成
改进措施（问题避免）
提供一个CRM调统一开通实时接口探测的工具，可以对接口返回时间做实时监控告警。
责任人：蔡宏富；完成时间：2014年1月
1）需求因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）系统设
计因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）软件编
码因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）自测因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
开发改进措施落实情况
➢
开发报告
撰写人
杨俏，蔡宏富
开发报告撰写
人
杨俏，蔡宏富
测试故障评估
故障责任
小组
浙江移动通信有限责任公司业务支撑中心
浙江移动业务支撑中心第36页
测试故障分析
1）功能测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
2）回归测
试因素分
析及改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
3）性能容
量测试因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
4）安全性
测试因素
分析及改
进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
5）编译因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
6）上线因
素分析及
改进
【原因分析】
【改进措施】□规范执行□重复问题□历史遗留问题
改进措施落实情况
➢
测试报告
撰写人
测试报告撰写
人