APM 深水區：構建連接運維與業務之橋

本文整理自 2019 年 QCon 北京站聽雲 CTO 趙宇辰主題演講《APM 深水區：構建連接運維與業務之橋》。

有關AIOps的話題，其實在之前的QCon大會上已經分享過很多了，但今天，我想從另一個角度來分享：運維是服務於業務的，如何在運維和業務之間搭建一個橋樑呢？

我的分享大致會分爲四個部分：

• APM現狀和痛點；

• 什麼是APM深水區；

• 技術原理；

• 實際案例。

APM現狀和痛點

上圖是一個比較經典的運維部署架構，其中的真實用戶是基於APP、網頁或者是小程序，並通過網絡設備訪問後端，而後端包含有一些基礎架構。這些架構之前可能是建立在私有云或者自建IDC機房，現在有很多是構建在公有云之上，例如Docker、Kubernetes等。另外，還有各種各樣的應用程序，例如Nginx、Apache Tomcat等；不同的編程語言，例如Java、.Net、Go、Python等；多種數據庫，例如MySQL、Oracle以及其它NoSQL、NewSQL。

APM是做什麼的呢？第一代APM主要做的是主動撥測，例如企業可能會在全國各地布很多點，模擬用戶操作，通過網絡設備訪問真實的後臺系統，測試系統的可用性。後來，模擬用戶操作已經不能滿足我們的需求，能不能涵蓋真實的用戶場景呢？所以，我們通過SDK的方式來訪問後端基礎架構，看看在真實用戶場景下是否會出現卡頓、白屏、崩潰等異常情況。現在出現了很多小程序，其本質上也是HTML 5或JavaScript，所以也可以用類似的方式來測試。

以上主要做的其實是用戶體驗的監控，而現在APM不僅需要監控技術，也要監控基礎架構，例如針對不同的編程語言，插入Agent，抓取調用關係、事務等，形成端到端的打通，實現全鏈路監控。當我們進行一個操作時，可以獲取到響應延時，如果慢了的話，還可以知道是前端慢還是後端慢。

我一直在思考一個問題——運維中出現的問題是平等的嗎？更具體一點說，每天遇到的海量報警都一樣重要嗎？這些報警是否也遵守2/8原則？哪些警報是真正緊急、影響業務的？被影響的業務有哪些？是否爲核心業務？如何來補救呢？……

基於以上問題，我們發現在做端到端全鏈路監控時，運維和業務還是割裂的。例如，從運維角度看，系統的響應時間和錯誤率上升了，但是無從得知真正影響的是哪些系統。從業務角度看，雖然可以看到一些指標下降，也會接到各種用戶投訴，但是他們不知道用戶不滿意的真正原因，真正投訴的是哪些系統、哪些報警。而從公司角度看，一個問題可能橫跨多個部門，所以很難去衡量企業的損失。

在互聯網場景中，業務方經常會看到一些指標下降，例如轉化率、收入、活躍用戶等，他們不知道原因，所以將問題反饋給運維部門，而運維部門查看了網絡、CPU等，往往會發現一切正常。通常，想要確定出現某個問題的真正原因，需要經過多個部門，例如運維、研發、網絡，甚至包括它們的子部門，而在這期間，公司的業務和健康狀況時刻都在受到影響。

在企業場景中也是如此，例如審批系統或辦公系統響應慢，點擊“提交”之後需要等很久，這會直接影響到業務方。而從運維的角度來看，可能OA、網絡、數據庫、吞吐量、CPU等都是正常的。

出現這些情況的關鍵原因就是缺少IT和業務之間的橋樑，所以，今天我們就講講如何在IT和業務之間架構橋樑，以解決企業痛點。對於運維來說，很多時候IT是一個成本中心的角色，但我們不希望它僅僅是個成本中心，而是能夠走向業務，擁抱業務，真正成爲企業的核心力。

什麼是APM深水區？

之前運維的目標是保證系統穩定安全，儘量不出事，能夠讓客戶用起來。而現在，我們能不能做得更好一點呢？從運維走向運營，關注用戶在使用系統時的感知、體驗，關注運維和開發是否能夠實現快速交付。

這就需要我們在運維和業務之間構建一座橋樑，在系統的左側顯示運維相關的場景，例如錯誤列表、追蹤結果、前端用戶反饋、敏捷度等等。而在系統的右側展現業務的角度，量化DevOps敏捷的成熟度，顯示幫助業務做了哪些事情。例如，之前解決一個問題可能需要一個小時，但是現在只需20分鐘，節約的40分鐘對於業務有何種程度的提升。

業務運維具體是怎麼做的呢？我們認爲可以分幾步走：
首先是業務指標監控，將業務和IT關聯起來，當我們在進行一個操作的時候，可以關聯到它的調用關係，如果出現異常情況，業務方可以定位到這是什麼操作，具體關聯到哪些IT異常。假設響應時間太長，那麼就對響應時間進行切片，獲取詳細分解。這樣，我們就建立了一個業務和IT比較初級的溯源。

