一起话单业务量下降问题的排查过程

      【文章摘要

最近,某局点支持人员反映某模块重启之后话单业务量下降,希望研发人员帮助查找问题原因。

本文对该问题原因的查找过程进行了详细的介绍,为相关软件问题的分析及解决提供了有益的参考。

一、问题描述

在某局点,有一个软件系统实现话单的生成功能。某天,该局点的现场支持人员发来邮件,反映现场某话单分拣模块重启之后生成的话单的量较之前有大幅度的降低。其邮件中表达的意思有这几个:

(1) 现场人员只是将该模块重启了,并未修改任何配置。

(2) 重启之后模块(图1中的话单分拣模块A)生成的每个话单文件的大小只有重启之前的几十分之一,下降得相当的厉害。

(3) 在现场还部署了另一个相同的话单分拣模块(图1中的话单分拣模块B),也进行了重启操作,但其生成的话单的量并未下降。

二、现场部署图

收到邮件之后,我们迅速展开了对问题的排查。在排查问题之前,我们了解了现场各个模块的部署情况,如图1所示。

图1 现场部署图

三、问题原因初步分析

我们请现场支持人员返回了话单转换模块、话单分拣模块A和话单分拣模块B的日志及相关的话单文件。在寻找具体的原因之前,我们很纳闷的是话单分拣模块A和话单分拣模块B是完全一样的,为什么一个有问题而另一个没有问题?我们基本上排除了话单分拣模块A的程序有问题的可能性,转而寻找其它方面的原因。

话单分拣模块A的程序处理的大致流程如图2所示。

图2 话单分拣模块A的程序处理流程

从图2可以看出,话单分拣模块A要将从源文件目录中扫描到的文件中的记录进行一定的筛选,然后将满足条件的记录按照特定算法写入结果文件中。图1中的最终话单A即是结果文件。

为了准确地定位问题原因,我们恢复了现场的环境,即采用与现场一样的程序版本、配置和数据库环境。我们根据现场返回的日志,选取了特定时段的源话单文件来运行,发现生成的最终话单与现场生成的最终话单是完全一样的。这进一步排除了程序有问题的可能性。

那么,问题原因到底是什么呢?

四、问题定位

既然程序没有问题,那是不是源话单中满足分拣条件的记录本来就变少了呢?我们详细查看了配置文件,里面涉及到分拣条件的配置如下:

FieldFilter=(11:4),(11:7),(11:8),(11:9),(11:10),(11:11)

其意思是只有源话单的每条记录的第11个字段的值等于4,7,8,9,10,11时,该条记录才能够被挑出来生成结果话单,否则会被过滤掉。

我们在重启之后的源话单文件中查询了一番,发现第11个字段的值等于4,7,8,9,10,11的记录确实很少。“巧妇难为无米之炊”,既然源头都少了,那么结果变少就不足为奇了。

我们又在重启之前的源话单文件中查询了一番,发现第11个字段的值等于4,7,9,10,11的记录数与重启之后对应的记录数相当,但第11个字段的值等于8的记录数明显比重启之后该字段为8的记录数多很多。难道这就是话单业务量下降的原因?

我们马上联系现场支持人员查看第11个字段的值等于8的记录的产生过程,发现确实是该过程异常导致源话单中满足筛选条件的话单记录减少,最终导致了整个话单业务量的下降。

现场进行相应的操作之后,第11个字段的值等于8的记录又出现了,话单业务量也就逐渐达到了重启模块之前的水平。

五、总结

通过本次问题排查,我们总结出的经验有以下几个:

(1) 系统出问题的地方并不限于最直观表现出现象的模块。当我们发现“认为有问题”的模块无问题时,应该着手排查其上游模块,直到查明问题的原因为止。

(2) 软件是程序、文档和数据的集合。在排查问题的过程中,我们不光要查看程序代码,对于程序用到的配置文件等,也要细细查看。

(3) 为了排查程序问题,我们要尽量掌握比较全面的信息(包括程序日志、数据库信息等),这样有利于复现问题,最终定位问题。

吴军老师在《文明之光》一书中说:“办法总比问题多”。确实,只要我们善于总结,善于分析,那么任何程序问题都是可以解决的。

