電信BSS業務監控系統的設計與應用研究

許玉華

（南京中興軟創軟件技術有限公司，江蘇 南京 210000）

0 引言

當前的運營商發展速度已經逐漸趨于平緩，但行業之間的競爭卻是越發激烈。同時，電信企業內部的系統，尤其是BSS系統規模正在逐步擴大，帶來了維護成本顯著提高的問題。運營商為了謀求進一步的發展，就必須要保障用戶的使用體驗，而這就需要一個強大的運維系統作為支撐。由于之前BSS設計十分重視功能堆積，對業務監控系統的設計不予重視，使得有關服務的業務監控及異常處理完全不存在，極大地影響了用戶的使用體驗，為此，本文針對電信BSS業務監控系統的設計展開了研究。

1 電信BSS業務監控系統的總體目標

設計電信BSS業務監控系統的主要目標，就是在通信網絡中可以借助流量的分析和理論的挖掘，做到實時監測和記錄整個電信業務過程，并借助原定設置的規則配置手段，將不健康的內容進行過濾，并對一些非法業務進行及時的阻斷，從而影響達到保護通信網絡，提升整體服務質量的目的。從當前的情況來看，電信業務種類十分繁多，根據不同的角度也可以做出不同類型的劃分。就比如其中的瀏覽業務，就是指用戶借助充當瀏覽器來訪問相應的網站的行為，這種業務根據所采用的瀏覽技術上的差異，可以分為WAP瀏覽器和Web瀏覽兩種，由于受到終端技術和WAP協議的限制，瀏覽類的業務在最初發展的時候只能夠訪問一些數量有限且內容單一的WAP網站。但是在手機處理能力不斷提升的影響下，WAP的協議也得到相應的擴展，再加之網絡帶寬的增加，使得用戶可以訪問到內容較為豐富的互聯網網站。

2 電信BSS業務監控系統的設計原則

在設計電信BSS業務監控系統的過程中，需要遵循如下幾個方面的原則：第一，易用性原則。BSS整個業務系統內部的各個業務系統是孤立建設的，整個業務系統的內部和系統之間存在較為復雜的交互以及數據之間的傳遞工作，從而導致整個企業的信息系統管理工作復雜程度相對較高。在設計業務監控系統的過程中追求可視化和易操作，可以逐步減少對于專業人員的過度依賴，同時這也是當前整個BSS業務監控系統設計所追求的原則之一[1]。第二，可靠性原則。業務監控系統設計的最初目的就是為了確保電信企業實現智能化運維的目標，這也就意味著監控系統不可以對BSS系統內部的基礎業務運行和性能產生相應的影響，系統在設計的環節中需要遵循標準和規范化的原則，保證整個系統具備較高水準的可靠性，以此來確保基礎性質的業務能夠正常的運轉。第三，安全性原則。BSS系統內部保存著有關客戶的重要資料，這也就意味著系統需要對外部的各種惡意攻擊和病毒入侵做出有效安全的防范，并且需要對訪問權限做出嚴格細致的管理，對于一些特殊性質的操作和重要的數據，必須在經過有關用戶的授權之后方可進行使用，而這些要求也就意味著整個系統必須具備相應的數據加密、身份認證等安全措施。業務監控系統在設計的環節中，也需要沿用原有電信BSS系統中固有的安全加固模式。第四，擴展性原則，在電信業務不斷發展的影響下，BSS業務監控系統往往會出現無法全面監控的情況，同時監控的范圍和場景也會出現相應的變化。在這種情況下，整個業務監控系統就需要添加全新的功能模塊，或者是和其他的工作軟件進行連接使用。在這些要求下就需要確保整個業務監控系統具備良好的拓展性，需要在設計標準化接口的前提下，做到輕松和第三方軟件進行相應的對接，從而真正意義上做到不同應用平臺間直接進行信息的有效交互，以便更好地解決運維工作的管控、業務系統間的協同和適配問題。第五，伸縮性原則[2]。

3 電信BSS業務監控系統的部分功能模塊設計

3.1 服務調用設計

