版权声明：本文为神州灵云作者的原创文章，未经神州灵云允许不得转载。
本文作者：Tony
对于核心业务保障是所有IT运维的重中之重，各种监测手段都会加之其上，编织起一张监测的大网，力求不遗漏任何蛛丝马迹；但是来自主机、网络、数据库和应用等层次的信息视角相对孤立，缺少业务流程和用户使用体验层次的有效关联，难以建立统一监测立体覆盖，容易造成IT运维的盲点和漏洞。
通常用OBASHI 方法论评估核心业务运作的六个“层次”，其中前两个层次表示核心业务运作的方式，后四个层次表示支持这些运作的 IT 构架：
- Ownership（利益相关者）
- Business Process（业务流程）
- Application（应用程序）
- System（操作系统）
- Hardware（硬件）
- Infrastructure（基础架构）
对于承载核心业务的IT构架，按照OBASHI方法论进行监测和运维保障，已经普遍实现：机房实时监控、服务器及各类设备监控、基础网管监控，中间件及数据库监控、流程及CMDB的建设；但是缺乏与上两层次的有效联动，对于业务流程、用户体验、代码性能的监控普遍缺失，一旦出现业务性能问题，难以从上往下快速排查，定位故障原因费时费力。
神州灵云通过海空联动立体化监测方案，紧紧围绕核心业务建模分析，从顶层开始建立对业务运行过程的全面监测，直观反映用户使用感受，让业务性能问题从发现到定位及最终解决都变得事半功倍，极大提升IT运维的效率；接着我们通过实例来展现立体化监测的威力
<实例>
近年来随着互联网金融业务快速发展，支付宝和微信结算作为核心组成部分是运维重点，尤其商铺的扫描收单业务直接影响到终端客户使用感受；但是最近一段时间，每天都有客户反映扫描支付回应缓慢，主要集中在微信收单上，需要定位问题尽快排除故障现象。
首先我们通过核心业务建模，对扫码收单业务进行业务健康度分析，监测正常、容忍、失望、错误和失败业务数量的占比:
找出失望业务，对单笔交易跟踪分析，确定失望的原因:
这笔失望的业务，原因是响应时间达到10663ms:
检索全量会话数据，通过业务会话的唯一标识BILLCODE找到这笔交易，确认在后端服务器之间数据交互环节确实存在极慢响应时间:
查看该业务的逻辑调用关系图，发现每笔业务处理过程中后端服务器都会通过互联网专线调用一次前端Api.weixin.qq.com和Tpay.95516.com的数据；分析调用微信和银联数据的交互过程，发现从请求到获得数据，响应时间分别是289ms和253ms，排除网络故障或者对方因素导致调用数据缓慢:
进一步对全量会话进行时间排序，发现每次调用数据同时会经历一次DNS解析:
原来每次调用Api.weixin.qq.com和Tpay.95516.com数据，建立连接之前都会从DNS获得域名对应的IP地址:
分析DNS数据，发现由于服务器系统采用源端口复用，导致第一次DNS解析不成功，相隔5秒后再次请求DNS解析，让扫码收单业务处理变得缓慢；最后通过调整操作系统配置，取消源端口复用，彻底解决了问题。
本例中，从发现问题->定位问题->解决问题的完整过程，充分体现立体化监测方案的优势，由业务建模监测整体业务健康度，发现单笔极慢交易，追踪业务调用逻辑，结合全量会话分析验证问题，排查会话交互最终定位问题根源，彻底解决业务响应缓慢的问题，切实提升核心业务的整体运维能力。
1079
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
