由于歷史與公司發展策略等多種因素，佛山移動的BOSS系統中存在著多種系統并存的情況。而多數系統由不同公司開發，也導致數據格式、消息機制等不盡相同。其中的惟一相同點，是外圍系統都必須通過“接口”才能與BOSS產生交互,接口有效地保證了數據安全與模塊獨立，同時也意味接口中斷將割裂內外部系統的連接。

根據規范，所有功能與業務的設置都必須由BOSS發起，一旦發生接口故障，涉及外圍系統的一切操作都將失敗。以目前的用戶基數，即便是短時間內發生異常，所造成的影響也是不可估量。因此，研究如何保障接口的高穩定性與可靠性意義重大。

BOSS2.0接口系統框架 　　

BOSS接口系統并非獨立存在，圖1描述了接口系統的技術框架，如圖中所示，在整個技術架構中，BOSS接口所處的位置、與關聯模塊的對接方式、內部實現原理等因素，都是能有效維護BOSS系統的基本前提。

圖1 BOSS2.0接口系統框架 　　

由圖1可知，從調用方向的角度看，接口可分為主動接口和被動接口，分別表示BOSS調用外圍系統服務，以及外圍系統調用BOSS服務。主動接口由BOSS應用服務器驅動，即BOSS應用服務器上的主動服務接口進程，是調用CICS對相關待處理表進行輪詢，并將每一條記錄封裝為一條消息放入MQ隊列（該隊列均由消息組成），接口機上的主動接口再從隊列中取出消息進行解析，進而根據控制信息發送到指定系統執行。被動接口則是由外圍系統驅動，通過接口機上的CICS客戶端調用BOSS應用服務器上的業務層服務操作數據庫。

值得一提的是，作為BOSS與外圍系統的承接點，接口的功能最終可歸結為對BOSS與外圍系統數據庫的操作。其中，主動接口的實現邏輯對BOSS2.0接口監控措施的實現至關重要。

接口監控措施 　　

監控接口是避免故障突發的重要措施。通過分析運行情況，監控接口能實現異常情況的提前預警，有效地縮短故障持續時間。

從分析方法的角度看，監控可分為定性和定量兩種，前者關注受監控體相關因素本質是否發生變化，是常用手段，而后者則深入到相關因素變化的數量，使分析更為徹底。

1.接口定性監控 　　

接口的本質是進程，監控進程一般采用查看進程狀態以及日志分析。作為有具體應用的進程，接口還有其特殊性，因而接口的定性分析至少覆蓋以下4個層次。

1)系統環境 　　

指操作系統及硬件環境穩定，提供進程足夠的信息資源，不存在非兼容應用等情況，這些是接口賴以生存的基本條件。

2)進程狀態 　　

在系統環境滿足的情況下，檢測進程狀態是最重要的方法，但必須注意進程活躍并不等同于進程正常工作，在Linux系統中，其進程可能因異常而停止工作，但仍能在活躍列表中查詢到，此時需配合日志做進一步定位。發生后這種現象的原因是，在正常情況下，所有的進程動作都會被寫入log文件。

3)日志分析 　　

在日志分析環節，主要包括寫入狀態與日志內容，如果檢測到日志處于寫狀態，則說明對應進程是活躍的，但進程正常與否尚需進一步判斷日志內容。異常操作時，在日志中會有失敗代碼關鍵字返回，如failed、error等。

4)進程時態 　　

進程時態指從業務角度看進程活躍的時間段。并非所有進程都是24小時處于工作狀態，正如銀行劃扣接口一般只允許在夜間啟動，因此白天期間檢測日志是無法判斷該進程是否正常，若不考慮該特性，則可基本判斷該進程結果是否有可能出錯。

在接口的定性監控方面，只有充分結合以上4個因素，才能對接口運行情況形成較全面認識。

在具體實施上，為了形成統一的體系以方便監控并達到告警信息與實時的反饋，可將以上4個層面因素納入IBM公司開發的TIVOLI監控系統。除此之外，為實現告警信息的自動推送與分發，可將自行開發告警信息轉發程序接入TIVOLI監控系統信息庫。一旦檢測到異常信息存在則立即進行短信或郵件的發送，確保維護人員及時了解接口系統運行情況。整個過程如圖2所示。

圖2 TIVOLI監控接口模型 　　

2.接口定量監控 　　

上文措施均從接口本身入手，并定性分析其運行情況。根據圖1對主動接口實現機制的描述，本節文字將從外系統（BOSS庫表）的角度提出監控措施，并利用表面不關聯的數據實現對接口性能的定量分析。

由于主動接口的業務數據來源于BOSS庫表，那么，庫表數據累積情況即反映了接口的運行情況，而庫表數據的遞減情況也就反映了接口的性能。示意圖如圖3。

圖3 庫表數據變動邏輯示意圖 　　