(本人微博:http://weibo.com/zhouzxi?topnav=1&wvr=5,微信号:245924426,欢迎关注!)

时间: 2024-10-05 05:32:01

一起话单业务量下降问题的排查过程的相关文章

电信计费业务:分话单

欠费问题一直是电信企业困扰的问题.最开始的时候,电信企业采用后付费的模式,也就是每个月计算一次费用,如果在一定期限内没有交清费用就停机.移动业务发展后,由于用户可能因为当月的费用较多而停止用这张卡,所以就采用了每次使用业务就计算一次费用的模式,如果计费完的余额不足,就发起停机.后面发现,单次使用业务也可能产生很大的费用,(特别是数据业务),就有了在线计费(实时计费),每次使用业务前都会判断余额,只预留出可以使用的时间(或者流量),在用完余额后,就会中断业务的使用. 在准实时计费和实时计费之间,实

话单字段!!!! 找对方法很重要!!!!

话单字段!!!! 找对方法很重要!!!!

解Bug之路-记一次中间件导致的慢SQL排查过程

解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似

记crond导致备份失败的排查过程

今天上班的路上收到一条短信,显示线上所有实例备份都失败了.备份失败是大事,于是到公司的第一件事儿就是排查备份失败的原因. 这两天迁移了数据库管理平台,当然涉及到数据库备份功能,备份失败肯定和平台迁移有一定关系,我们先聊聊线上备份方案: 目前线上的备份方案是: 1.有一个前端页面可以配置备份任务 2.备份任务配置好了,会自动刷新到系统的crontab定时通过ansible远程执行. 排查过程: 1.查看备份报告,显示所有的备份文件大小都是0,初步估计是备份失败了而不是元数据没有更新的问题. 2.去

小问题不简单,一个无线故障的排查过程

本文不是为了说明解决了多难的问题,而是提供了查找app连接服务端的问题的几种解决问题的思路和方法 研发人员反映有个手机app业务在3G网络下刷新不了,是连接的测试环境的服务,通过办公网和wifi正常. 研发认为可能是在3G网络或者是服务器所在IDC机房问题,问题出现有一段时间了. 真这么神奇?专治疑难杂症30年的我得查查- 找来一台andriod手机,root过的,安装ssh终端模拟器app,希望直接连接网络进行测试. 发现能ping ,说明网络是通的,不能telnet服务端口. 想通过curl

一次线上页游服务器响应缓慢排查过程

最近线上一组服务器玩家反馈响应缓慢,记录下排查过程. 1.使用top命令查看服务器负载情况, top - 15:59:37 up 26 days,  3:42,  6 users,  load average: 2.98, 2.74, 2.70 Tasks: 180 total,   1 running, 167 sleeping,  12 stopped,   0 zombie Cpu(s):  8.1%us,  2.4%sy,  0.0%ni, 65.7%id, 23.6%wa,  0.0%

记一次erlang 节点CPU严重波动排查过程

新服务上线后观察到,CPU在10 ~ 70%间波动严重,但从每秒业务计数器看业务处理速度很平均. 接下来是排查步骤: 1. dstat -tam 大概每10s一个周期,网络流量开始变得很小,随后突然增大,CPU也激增. 网络流量变化和从性能计数器结果上并不符合,服务相关业务较为复杂,先找出那个业务占用网络流量. 2. iftop 找出流量最大的几个目标IP,并且周期的流量变为0随后激增. 通过IP 知道是外部http接口地址,因为接口调用是异步进行的,性能计算是执行开始记录的,而不是结束记录,因

mysql error code '1064' 排查过程

下午自测代码,在这个update上卡了一个半小时,大大的降低了开发的生产力,把排查过程发出来,好的士兵不会掉进同一个陷阱.先把异常堆栈打出来. 2016-03-28 17:23:38.420 main DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory:463] - Finished creating instance of bean 'Sybase' 2016-03-28 17:23:38.42

一起数据库中过期用户数据堆积问题的排查过程

[文章摘要] 对于使用数据库来存放大量用户的软件来说,过期数据的清理机制需要慎重设计.如果设计不当,则会导致数据的误删除或清理不完全. 本文对某数据清理模块因参数配置不当而导致的过期用户数据堆积问题进行了详细的分析,为相关软件问题的分析及解决提供了有益的参考. 一.问题描述 在某软件系统中,为了让不同种类的用户享受对应的服务,引入了一个信箱服务等级的概念,即不同服务等级的用户具有不同的权限."一分钱,一分货",对于运营商来说,高服务等级的用户收取高的资费,提供高质量的服务. 为了维护不