其次，我們可以做一些業務級的告警。以前只能看到系統的整體錯誤率，即當天系統有多少異常、報警，但是無從得知業務的可用性和健康狀況。在很多情況下，IT系統可能沒有問題，但是業務性能已經下降了很多。單從CPU或硬盤等一個角度的信息，很難衡量業務的可用性及健康狀況，所以我們要結合積累的所有數據來衡量，從業務層面反饋一些變化。另外，對於一些業務指標的下降，我們能不能提前做一些預警，通過業務信息來反推IT信息。

第三，當我們在做業務追蹤時往往會看到用戶的投訴，比如某個用戶投訴響應太慢了，一般情況下，用戶都會有一個唯一標識的用戶ID，根據這個ID可以在系統中查看到用戶進行了哪些操作，每個操作調用了系統的哪些關鍵環節，可以快速定位到具體的問題。如果是訂單系統，也可以根據唯一標識符抓取到詳細信息。

第三，以前做IT監控時，我們看到的只是一個事務，IT請求發過去，不超過幾秒，這個事務就返回來了。但是當業務和IT關聯起來，就不再只是一個簡單的、幾秒鐘的事務，而是一個業務流。如果是做貸款申請，申請提交之後，後臺收到申請會有貸款審批員進行審批，而審批過程可能需要跨部門，最後由放款員來決定是否能夠放款。貸款申請的業務流歷時多天，橫跨多個不同的業務應用系統，把整個業務串聯起來。從業務角度來看，業務流關注的不再是一個事務的好壞，而是整個業務流程的好壞。

最後，結合所有的信息，我們可以做業務上的刻畫。在不同的企業場景中，使用的度量單位也不盡相同，用戶發生的錯誤、業務的可用性等等都需要刻畫。

運維+AI已經有很多老師分享過了，也有很多企業在實踐，但是我希望能夠在此基礎上加上業務信息，真正做到自動化，解決實際的用戶體驗問題。當我們能夠把積累下來的IT數據和業務數據關聯起來，那麼在很多情況下就不需要人工做判斷，而是可以實時、自動的發現潛在的IT系統瓶頸，甚至是業務系統瓶頸。

發現業務瓶頸之後，我們能否結合相關數據一鍵定位到潛在根因，例如網絡訪問出現問題的原因可能是河北某個地區的某個運營商出現問題，又或者是某個訂票網站與第三方的對接出現問題，導致一小部分用戶體驗受到影響。傳統做法是根據經驗判斷，或者通過大量的檢索和推理來做根因分析。那麼，現在我們是否能夠根據數據及特徵自動找到潛在根因。

技術原理

如果把運維和業務結合起來，確實能夠提升企業效率，幫助運維再上一層樓，但是如何去構建運維和業務之間的橋樑呢？所以，我想和大家分享一下我們的技術原理。

APM的原理是什麼？一般來說，APM有幾種不同的方案，第一種方案是在代碼中進行自定義，當有方法要實現時打入日誌，通過日誌進行總結或計算。這種方式的劣勢在於需要改代碼，如果是新加入公司的同學，往往會漏掉相應的代碼規範，那麼系統就很難總結信息。另外，因爲打入的日誌是非結構化的，日誌也會不停變化，隨着時間推移，APM監控的系統和現在的系統可能不一樣了。

另一種方案是字節碼技術，以Java、.Net等虛擬機語言爲例，BCI技術的優勢在於不需要進行任何代碼級的修改，可以利用Java機技術自動獲取信息，並且可以將得到的Class文件進行變換，並且在變換時添加想監控的東西。如果是針對C語言、Go語言等編程語言，可能還需要去做一些埋點。

一般來說，我們會在虛擬機內部Load 這個Class，獲取性能數據，然後再把它打入到Class中，當加載Class時，就可以把想要的代碼替換到原來的文件中，這就是數據獲取的原理。

除了性能數據，我們還需要獲取業務數據。如果是在前端，可以通過HTTP請求的URL參數或者Header去獲取。前端業務數據比較好獲取，如何把後端業務數據也獲取到呢？舉例說明，假設有個Product類，每個Product有個ID，在Web Service層有個調用方法是get product by Order，根據Order的ID獲得相應的Product。其中，方法的參數、Order ID、Product類都可以通過BCI技術獲取。另外，如果它有返回值string，那麼我們可以通過方法的參數或返回值獲取。這樣，通過程序調用的業務信息都可以利用同樣的方式獲取到。同時，這個方法中的Product是個Object，不是個類，那麼可以通過虛擬機的技術獲取到，進行一些簡單的數據聚合，形成業務視角。

在構建業務和運維之間橋樑時，也會遇到很多挑戰。

第一個挑戰是全面數據獲取能力。我相信每個團隊、每個系統都多多少少會有數據獲取的能力，但是如何把前端、後端、數據庫等所有數據都全面獲取到，這是一個難點。