假設主動接口在正常工作的情況下進程數為N，庫表原有數據量U，業務請求增速恒定Su，經過時間t后U降低為0（生產環境中取接近0，若庫表數據隨時間不斷增加則說明接口性能不滿足），則接口單個進程性能為Ci=(U+Sut)/Nt。通過接口性能能夠估其吞吐能力，再結合業務量重新調整接口進程數，達到資源優化配置。

對于不間斷工作的主動接口（如HLR施工），若其計得性能c，業務請求增速恒定為Su，在相鄰的2個單位時間內查得的庫表數據量，先后為Ut、Ut+1，則如果|Ut-Ut+1|≈|c-Su|則說明接口正常，否則接口可能存在異常，需要引起重視。

對于被動接口，BOSS庫表的作用是保存業務執行結果，因此在計算性能時只需考慮外部請求滿負荷情況下庫表的增速Sp，即Cp=Sp。但必須注意的是，庫表數據的增長速度s低于Cp并不能說明接口一定異常，因為在非滿負荷情況下s 　　對于負責業務查詢的接口，其數據源與結果均不經過BOSS庫表，因此上述方法不具有普適性。

使用定性分析與定量分析的兩種監控方法，都只涉及接口的某一特性，在監控時還需充分考慮各種因素，建立完整的接口健康度模型，在定性方法無法判斷接口運行狀態時需進一步進行定量分析，使得兩種方法優勢互補，提高監控的有效性。

應急方案與工具 　　

應急是在故障事實既定時的補救措施，主要包括應急方案與工具，前者是完整的流程及措施，后者能輔助方案的順利實施。

1.制定應急措施并演練 　　

作為BOSS與外圍系統的惟一連接點，接口故障將導致內外系統完全中斷。因此，最好的應急措施之一就是在故障時立即將服務切換到備機。為保證一次切換成功率，應急方案須詳盡、具可操作性與驗證性，并至少在方案中詳細描述以下關鍵點。

1)接口機與備機網絡環境，包括邏輯連接圖、備機IP、網絡聯通等作為判斷條件； 　　

2)接口啟動方式與配置參數，包括指令路徑及執行方式，配置文件具體修改方法，接口已正常啟動的標志； 　　

3)備機具備對主機完全可代替的條件，包括接口進程類型、數量，操作系統環境，配置信息及網絡結構等； 　　

4)誤操作回滾邏輯，包括操作步驟、命令字，檢測回滾成功的方法。該部分的描述在出現切換失敗時顯得尤為重要； 　　

5)切換結果測試用例，在切換成功后根據預先設計好的輸入檢測輸出是否符合要求，是檢測切換結果的有效手段。

必須強調的是，完善的應急預案并不能保障應急成功，只有配合熟練演練才能真正發揮預案的作用。

2.開發應急工具 　　

應急工具能有效縮短故障恢復時間。廣東移動通信有限公司自主開發的“BOSS接口異常數據輔助處理系統”便是處理客服接口故障的重要應急工具之一，系統通過將異常數據封裝為協議包直接送接口執行，可有效彌補BOSS前臺功能不足、或前臺界面異常及因流程冗長引起的施工延時或故障，同時由于該方式精簡流程，執行效率與成功率高，能有效應對緊急情況。

圖4 智能網號碼充值流程 　　

以圖4智能網充值開機流程為例，其經歷的步驟繁多，特別是其中信控判斷邏輯復雜，程序處理耗時多，是引起月結用戶充值到賬但無法及時開機的關鍵環節。站在服務用戶的角度，最直接的應急方式便是提取已繳費入賬的號碼直接送HLR施工開機，對于存在欠費可能的用戶，其開機狀態在正常流程進行修復，但對于充值后仍欠費的用戶，其開機狀態將在經歷過信控后自動被修改為停機。

盡管該方式可能產生欠費風險，但考慮到大部分用戶將根據欠費額度進行充值，同時流程修復時間也相對較短，該方法依然是可行的。

利用BOSS接口異常數據輔助處理系統執行以上應急流程的方式是：在提取號碼后，根據客服協議開機命令字10007格式要求（HandsetNo~工號~返回格式~nCode~sType~備注），將批量號碼構造成報文列表并導入系統執行。主界面如圖5所示。

圖5 系統主界面 　　

該系統的設計模型如圖6所示。由設計模型可看出，系統主要實現協議包的封裝與發送，后續流程由接口進程完成，因此，只要是接口協議支持的業務系統即可。統計《客服接口說明》命令字可知系統支持的業務類型約計500種，能有效滿足多種需求。

圖6 系統設計模型 　　

為了調節對接口所產生的壓力，系統還實現線程數與執行時間的動態配置，在接口壓力較大時可減少系統線程，并把對資源需要量多的任務定時在晚間自動啟動，避免對接口日常運作造成不良影響。

總結 　　

本文主要研究BOSS接口的監控方法以及應急措施，將傳統手段納入監控系統，并重點介紹利用庫表定量分析。在應急措施中，主要討論應急方案以及自建系統在應急中的作用，通過監控預防故障突發，利用應急措施降低故障影響范圍，形成較完整的接口維護體系，佛山移動目前在實踐中已經驗證了該方法的有效性。