Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3621627
  • 博文数量: 338
  • 博客积分: 2173
  • 博客等级: 上尉
  • 技术积分: 7765
  • 用 户 组: 普通用户
  • 注册时间: 2011-08-24 17:26
  • 认证徽章:
个人简介

2018聚焦团队目标,再创佳绩

文章存档

2018年(3)

2017年(34)

2016年(49)

2015年(53)

2014年(47)

2013年(72)

2012年(80)

分类: IT职场

2018-01-22 22:17:24

忙忙碌碌的一年,已经接近尾声,2017是忙碌的一年,也是收获的一年,这一年90%以上的时间都花在了工作上,有的月份加班都加上二十五六天,为此也付出了很多,摊子铺的太大,弄得自己非常焦虑,失去了很多陪伴家人的机会,压榨了与家人团聚的时间,想到此处,也时常自责自己的自私、没有情趣。借此,总结一下2017年工作中,比较重要的10件事,以缅怀那失去的美好时光。

一、核心篇
TOP1:核心交易负载不均衡,导致其中某一个AOR交易量是其他AOR的2倍左右,所在系统的CPU负载过高(超过80%)、交易处理时间由原来的200多毫秒增加到500多毫秒。
通过优化核心CICS COR负载均衡参数,目前核心交易负载基本均衡,交易响应时间保持在正常范围之内。同时通过该问题进行总结分析,得出如下结论:在维持现有业务模型及业务逻辑不变的情况下核心生产系统每个AOR实际每分钟最大处理交易的笔数大约在5000到6000笔,也就是说目前核心交易系统,每分钟最大处理能力约3万笔左右。
TOP2:核心交易缓慢,发现核心所有交易在时间上随机性的出现突然变慢现象且整体变慢持续时间约在5-10秒左右。
通过结合BPC、大数据应用日志平台每笔交易的处理时间以及NPM网络抓包的数据,细粒度分割到交易的每一个处理阶段,发现交易慢在数据落盘阶段,最终定位为同城光纤瞬断导致。通过对该问题的分析总结,对于性能问题,目前我们的工具已经采集到所需的数据,但对于根因分析时还需要投入大量的人力以及依赖专家的知识技能,才能找到问题的root cause。对于如何把专家的技能固化下来,进行工具化、平台化,打造一个专家系统,以帮助我们一般运维人员再遇到此类具有挑战性的问题时具备资深专家的能力,能够快速、高效定位与解决问题。我觉得这个工作是还有进一步挖掘的空间,尤其是由性能导致的生产问题这个领域。
TOP3:核心数据库交易日志被异常进程长时间持有导致数据库交易日志满,CICS force Purge后没有正常退出,导致后续所有交易无法处理。
通过调整数据库参数log_span彻底解决,关于该问题的反思,我们对数据库的理解还不够深入,尤其是在数据库的自我保护机制、监控的盲点以及容量评估上,要再下一些功夫。2018年,计划在数据库、中间件部署方面建立标准与规范并推动落地,争取由被动运维向主动运维进行转变。
TOP4:核心读写分离投产
核心读写分离项目的投产过程,就像为正在飞行中飞机更换发动机的过程,其存在的风险与压力,只有参与其中的人才能够体会。该项目投产后,联盟CBUS系统由原来的单核心变成双核心,原来核心无法支撑的业务,现在具备了支撑能力、丰富了联盟核心系统的业务功能。
目前核心备库与主库延迟主要发生在批量阶段,在批量时备库最大延时90s,最大数据GAP 220MB,其他时间阶段基本零延迟。虽然核心备库已经顺利投产,但是还有进一步优化的空间。2018年核心备库方面,第一个要做的工作:优化备库replay only window问题,在查询节点部署探测交易,捕获异常后发起探测交易,将业务影响降到最低;第二个工作,备库接管主库的预研性工作。
二、次核心篇
TOP5:联盟ESB集群化改造及ESB系统从小机迁移到x86平台项目
通过ESB集群化改造,实现了ESB应用的可横向扩展及去小机化。在迁移后发现数据库内存不足,借助运维窗口,停机扩容解决,有效保证了系统的稳定运行。联盟企业服务总线从小型机迁移到x86平台集群化改造工作的顺利完成标志着联盟企业服务总线应用具备了由原来只能纵向扩展变为可横向扩展的能力。对投产后的系统例行巡检时发现数据库所在服务器的内存不足,通过及时扩容保障了系统的稳定运行,同时也暴漏了对系统容量评估方面还有提升的空间,后续尽量联合研发、应用、主机及测试人员一起参与容量评估的过程中来,从业务、测试等视角为容量评估提供数据支撑,在评审阶段规避此类问题。
三、外联区篇
TOP6:XBUS应用内存泄露
通过对系统性能数据汇总,趋势分析,发现联盟外联区XBUS应用程序大约每隔3个周左右,内存将会耗尽。后续通过编写脚本向下钻取应用进程数据定位到应用程序gaps存在内存泄露问题。通过跟踪分析其他使用到gaps平台的应用如:二代支付、XBUS联机、第三方支付及批量平台也都存在不同程度类似的内存泄露问题。
与coding沟通,短时间内无法解决,为保证系统的稳定运行,目前通过定期重启方式规避此类问题。
TOP7:XBUS带业务切换演练
这是联盟第一次带业务的,模拟真实故障场景的切换演练。在演练过程中发现了只有在带业务切换过程中才能发现的一些问题,并将发现的问题进行跟踪,责任到人,限期整改。此次演练取得了良好演练效果,进一步提高了XBUS业务系统的健壮性。因为此次切换演练与之前的场景存在较大的差异,所以这项工作对于系统软件组来说也算是2017年标志性的一件工作吧!
四、电子银行篇
TOP8:电子银行数据库服务器因系统资源耗尽导致数据库集群重构
通过紧急扩容及重启数据库后解决,通过该问题可以反映出,对系统容量评估的重要性。计划2018年数据库监控工具投产后,实现数据库负载趋势化分析,建立数据库运行健康状况关键指标,根据历史性能数据开展线上系统容量评估、数据库管理及优化等工作。
五、数整报表篇
TOP9:多家成员行查询报表锁内存经常耗尽及查询报表乱码问题分析
随着联盟数整报表系统数据量的增加,由于前期WAS部署配置没有统一的标准与规范,WAS访问数据库的隔离级别设置过高导致应用消耗了大量数据库内存资源,最终导致数据库的并发处理能降低,应用报表异常。通过调整WAS的隔离级别解决。
由于外围系统与核心系统字符集不统一,核心在接受外围上送过来的某些生僻字时,没有正确存储该字的编码,导致核心再将数据下档给数整后,数整报表在结果汇总展现时出现乱码,通过修改JVM字符编码解决。
以上问题说明了我们部分系统的一些参数配置还有近一步优化的空间,后续我们计划在中间件部署管理方面制定规范与标准,以保证生产系统稳定、高效的运行。
TOP10:联盟数整数据库故障处理与反思
联盟数整数据库服务器今年宕机3次,由于系统宕机导致数据库在线日志损坏一次,故障修复时间长达6个小时。除此之外,服务器的每次宕机导致数据库在系统被备机接管后的crash recovery阶段长达约1到2个小时,也就是说应用长达1到2个小时,无法正常访问数据库。
对于关键系统如何保证数据库不因系统软件、硬件、存储等故障而中断服务?如何提高联盟关键系统的健壮性及业务连续性?如何保证数据库在产生逻辑坏页、坏块后快速恢复业务?那么建立数据库维度的容灾、高可用机制也许是保证联盟系统业务连续的可行性方案之一。2018年计划对Oracle ADG技术、DB2 HADR技术的HA功能预研。

阅读(2354) | 评论(1) | 转发(0) |
2

上一篇:wireshark分析ip分片

下一篇:没有了

给主人留下些什么吧!~~

gsbtsb2018-01-28 11:04:32

阿斯顿rgbjjvvxxjrrtthc

评论热议
请登录后评论。

登录 注册