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

浙江移动通信有限责任公司业务支撑中心 单查询接口调用异常，最终导致下发用户提醒短信不准确。通过调整查询代理客户端配置信息，并且紧急修复代码最终恢复 1. 完善外围查询接入管控，明确接口规范 针对本次故障，首先对帐管充值下发短信生成异常处理机制进行优化，对外围应用调用其相关接口，需加强接入管控，明确接口规范，确保外围异常查询处理逻辑可靠，必须具备容错处理。 2. 完善查询代理架构 查询代理作为连接外围系统和实时帐务的枢纽，需要进行框架优化，具备对外围吞吐量、调用来源、成功失败数、错误类型、关键业务耗时进行有效记改进措施 录，并且能够通过运维平台展现，最终达到可监可控，可视可分析。 3. 梳理查询代理异常场景，加强开发人员对于账务后台框架的培训 在BOSS账务开发组内进行BOSS后台框架应用开发规范的培训，针对查询代理返回错误的场景进行梳理，明确哪些错误是可以不进行5次尝试，哪些错误是需要用5次尝试来保证的。 4. 明确管理职责 明确系统优化室环境组为环境配置文件的责任部门，应用优化室优化组为业务配置文件的责任部门，杜绝类似配置文件历史措施的再次发生． 故障详细分析 用户充值后收到了充值提醒短信，充值提醒短信中的余额与用户实际的余额故障现象不符，由于查询实时费用超时返回为0，导致短信中的余额=用户充值之后账本详细描述 余额，而实际余额=用户充值后的账本余额-用户实时费用，即提醒短信中的余额虚高。 事件单号 开始时间（系统） 开始时间（业务） 故障影响系统 SD201312276938 12月27日12:59 12月27日12:59 帐管系统查询实时费用，批量业务查询用户实时费用 问题单号 恢复时间 （系统） 恢复时间 （业务） 故障影响业务 PM201312275564 12月28日20:00 12月28日20:10 充值下发短信 故障处理情况 ? 查询优化项目对查询代理异常时重试5次的机制进行调整，是此次故障的直接原因 在实时计费、按量计费项目过程中，一方面为有效减少查询代理负荷，并且进一步减少帐务后台压力，确保实时计费用户加载能够按时完成；一方面为有效加强查询代理调用错误日志梳理管控（要求将查询代理的调用错误日志按类型、端口入库，如果将每次重试的量也入库，会导致统计的日志不准确），项目组决定对原有调用查询代理异常时重试5次的机制进行优化，在后台服务会持续异常的场景下，如无来源标记、数据异常、计算服务异常、路由关系不存在等场景下将重试5次的机制删除，但是一来未考虑到查询代理的配置原因，二来在设计的时候，场景未考虑充分，从而导致异常情况被扩大化，最终出现外围调用无返回，加上外围调用组装机制不合理，最终导致用户费用显示不准确。 ? 查询代理外围客户端配置存在历史错误，是此次故障的重要影响因素之一 浙江移动业务支撑中心第17页

故障起因简述

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

查询代理是连接外围系统和实时帐务核心系统之间的纽带，外围系统通过查询代理进行资金、余额、账单查询。查询代理目前部署架构是2台主机（上塘和滨江主机，各20个进程，每台主机对外提供3个端口供外围调用），而外围主要是CRM系统（网厅、IVR、短厅、帐管等）通过不同的接口调用，配置文件mdb.properties配置查询代理调用的域名和端口，此文件分为CRM APP、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日紧急上线的程序只发布了CRM EJB集群主机，营帐批量后台进程主机未发布，导致问题依然存在。 10:00 再次进行故障仔细排查，最终确认故障原因是由于CRM系统中调用查询代理的配置错误，存在一定概率单次调用失败，并且此次上线取消了5次重试，从而导致外围调用查询代理错误，最终返回用户错误余额信息。 13:30 紧急修复CRM系统查询代理配置文件，并对遗漏发布的营帐批量后台程序进行补发布，通过重启相关进程后生成的充值短信恢复正常。

13:30 由于27日为避免故障影响范围扩大，处理过程中通过删除统一短信平台的相关模板而不进行下发，28日晚通过恢复短信模板，并重启统一短信平台后恢复。

故障处理回顾

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

浙江移动通信有限责任公司业务支撑中心 处理后效果/遗留问题说明 运维故障评估 故障 根源系统 是否影响 集团考核 否 故障原因是否已在故障池内 否 CRM系统 严重程度 □重大 □严重 □主要 ■一般 配置管理 系统 开发商 亚联 □客户响应室 需求管理 □业务管理室 缺陷管理 □业务管理室 架构管理 □系统规划室 测试管理 □开发管理室 □计费帐务室 需求管理 □业务管理室 缺陷管理 □业务管理室 架构管理 □系统规划室 测试管理 □开发管理室 □系统优化室 业支系统 □系统规划室 统一权限配置 软件质量 配置管理 统一产品配置 故障待改进点涉及科室 软件质量 ■应用优化室 （运行异常） 基础设施 基础保障 系统能力(架经分系统 □经营分析室 构、容量)问题 信安系统 □信息安全室 需求管理 □业务管理室 业支系统 缺陷管理 ■业务管理室 架构管理 □系统规划室 测试管理 □开发管理室 经分系统 信安系统 电渠系统 □经营分析室 □信息安全室 □客服中心电渠 软件质量 运维故障分析 1）告警 监控管理 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 【原因分析】 历史配置文件配置导致查询失败率高． 2）高可用保障管理 3）运维 操作管理 浙江移动业务支撑中心第19页

浙江移动通信有限责任公司业务支撑中心 【改进措施】□规范执行 □重复问题 □历史遗留问题 1、 明确系统优化室环境组为环境配置文件的责任人，应用优化室优化组为业务配置文件的责任人，防止类似配置文件历史措施的再次发生； 2、 针对本次查询代理无返回的异常情况处理，需要梳理排查，尤其是涉及到资金相关、调用量大、影响面广的渠道，需要优先进行核实。同时，查询代理还存在另一风险隐患，由于外围对查询代理返回错误代码无法处理，因而查询代理约定出错情况将返回0，该问题同样存在隐患，后续需要协调外围渠道彻底改造。 4）系统 基础平台问题 【原因分析】 【改进措施】□规范执行 □重复问题 □历史遗留问题 需求开发责任人 告警调整任务单号 新增/修改 新增/修改 任务单号 专题需要的资源 改进措施落实情况 ? 运维报告撰写人 故障责任小组 故障引入需求编号和名称 故障原因综述 唐艳芬，朱建波 改进措施落实监督人 开发故障评估 蒋健 需求维护跟踪人 告警调整人 预案编写人 报告撰写人 稽核人 专题发起人 故障后续改进 故障所属域（CRM/BOSS/渠道） 优化需求 告警监控 故障预案 高可用保障 数据稽核 疑难问题 优化需求编号 告警调整版本号 预案名称 优化分析报告名 数据稽核任务 专题名称 开发故障分析 历史原因 故障影响范围 全省 查询代理优化需求上线造成部分外围实时账单查询接口调用异常，最终导致下发用户提醒短信提醒余额与实际不符。通过调整查询代理客户端配置信息，并且紧急修复代码最终恢复。 浙江移动业务支撑中心第20页