短信系统故障分析_郭利山.docVIP

短信系统故障分析 短信系统故障概述 公司短信平台一共有四套独立的短信系统对应四个运营商，服务器较多，需要保障的东西较多。由于公司的性质，对运维部门的要求也比较高。 一直以来技术运维部不断完善监控机制监控方式方法以便更好的对短信系统提供保障，不过短信系统就算再良好的运行 发生故障也是不可免的， 在这里主要讲的是对短信系统故障进行相应分析，降低短信系统故障发生率，提高短信系统保障能力，加深运维人员对短信系统的理解。 短信系统故障的发现主要有下列三种情况 检查中发现 统计应用过程中发现 客服投诉渠道发现 后两种渠道发现说明短信系统的监控体系可能存在着不足或是在监控的态度、频率上存在不足 对短信系统故障的运维要求 1.避免可以免的故障 2.及时发现故障 3.快速有效解决故障 4积累经验使短信系统更稳定的运行 下面对短信系统故障进行详细的分类分析 故障类别一 外部类故障 我们的短信系统是通过短信网关（SPGW）与运行商网关（ISMG）连接，实现MOMT短信上下行。为了规范sp行为 运营商一般都有管理平台对各sp短信进行管理。我们与运营商的集中网关进行连接，运营商集中网关则与其各省网关进行连接，最终通过各省短信中心与用户实现短信互动。 从上面这个图可以看出各个环节都有可能出现短信故障，只不过故障的影响范围、故障的类型表现不一样。下面要详细讲的短信系统外部类故障，几乎都是图中某个环节出现了问题所致。 无MO、MT类故障 这种类型的故障是很严重的短信故障。表现形式很多 举例详细说明： 网关无任何上行 从网关跟踪测试观测没有任何上行 这种故障应该能及时快速的发现 通过检查 统计等很多种途径都能发现 遇到这种故障 首先应排除网路问题 检查内部短信系统 察看与运营商网关连接情况 如这一切正常 应及时与运营商联系解决 此种错误多为对方网关问题 网关下行全部失败 通过监控或统计可及时发现，该故障表现为全部下行在网关上均为ack失败，我方系统非法更改或运营商网关故障或运营商系统进行升级更改我方未做相应更改都可能导致该故障。解决办法是对短信系统进行详细检查，如未发现系统异常，应与运营商进行沟通确认有无系统更改，及时作相应调整。 某省无上行或下行全部失败 通过监控或统计发现某省上下行异常而其他省市正常。这种情况下先通过测试手机进行测试，像西藏等人口稀少省一两天没有上行是很平常的，如测试手机测试未回复，应与市场部门沟通联系运营商解决。如有该省短信技术部门电话 可电话联系咨询测试解决。 某手机号上下行异常 客服经常会接到用户投诉 说上行未回复 经确认该用户所在省市短信上下行正常 可根据该用户所参与业务详细分析解决 2．Ack、状态报告类故障 Ack失败问题 Ack相当于我方网关给运营商网关发送的短信数据包的直接响应，跟状态报告是有区别的。Ack失败表明我方给对方放送的短信数据报不符合对方网关要求或与对方网关流量限制等有关。比较常见的故障是大型活动用户大量参与 下行信息流量巨大 ack失败可能会快速增加 这要与运营商网关设置有关 需要与运营商沟通解决 状态报告失败高问题 状态报告反映了下行信息的状态，一条下行信息成功与否、失败原因全通过状态报告来反映。比较常见的故障是收不到状态报告或状态报告回的慢，这种情况联通出现的比较多，这主要是因为联通系统不太稳定。状态报告失败率过高，这里主要指的是单条点播的失败率，定制类下发由于无效用户多状态报告失败高是正常的。单条点播的成功率一般都在90%以上，单条点播失败率高从以往来看主要有两个原因一是有用户大量群发 二是有某些省份该点播业务异常造成 如没有开通该点播业务等。 故障类别二 内部类故障 短信应用系统故障 网关故障 在网关服务器上这要运行着网关和入库程序 比较常见的网关故障是入库问题 网络或数据库异常很可能导致入库出现异常 会导致所有话单入不到数据库中 在巡检中应注意观察入库程序是否有大量无效话单，如统计过程中发现数据少时应察看入库程序。 SWTICH故障 Switch主要负责短信由网关分发到运行库、运行库下行信息汇总到网关，所以switch上的路由配置很关键 路由配置时一定注意源地址和目的地址。 业务模块 业务模块可通过GFI监控页面进行察看，当业务模块意外关闭是应及时发现启动 数据库故障 这是最常见的短信系统故障，通过检查主库的log_err表、网页检查页面、短信下发配置、客服等多种渠道可发现数据库故障。数据库发生问题时会导致同步、下发、查询等一系列问题。数据库出现问题目前比较常用的解决办法就是重启。重启完需检查主库JOB,重启web服务器的tomcat。 计算机硬件或网路故障 服务器和网路故障对短信系统的影响很大，我们在查找短信故障原因时应先对相应服务器进行检