版權聲明：本文為神州靈云作者的原創文章，未經神州靈云允許不得轉載。

本文作者：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解析，讓掃碼收單業務處理變得緩慢；最后通過調整操作系統配置，取消源端口復用，徹底解決了問題。

本例中，從發現問題->定位問題->解決問題的完整過程，充分體現立體化監測方案的優勢，由業務建模監測整體業務健康度，發現單筆極慢交易，追蹤業務調用邏輯，結合全量會話分析驗證問題，排查會話交互最終定位問題根源，徹底解決業務響應緩慢的問題，切實提升核心業務的整體運維能力。

總結

以上是生活随笔為你收集整理的海空联动立体化监测简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。