第二個挑戰是全量獲取數據能力，這比第一個挑戰更難。我們花了一年時間去重寫了Agent架構。爲什麼這樣做呢？因爲我們在做業務運維時發現，這和傳統APM性能不一樣，傳統方式可以接受數據抽樣，抽樣10%、20%就可以在重大事件發生時，體現出相應的異常和錯誤。而業務運維如果做抽樣的話，那麼只能取得部分數據，無法覆蓋到所有受影響的用戶，所以只能獲取全量數據，而這對於前端和後端的壓力是非常大的。重寫之前，我們調研了很多探針架構，發現它們都無法支撐，所以我們自己重寫了一個新的探針架構。對比新舊版本，我們發現，全量數據獲取的效率已經高於以前抽樣數據獲取的效率，時間更省，效率更高，獲取的數據更全。

第三個挑戰是數據處理、分析能力。因爲獲取到的是全量數據，所以信息量很大，對數據處理和分析的能力提出了挑戰。業務數據存在數據庫中可能只有一行，但是對於運維來說，這一行數據可能橫跨多個調用鏈，分佈在不同的機器、容器上，所以如果想要分析出一個結果，運維要處理的數據量遠大於業務數據量。另外，如果想要靈活處理、分析數據，對機器查詢能力的要求也是非常高的。

最後一個挑戰是對新技術的支持。現在出現了很多新技術，例如Kubernetes、容器、分佈式、Serverless、邊緣計算、IOT等，這些新技術應該如何去支持業務呢？

上圖是我們整體的架構圖，數據源包括移動App、Web網頁、傳統APM的模擬撥測、ITIM、日誌和NPMD。在數據採集層上面會有一個數據接入層，針對不同的數據類型做簡單處理，例如探針管理、數據預處理、數據聚合等。再上一層是數據存儲層，有點類似於數據中臺，我們會做一些和存儲相關的工作，在不同的應用場景下，存儲結構也有所不同，例如可能需要把非結構化存儲的日誌轉化成結構化字段。再上一層是數據分析層，主要是分析引擎、數據引擎和機器學習引擎。最後是業務表現層，主要包括的是業務方真正可以用到的東西，例如控制檯、儀表板、業務大屏等。

實際案例

聽了上面的這些內容，有人可能會覺得比較寬泛、不具象。接下來，我就講講具體的實際案例。

如何定義數據結構？抽象來看，我們認爲業務系統是一個樹狀結構，底下會有子業務系統，再往下可能還會有孫子業務系統。而業務系統包含兩個部分，一個是用戶操作，一個是業務流。用戶操作就是字面意思，比如用戶通過點擊按鈕去完成登錄、審批、支付等操作。而操作之間會形成業務流，例如訂單處理的業務流，先下單，之後由倉庫來處理，然後快遞員處理，整個業務流的場景可能是要橫跨不同的IT系統。

上圖是一個電力場景，該場景主要是做供電管理，包括提供供電方案、查看場地、設計檢查場地建設、竣工驗收、裝表裝電等。因爲這些工作涉及不同的人，有在室內辦公的、有在現場勘查的，同時國家對於工作的完成時間也有限制，只通過IT系統是很難衡量這些指標。所以，我們希望能夠把不同系統的信息都獲取到，並從中量化出相關指標，例如正在進行中的業務流的數量、報錯的業務、平均執行週期等等。

另外，我們希望能夠從業務視角下鑽到運維，例如當前整體業務系統的可用性是多少、受影響的用戶有多少、錯誤有多少，下鑽到運維，我們可以看到主業務中的子業務數量、孫子業務數量，甚至可以具體到子業務的操作。

在用戶投訴的場景中，我們在接到了用戶投訴發送短信失敗的工單之後，就可以把用戶ID或者手機號輸入到系統中，查找到用戶發送短信失敗的根因，具體的IT錯誤。在此基礎上，我們可以把系統中所有類似的IT錯誤都搜索出來，找到可能受影響用戶的相關信息，例如ID、郵箱等，去做用戶關懷，或者及時做修正。

剛剛我們關注的都是運維錯誤，其實我們常被業務方投訴，是因爲業務錯誤。什麼叫業務錯誤？以支付場景爲例，當銀行卡餘額不足，會報業務錯誤或提示交易失敗，當交易達到上限，會報業務錯誤。而業務錯誤是無法在IT系統中體現的，但是站在業務方的角度，這些都是IT系統的錯誤，所以，我們需要整體通盤的考慮這個問題，找到一個比較好的定義業務方錯誤的方法。

爲什麼說APM走到了深水區？最開始的APM是端到端監控，主要是監控用戶體驗和應用性能。後來，我們可以抓取到業務信息，這時要思考如何把IT數據和業務數據關聯起來，並做一些多維度的機器分析和可視化。數據關聯之後，我們又開始思考，是否還能結合AI技術，進行智能根因診斷、異常檢測、效率提升等等。

如果企業能夠綜合上圖的四個階段，結合IT視角和業務視角，那麼一定可以給到用戶更好的決策推薦，幫助他們完成業務目標。

作者介紹：
趙宇辰，聽雲 CTO，美國伊利諾伊大學芝加哥分校，機器學習和數據挖掘方向博士。擁有十多項美國和國際專利以及多篇最佳學術論文，同時是最早將 AIOps 產品化的實踐者之一。