對于整個BSS業務監控系統而言，服務調用是其中的高級運維部分，其主要功能就是定位系統故障的發生位置及分析整個系統的運行狀態。其具體的分層包括顯示層、服務能力、統計分析、存儲、匯聚、采集、埋點等。其中的埋點是借由平臺的中間件以及業務邏輯，在完全遵循日志規范的基礎上，實現日志的埋點輸出，具體的日志輸出內容調用鏈的埋點日志、跟蹤日志等。部署在業務服務器內部的Uni Agent中的 Flume Agent，主要是負責采集日志的從文件，并將之傳輸到匯聚層。在日志匯聚之后，需要由Flume集群將存在于Kafak中的數據全部取出，在將這些數據導入原始日志庫及搜索完服務器之后，需要進行流式計算即調用鏈整體狀態進行計算，隨后將計算得出的結果數據導入到搜索服務器中。

統計分析層則是將原始日志庫中埋點日志進行提取和調用，并在進行分析和計算之后將調用鏈的結果數據生成表格存放到分析結果庫中。而服務能力則是為外界提供相應的運維服務結果。

分布性質的服務跟蹤系統的主要思路就是借助服務調用鏈的各個服務處理節點響應產生的日志信息，通過串聯同一個生產請求中帶有同一個ID的系統和服務，并在經過重組還原之后得到更多具有價值的信息。具體來說，每一個URL請求都生成一個全局唯一化ID，而這個ID在BSS業務監控系統中被稱作是Trace ID，同時這個ID將會存在于對應URL請求中全部的服務調用等環節生成的全部日志中。由于這些全部的資源訪問行為都是在分布式環境下開展的，如若想要在應用程序中實現打印服務鏈路日志和傳遞Trace ID的目標，也就意味著在程序中會有大量的日志打印代碼，而且需要以用數據的方式將Trace ID傳遞到下一個服務節點，而這些環節的存在都為整個系統帶來了較大的代碼入侵風險。因為BSS業務系統絕大部分都是用Java語言編寫的，為此就會在服務框架層和資源的驅動訪問層中植入傳遞Trace ID的功能代碼，換言之就是在中間件層面上統一實現了業務監控系統上下文的創建[3]。有效調用上下網在中間件中的網絡請求傳遞，并能夠做到將上下文信息的調用保存在本地的Thread Local中，從而有效實現了BSS業務監控平臺所需要的上下文調用和日志信息對于系統開發人員完全透明的目標。

3.2 巡檢管理設計

整個系統的健康程度評價，也是通過各個系統指標項的得分匯聚計算而來的，就當前的情況來看，系統自身的健康度模型可以將業界內部通用的QOE模型作為參考，并借此設計出一套評估BSS業務系統的健康度模型。這個模型主要是從BSS內部的各個產品和業務服務器中進行業務數據日志和性能指標的收集并嚴格按照業務流程的維護需求設置相應的KPI。健康度模型中存在的任何一個中間節點的健康度都是由下一層的節點數據經過匯集計算得出的，而葉子節點的健康度主要是由3個KQI的總體評分得出的，主要是針對不同業務所提出的接近用戶感受的業務質量參數，包括可用性、性能下降程序及事件扣分。其中每一個KQI評分也是經過不同的KPI得分匯聚而來的，而在電信BSS業務監控系統中的KPI主要指的是應用、服務、資源三者，比如在性能下降中會設置時延平均數、CPU占用率以及內存使用率等。借助基礎性能將性能KPI或是業務KPI經過采集上報之后，進行相應的匯聚加工操作，使用相應的計算表達式可以做到標準化處理單個或者是有所關聯的KPI，并真正在給出單個節點評分數值的前提下，借助匯聚算法得出父節點的數值，最終就能夠得到頂層節點的評分。

4 結語

傳統的電信BSS業務系統單純地注重功能模塊設計，忽視了業務監控功能的設計導致無法有效及時地處理整個業務系統運營中出現的故障，直接降低了整體的用戶使用體驗，這對于電信企業的進一步發展有著極大的損害。本文針對現有BSS業務系統中監控系統的不足，在全面遵循設計原則的基礎上就其中的日志管理和服務調用兩大模塊進行了相應的設計改進，以便為今后的電信BSS業務系統設計改良提供相應的參考。