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

中国移动浙江企业IT系统故障详细分析汇报模板
　　十二月份故障分析汇报(12月 01日 -12月 31日) 1、有关 12月 4日客服部分座席多次出现被忽然签出故障(蓝)
　　2、 有关 12月 8日金华顾客反应通过社会渠道系统充值话费未到帐故障 (蓝)
　　3、有关 12月 26日部分地市社会渠道客户关系管理系统登陆异常故障(黄)
　　析到 CDN 地址。社会渠道管理平台通过 IP 能正常访问,通过域名访问失 败。 终端系统、 CRM 新渠道通过 IP 和域名都能正常访问。 判断为 CDN 问 题,后经和网宿沟通确认,社会渠道为 https 应用,因网宿没有导入对应 渠道证书, 导致应用无法访问。 终端系统、 CRM 新渠道系统为 http 页面访问正常。b5E2RGbCAP
　　3、 8:38 告知代理点直接通过社会渠道三个源 IP 访问,业务恢复正常。但因 渠道系统代理点众多,部分通过域名访问平台顾客仍旧无法访问。p1EanqFDPw
　　4、 8:40 联络网管中心进行 DNS 配置回退,但未联络上厂家。
　　5、 8:42联络 CDN 进行社会渠道域名回退,将渠道三个域名指向详细源站 IP ,但 CDN 厂家误认为受影响业务只有社会渠道电信域名,在修改 DNS 配 置时只将社会渠道电信域名 A 记录指向到源站 IP 122.224.123.75, 此外二 个社会渠道域名未进行源站 IP 切换。 DNS 布署和同步时间超过 20分钟。 6、 9:05 CMCC 测试 DNS 解析电信域名到源站 IP ,业务访问正常。但移动和网 通域名 DNS 解析仍然为 CDN CNAME 记录,业务无法正常访问。部分代理商 反馈业务正常。DXDiTa9E3d
　　7、 9:10 因仍有部分顾客业务未恢复, 网络组规定网宿将渠道三个域名 NS 记 录到 DCN 智能 DNS 服务器 (211.138.127.44和 122.224.123.74)RTCrpUDGiT
　　网宿反馈无法配置 NS 记录,只能配置 A 记录。这过程布署和同步时间超 过 30分钟。
　　8、 9:40 CDN配置生效后,部分顾客通过域名访问社会渠道页面仍然无法打 开。
　　9、 9:50 联络网管中心回退社会渠道、 终端、 CRM 新渠道域名配置, 删除网 管 DNS 对应 CNAME 记录,增长指向智能 DNS 服务器 NS 记录。 DNS 同 步时间超过 40分钟。5PCzVD7HxA
　　10、 9:50-10:30 在 DNS 配置同步过程中,维护人员页面发现访问社会渠道、 终端、 CRM 新渠道网站会跳转到广告页面, DNS 解析社会渠道域名会解析 到未知 IP ,出现 DNS 劫持。jLBHrnAILg
　　11、 10:40联络电信企业,反馈 DNS 被劫持状况。
　　12、 10:40 因网管中心全局 DNS NS记录同步比较慢 (同步周期 2小时 ) ,维护 人员联络网管中心删除社会渠道、 终端、 CRM 新渠道域名 NS 记录, 并将 域名 NS 记录修改成网宿提供 CNAME 记录, DNS 配置同步时间 30分钟。 13、 11:10 在 DNS 配置同步过程中, 测试终端、 CRM 新渠道业务在 11:10页面 恢复,但社会渠道业务仍然未恢复。xHAQX74J0X
　　14、 11:15 测试发现网宿误将社会渠道三个域名 A 记录到 DCN 智能 DNS 接口 地址 211.138.127.44和 122.224.123.74,而非真实源站 IP 。LDAYtRyKfE
　　15、 11:20 联络网宿将社会渠道三个域名对解析到 A 记录源站地址。 DNS 同 步时间 20分钟。Zzz6ZB2Ltk
　　16、 11:40 DNS同步完毕,绝大部分社会渠道业务恢复正常,个别顾客由于本 地 DNS 同步刷新时间不一样步,导致平台无法访问,已经通过 IP 地址访问 和手工修改当地 DNS 为 8.8.8.8方式处理。dvzfvkwMI1
　　处理后效 果 /遗留问 题阐明 与否影响
　　集团考核
　　否
　　故障原因
　　与否已在
　　故障池内
　　否
　　4、有关 12月 27日部分地市顾客充值后余额提醒短信与实际不符故障(蓝)
　　查询代理是连接外围系统和实时帐务关键系统之间纽带, 外围系统通过查 询代理进行资金、余额、账单查询。查询代理目前布署架构是 2台主机(上塘 和滨江主机,各 20个进程,每台主机对外提供 3个端口供外围调用) ,而外围 重要是 CRM 系统(网厅、 IVR 、短厅、帐管等)通过不一样接口调用,配置文献 mdb.properties 配置查询代理调用域名和端口,此文献分为 CRM APP、 CRM 批量和帐管批量三份。rqyn14ZNXI
　　实时帐务二期进行查询代理改造后,期间对查询代理连接进行优化 调整,对应外围客户端调用配置信息也进行调整,但却忽视了上述 CRM 批量 和帐管批量配置信息调整,最终导致外围 CRM 批量和帐管批量调用上塘主机都 会失败。但由于外围查询有对应错误处理机制,遇失败后进行端口轮询 5次重 试,若调用上塘主机查询失败后,会轮询调用滨江查询代理,因此该错误一 直未显现。EmxvxOtOco
　　帐管充值下发短信生成模块异常处理机制不健全是故障重要影响原因之 一。
　　查询代理外围客户端众多,包括网厅、信息推送平台、华为 IVR 、短厅 /掌 厅、自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在 调用查询代理异常处理机制不一,存在不完善地方,例如本次故障帐管充 值短信下发模块,充值后需要查询实时账单进行模拟销账,获取顾客余额进行 下发顾客,但当调用查询代理实时账单查询失败时,程序会自动按照实时账单 为 0来进行模拟销账,会导致计算得到余额虚高,从而下发短信导致顾客误 解。SixE2yXPq5
　　故障处理 回忆 12月 27日:
　　12:59 总控台短信:【灰】充值提醒短信与实际余额不符;
　　13:00 维护、账务开发、查询代理有关开发人员通过排查核算,发现充值入账 日志连 MDB 错误量诸多 , 比 25日多诸多,虽然只计算一小时量也不是一种量 级(故障当日 1小时有上万条报错,平时只有百来条) ;6ewMyirQFL
　　13:30 为防止故障升级,维护侧告知华为关闭充值提醒短信;
　　14:30 开发确认前一晚上线优化需求,关闭了外围查询失败重试 5次机 制,改为一次;
　　15:40 总控台短信:【蓝】超 60分钟,升蓝;
　　23:00 紧急上线查询代理外围客户端(包括 CRM ,帐管)调用查询失败恢复重 试 5次功能。
　　12月 28日:
　　8:10 维护第二天上线跟踪发现问题仍然存在,告知开发立即到现场,核算发 现 27日紧急上线程序只公布了 CRM EJB 集群主机,营帐批量后台进程主机未 公布,导致问题仍然存在。kavU42VRUs
　　10:00 再次进行故障仔细排查, 最终确认故障原因是由于 CRM 系统中调用查询 代理配置错误, 存在一定概率单次调用失败, 并且本次上线取消了 5次重试, 从而导致外围调用查询代理错误,最终返回顾客错误余额信息。y6v3ALoS89
　　13:30 紧急修复 CRM 系统查询代理配置文献, 并对遗漏公布营帐批量后台程 序进行补公布,通过重启有关进程后生成充值短信恢复正常。M2ub6vSTnP
　　13:30 由于 27日为防止故障影响范围扩大,处理过程中通过删除统一短信平 台有关模板而不进行下发, 28日晚通过恢复短信模板,并重启统一短信平台 后恢复。0YujCfmUCw
　　故障详细 分析及问 题处理
　　1、查询优化项目对查询代理异常时重试 5次机制进行调整,是本次故障 直接原因。
　　在实时计费、按量计费项目过程中,首先为有效减少查询代理负荷,并且进 一步减少帐务后台压力,保证明时计费顾客加载可以准时完毕;首先为有效 加强查询代理调用错误日志梳理管控 端口入库, 假如将每次重试量也入库, 会导致记录日志不精确) , 项目组决 定对原有调用查询代理异常时重试 5次机制进行优化,在后台服务会持续异 常场景下,如无来源标识、数据异常、计算服务异常、路由关系不存在等场 景下将重试 5次机制删除,不过一来未考虑到查询代理配置原因,二来在 设计时候,场景未考虑充足,从而导致异常状况被扩大化,最终出现外围调 用无返回,加上外围调用组装机制不合理,最终导致顾客费用显示不精确。 2、查询代理外围客户端配置存在历史错误,是本次故障重要影响原因之一。 查询代理是连接外围系统和实时帐务关键系统之间纽带,外围系统通过查询 代理进行资金、余额、账单查询。查询代理目前布署架构是 2台主机(上塘和 滨江主机,各 20个进程,每台主机对外提供 3个端口供外围调用) ,而外围主 要是 CRM 系统(网厅、 IVR 、短厅、帐管等)通过不一样接口调用,配置文献 mdb.properties 配置查询代理调用域名和端口,此文献分为 CRM APP、 CRM 批量和帐管批量三份。eUts8ZQVRd
　　实时帐务二期进行查询代理改造后, 对应外围客户端调用配置信息也进行调整,但却忽视了上述 CRM 批量和帐管 批量配置信息调整, 最终导致外围 CRM 但由于外围查询有对应错误处理机制,遇失败后进行端口轮询 5次重试,若调 用上塘主机查询失败后, 会轮询调用滨江查询代理,sQsAEJkW5T
　　3、帐管充值下发短信生成模块异常处理机制不健全是故障重要影响原因之 一。
　　查询代理外围客户端众多,包括网厅、信息推送平台、华为 IVR 、短厅 /掌厅、 自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在调用 查询代理异常处理机制不一,存在不完善地方,例如本次故障帐管充值短 信下发模块,充值后需要查询实时账单进行模拟销账,获取顾客余额进行下发 顾客,但当调用查询代理实时账单查询失败时,程序会自动按照实时账单为 0来进行模拟销账,会导致计算得到余额虚高,从而下发短信导致顾客误解。 故障处理 措施GMsIasNXkA
　　1、完善外围查询接入管控,明确接口规范。
　　针对本次故障,首先对帐管充值下发短信生成异常处理机制进行优化,假如查 询实时账单接口返回有问题,则不生成下发短信,从而防止顾客收到不精确 余额短信。TIrRGchYzg
　　此外,查询代理作为服务端,外围应用调用其有关接口,需加强接入管控,明 确接口规范,保证外围异常查询处理逻辑可靠,必须具有容错处理,针对本次 查询代理无返回异常状况处理,需要梳理排查,尤其是波及到资金有关、调 用量大、影响面广渠道,需要优先进行核算。同步,查询代理还存在另一风 险隐患,由于外围对查询代理返回错误代码无法处理,因而查询代理约定出错 状况将返回 0,该问题同样存在隐患,后续需要协调外围渠道彻底改造。 2、完善查询代理架构。7EqZcWLZNX
　　查询代理作为连接外围系统和实时帐务枢纽,需要进行框架优化,具有对外
　　5、有关 12月 27日客服平台系统运行缓慢故障(红)
　　6、有关 12月 30日全省部分顾客通过充值卡充值未到账故障(蓝)
本文档来源于第一文库网：