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

《中国移动浙江公司IT系统故障详细分析报告模板.pdf》由会员分享，可在线阅读，更多相关《中国移动浙江公司IT系统故障详细分析报告模板.pdf（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第 1 页 中国移动浙江公司 IT 系统故障详细分析报告模板 十二月份故障分析报告(12 月 01 日-12 月 31 日)1、关于 12 月 4日客服部分座席多次出现被突然签出的故障(蓝)2、关于 12 月 8 日金华用户反映通过社会渠道系统充值话费未到帐的故障(蓝)3、关于 12 月 26 日部分地市社会渠道客户关系管理系统登陆异常故障(黄)析到 CDN 地址。社会渠道管理平台通过 IP 能正常访问,通过域名访问失 败。终端系统、CRM 新渠道通过 IP 与域名都能正常访问。判断为 CDN 的问 题,后经与网宿沟通确认,社会渠道为 https 应用,因网宿没有导入相应 的渠道证书,导致应用

2、无法访问。终端系统、CRM 新渠道系统为 http 页面访问正常。3、8:38 通知代理点直接通过社会渠道三个源 IP 访问,业务恢复正常。但因 渠道系统代理点众多,部分通过域名访问平台的用户仍旧无法访问。4、8:40 联系网管中心进行 DNS 配置回退,但未联系上厂家。5、8:42 联系 CDN 进行社会渠道域名回退,将渠道三个域名指向具体的源站 IP,但 CDN 厂家误认为受影响业务只有社会渠道电信域名,在修改 DNS 配 置时只将社会渠道电信域名 A 记录指向到源站 IP 122.224.123.75,另外二 个社会渠道域名未进行源站 IP 切换。DNS 部署与同步时间超过 20 分钟。

3、6、9:05 CMCC 测试 DNS 解析电信域第 2 页 名到源站 IP,业务访问正常。但移动与网 通域名 DNS 解析仍然为 CDN CNAME 记录,业务无法正常访问。部分代理商 反馈业务正常。7、9:10 因仍有部分用户业务未恢复,网络组要求网宿将渠道三个域名 NS 记 录到 DCN 智能 DNS 服务器(211.138.127.44 与 122.224.123.74)网宿反馈无法配置 NS 记录,只能配置 A 记录。这过程部署与同步时间超 过 30 分钟。8、9:40 CDN 配置生效后,部分用户通过域名访问社会渠道页面仍然无法打 开。9、9:50 联系网管中心回退社会渠道、终端、C

4、RM 新渠道域名的配置,删除网 管 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 记录修改成网宿提供

5、的 CNAME 记录,DNS 配置同步时间 30 分钟。13、11:10 在 DNS 配置同步过程中,测试终端、CRM 新渠道业务在 11:10 页面 恢复,但社会渠道业务仍然未恢复。第 3 页 14、11:15 测试发现网宿误将社会渠道三个域名 A 记录到 DCN 智能 DNS 接口 地址 211.138.127.44 与 122.224.123.74,而非真实的源站 IP。15、11:20 联系网宿将社会渠道三个域名正确解析到 A 记录源站地址。DNS 同 步时间 20 分钟。16、11:40 DNS 同步完成,绝大部分社会渠道业务恢复正常,个别用户由于本 地 DNS 同步刷新时间不同步,

6、导致平台无法访问,已经通过 IP 地址访问 与手工修改本地 DNS 为 8.8.8.8 的方式解决。处理后效 果/遗留问 题说明 是否影响 集团考核 否 故障原因 是否已在 故障池内 否 4、关于 12 月 27 日部分地市用户充值后余额提醒短信与实际不符的故障(蓝)查询代理是连接外围系统与实时帐务核心系统之间的纽带,外围系统通过查 询代理进行资金、余额、账单查询。查询代理目前部署架构是 2 台主机(上塘 与滨江主机,各 20 个进程,每台主机对外提供 3 个端口供外围调用),而外围 主要是 CRM 系统(网厅、IVR、短厅、帐管等)通过不同第 4 页 的接口调用,配置文件 mdb.prope

7、rties 配置查询代理调用的域名与端口,此文件分为 CRM APP、CRM 批量与帐管批量三份。2012 年实时帐务二期进行查询代理改造后,期间对查询代理连接进行优化 调整,相应外围客户端的调用配置信息也进行调整,但却忽略了上述 CRM 批量 与帐管批量配置信息调整,最终导致外围 CRM 批量与帐管批量调用上塘主机都 会失败。但由于外围查询有相应错误处理机制,遇失败后进行端口轮询 5 次重 试,若调用上塘主机查询失败后,会轮询调用滨江的查询代理,因此该错误一 直未显现。帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之 一。查询代理外围客户端众多,包括网厅、信息推送平台、华为

8、IVR、短厅/掌 厅、自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在 调用查询代理异常处理机制不一,存在不完善的地方,例如本次故障的帐管充 值短信下发模块,充值后需要查询实时账单进行模拟销账,获取用户余额进行 下发用户,但当调用查询代理实时账单查询失败时,程序会自动按照实时账单 为 0 来进行模拟销账,会导致计算得到的余额虚高,从而下发短信造成用户误 解。故障处理 回顾 12 月 27 日:12:59 总控台短信:【灰】充值提醒短信与实际余额不符;13:00 维护、账务开发、查询代理相关开发人员通过排查核实,发现充值入账 日志连 MDB 错误量很多,比 25日多很多,即使只计

9、算一小时的量也不是一个量 级(故障当天 1 小时有上万条报错,平时只有百来条);第 5 页 13:30 为避免故障升级,维护侧通知华为关闭充值提醒短信;14:30 开发确认前一晚上线的优化需求,关闭了外围查询失败重试 5次的机 制,改为一次;15:40 总控台短信:【蓝】超 60 分钟,升蓝;23:00 紧急上线查询代理外围客户端(包括 CRM,帐管)调用查询失败恢复重 试 5 次的功能。12 月 28 日:8:10 维护第二天上线跟踪发现问题依然存在,通知开发立即到现场,核实发 现 27 日紧急上线的程序只发布了 CRM EJB 集群主机,营帐批量后台进程主机未 发布,导致问题依然存在。10

10、:00 再次进行故障仔细排查,最终确认故障原因是由于 CRM 系统中调用查询 代理的配置错误,存在一定概率单次调用失败,并且此次上线取消了 5 次重试,从而导致外围调用查询代理错误,最终返回用户错误余额信息。13:30 紧急修复 CRM 系统查询代理配置文件,并对遗漏发布的营帐批量后台程 序进行补发布,通过重启相关进程后生成的充值短信恢复正常。13:30 由于 27 日为避免故障影响范围扩大,处理过程中通过删除统一短信平 台的相关模板而不进行下发,28 日晚通过恢复短信模板,并重启统一短信平台 后恢复。故障详细 分析及问 题解决 第 6 页 1、查询优化项目对查询代理异常时重试 5 次的机制进

11、行调整,是此次故障的 直接原因。在实时计费、按量计费项目过程中,一方面为有效减少查询代理负荷,并且进 一步减少帐务后台压力,确保实时计费用户加载能够按时完成;一方面为有效 加强查询代理调用错误日志梳理管控 端口入库,如果将每次重试的量也入库,会导致统计的日志不准确),项目组决 定对原有调用查询代理异常时重试 5 次的机制进行优化,在后台服务会持续异 常的场景下,如无来源标记、数据异常、计算服务异常、路由关系不存在等场 景下将重试 5次的机制删除,但是一来未考虑到查询代理的配置原因,二来在 设计的时候,场景未考虑充分,从而导致异常情况被扩大化,最终出现外围调 用无返回,加上外围调用组装机制不合理

12、,最终导致用户费用显示不准确。2、查询代理外围客户端配置存在历史错误,是此次故障的重要影响因素之一。查询代理是连接外围系统与实时帐务核心系统之间的纽带,外围系统通过查询 代理进行资金、余额、账单查询。查询代理目前部署架构是 2 台主机(上塘与 滨江主机,各 20 个进程,每台主机对外提供 3 个端口供外围调用),而外围主 要是 CRM 系统(网厅、IVR、短厅、帐管等)通过不同的接口调用,配置文件 mdb.properties 配置查询代理调用的域名与端口,此文件分为 CRM APP、CRM 批量与帐管批量三份。2012 年实时帐务二期进行查询代理改造后,相应外围客户端的调用配置信息也进行调整

13、,但却忽略了上述 CRM 批量与帐管 批量配置信息调整,最终导致外围 CRM 但由于外围查询有相应错误处理机制,遇失败后进行第 7 页 端口轮询 5 次重试,若调 用上塘主机查询失败后,会轮询调用滨江的查询代理,3、帐管充值下发短信生成模块异常处理机制不健全是故障的重要影响因素之 一。查询代理外围客户端众多,包括网厅、信息推送平台、华为 IVR、短厅/掌厅、自助终端、话费信使、余额提醒、帐管充值短信下发等等。各外围接口在调用 查询代理异常处理机制不一,存在不完善的地方,例如本次故障的帐管充值短 信下发模块,充值后需要查询实时账单进行模拟销账,获取用户余额进行下发 用户,但当调用查询代理实时账单

14、查询失败时,程序会自动按照实时账单为 0 来进行模拟销账,会导致计算得到的余额虚高,从而下发短信造成用户误解。故障解决 措施 1、完善外围查询接入管控,明确接口规范。针对本次故障,首先对帐管充值下发短信生成异常处理机制进行优化,如果查 询实时账单接口返回有问题,则不生成下发短信,从而防止用户收到不准确的 余额短信。此外,查询代理作为服务端,外围应用调用其相关接口,需加强接入管控,明 确接口规范,确保外围异常查询处理逻辑可靠,必须具备容错处理,针对本次 查询代理无返回的异常情况处理,需要梳理排查,尤其是涉及到资金相关、调 用量大、影响面广的渠道,需要优先进行核实。同时,查询代理还存在另一风 险隐患,由于外围对查询代理返回错误代码无法处理,因而查询代理约定出错 情况将返回 0,该问题同样存在隐患,后续需要协调外围渠道彻底改造。2、完善查询代理架构。第 8 页 查询代理作为连接外围系统与实时帐务的枢纽,需要进行框架优化,具备对外 5、关于 12 月 27 日客服平台系统运行缓慢的故障(红)6、关于 12 月 30 日全省部分用户通过充值卡充值未到账的故障(蓝)