BOSS接口監(jiān)控及應急分析
加入技術交流群
由于歷史與公司發(fā)展策略等多種因素，佛山移動的BOSS系統(tǒng)中存在著多種系統(tǒng)并存的情況。而多數(shù)系統(tǒng)由不同公司開發(fā)，也導致數(shù)據(jù)格式、消息機制等不盡相同。其中的惟一相同點，是外圍系統(tǒng)都必須通過“接口”才能與BOSS產生交互,接口有效地保證了數(shù)據(jù)安全與模塊獨立，同時也意味接口中斷將割裂內外部系統(tǒng)的連接。
根據(jù)規(guī)范，所有功能與業(yè)務的設置都必須由BOSS發(fā)起，一旦發(fā)生接口故障，涉及外圍系統(tǒng)的一切操作都將失敗。以目前的用戶基數(shù)，即便是短時間內發(fā)生異常，所造成的影響也是不可估量。因此，研究如何保障接口的高穩(wěn)定性與可靠性意義重大。
BOSS2.0接口系統(tǒng)框架
BOSS接口系統(tǒng)并非獨立存在，圖1描述了接口系統(tǒng)的技術框架，如圖中所示，在整個技術架構中，BOSS接口所處的位置、與關聯(lián)模塊的對接方式、內部實現(xiàn)原理等因素，都是能有效維護BOSS系統(tǒng)的基本前提。
圖1 BOSS2.0接口系統(tǒng)框架
由圖1可知，從調用方向的角度看，接口可分為主動接口和被動接口，分別表示BOSS調用外圍系統(tǒng)服務，以及外圍系統(tǒng)調用BOSS服務。主動接口由BOSS應用服務器驅動，即BOSS應用服務器上的主動服務接口進程，是調用CICS對相關待處理表進行輪詢，并將每一條記錄封裝為一條消息放入MQ隊列（該隊列均由消息組成），接口機上的主動接口再從隊列中取出消息進行解析，進而根據(jù)控制信息發(fā)送到指定系統(tǒng)執(zhí)行。被動接口則是由外圍系統(tǒng)驅動，通過接口機上的CICS客戶端調用BOSS應用服務器上的業(yè)務層服務操作數(shù)據(jù)庫。
值得一提的是，作為BOSS與外圍系統(tǒng)的承接點，接口的功能最終可歸結為對BOSS與外圍系統(tǒng)數(shù)據(jù)庫的操作。其中，主動接口的實現(xiàn)邏輯對BOSS2.0接口監(jiān)控措施的實現(xiàn)至關重要。
接口監(jiān)控措施
監(jiān)控接口是避免故障突發(fā)的重要措施。通過分析運行情況，監(jiān)控接口能實現(xiàn)異常情況的提前預警，有效地縮短故障持續(xù)時間。
從分析方法的角度看，監(jiān)控可分為定性和定量兩種，前者關注受監(jiān)控體相關因素本質是否發(fā)生變化，是常用手段，而后者則深入到相關因素變化的數(shù)量，使分析更為徹底。
1.接口定性監(jiān)控
接口的本質是進程，監(jiān)控進程一般采用查看進程狀態(tài)以及日志分析。作為有具體應用的進程，接口還有其特殊性，因而接口的定性分析至少覆蓋以下4個層次。
1)系統(tǒng)環(huán)境
指操作系統(tǒng)及硬件環(huán)境穩(wěn)定，提供進程足夠的信息資源，不存在非兼容應用等情況，這些是接口賴以生存的基本條件。
2)進程狀態(tài)
在系統(tǒng)環(huán)境滿足的情況下，檢測進程狀態(tài)是最重要的方法，但必須注意進程活躍并不等同于進程正常工作，在Linux系統(tǒng)中，其進程可能因異常而停止工作，但仍能在活躍列表中查詢到，此時需配合日志做進一步定位。發(fā)生后這種現(xiàn)象的原因是，在正常情況下，所有的進程動作都會被寫入log文件。
3)日志分析
在日志分析環(huán)節(jié)，主要包括寫入狀態(tài)與日志內容，如果檢測到日志處于寫狀態(tài)，則說明對應進程是活躍的，但進程正常與否尚需進一步判斷日志內容。異常操作時，在日志中會有失敗代碼關鍵字返回，如failed、error等。
4)進程時態(tài)
進程時態(tài)指從業(yè)務角度看進程活躍的時間段。并非所有進程都是24小時處于工作狀態(tài)，正如銀行劃扣接口一般只允許在夜間啟動，因此白天期間檢測日志是無法判斷該進程是否正常，若不考慮該特性，則可基本判斷該進程結果是否有可能出錯。
在接口的定性監(jiān)控方面，只有充分結合以上4個因素，才能對接口運行情況形成較全面認識。
在具體實施上，為了形成統(tǒng)一的體系以方便監(jiān)控并達到告警信息與實時的反饋，可將以上4個層面因素納入IBM公司開發(fā)的TIVOLI監(jiān)控系統(tǒng)。除此之外，為實現(xiàn)告警信息的自動推送與分發(fā)，可將自行開發(fā)告警信息轉發(fā)程序接入TIVOLI監(jiān)控系統(tǒng)信息庫。一旦檢測到異常信息存在則立即進行短信或郵件的發(fā)送，確保維護人員及時了解接口系統(tǒng)運行情況。整個過程如圖2所示。
圖2 TIVOLI監(jiān)控接口模型
2.接口定量監(jiān)控
上文措施均從接口本身入手，并定性分析其運行情況。根據(jù)圖1對主動接口實現(xiàn)機制的描述，本節(jié)文字將從外系統(tǒng)（BOSS庫表）的角度提出監(jiān)控措施，并利用表面不關聯(lián)的數(shù)據(jù)實現(xiàn)對接口性能的定量分析。
由于主動接口的業(yè)務數(shù)據(jù)來源于BOSS庫表，那么，庫表數(shù)據(jù)累積情況即反映了接口的運行情況，而庫表數(shù)據(jù)的遞減情況也就反映了接口的性能。示意圖如圖3。
圖3 庫表數(shù)據(jù)變動邏輯示意圖
假設主動接口在正常工作的情況下進程數(shù)為N，庫表原有數(shù)據(jù)量U，業(yè)務請求增速恒定Su，經過時間t后U降低為0（生產環(huán)境中取接近0，若庫表數(shù)據(jù)隨時間不斷增加則說明接口性能不滿足），則接口單個進程性能為Ci=(U+Sut)/Nt。通過接口性能能夠估其吞吐能力，再結合業(yè)務量重新調整接口進程數(shù)，達到資源優(yōu)化配置。
對于不間斷工作的主動接口（如HLR施工），若其計得性能c，業(yè)務請求增速恒定為Su，在相鄰的2個單位時間內查得的庫表數(shù)據(jù)量，先后為Ut、Ut+1，則如果|Ut-Ut+1|≈|c-Su|則說明接口正常，否則接口可能存在異常，需要引起重視。
對于被動接口，BOSS庫表的作用是保存業(yè)務執(zhí)行結果，因此在計算性能時只需考慮外部請求滿負荷情況下庫表的增速Sp，即Cp=Sp。但必須注意的是，庫表數(shù)據(jù)的增長速度s低于Cp并不能說明接口一定異常，因為在非滿負荷情況下s 對于負責業(yè)務查詢的接口，其數(shù)據(jù)源與結果均不經過BOSS庫表，因此上述方法不具有普適性。
使用定性分析與定量分析的兩種監(jiān)控方法，都只涉及接口的某一特性，在監(jiān)控時還需充分考慮各種因素，建立完整的接口健康度模型，在定性方法無法判斷接口運行狀態(tài)時需進一步進行定量分析，使得兩種方法優(yōu)勢互補，提高監(jiān)控的有效性。
應急方案與工具
應急是在故障事實既定時的補救措施，主要包括應急方案與工具，前者是完整的流程及措施，后者能輔助方案的順利實施。
1.制定應急措施并演練
作為BOSS與外圍系統(tǒng)的惟一連接點，接口故障將導致內外系統(tǒng)完全中斷。因此，最好的應急措施之一就是在故障時立即將服務切換到備機。為保證一次切換成功率，應急方案須詳盡、具可操作性與驗證性，并至少在方案中詳細描述以下關鍵點。
1)接口機與備機網絡環(huán)境，包括邏輯連接圖、備機IP、網絡聯(lián)通等作為判斷條件；
2)接口啟動方式與配置參數(shù)，包括指令路徑及執(zhí)行方式，配置文件具體修改方法，接口已正常啟動的標志；
3)備機具備對主機完全可代替的條件，包括接口進程類型、數(shù)量，操作系統(tǒng)環(huán)境，配置信息及網絡結構等；
4)誤操作回滾邏輯，包括操作步驟、命令字，檢測回滾成功的方法。該部分的描述在出現(xiàn)切換失敗時顯得尤為重要；
5)切換結果測試用例，在切換成功后根據(jù)預先設計好的輸入檢測輸出是否符合要求，是檢測切換結果的有效手段。
必須強調的是，完善的應急預案并不能保障應急成功，只有配合熟練演練才能真正發(fā)揮預案的作用。
2.開發(fā)應急工具
應急工具能有效縮短故障恢復時間。廣東移動通信有限公司自主開發(fā)的“BOSS接口異常數(shù)據(jù)輔助處理系統(tǒng)”便是處理客服接口故障的重要應急工具之一，系統(tǒng)通過將異常數(shù)據(jù)封裝為協(xié)議包直接送接口執(zhí)行，可有效彌補BOSS前臺功能不足、或前臺界面異常及因流程冗長引起的施工延時或故障，同時由于該方式精簡流程，執(zhí)行效率與成功率高，能有效應對緊急情況。
圖4 智能網號碼充值流程
以圖4智能網充值開機流程為例，其經歷的步驟繁多，特別是其中信控判斷邏輯復雜，程序處理耗時多，是引起月結用戶充值到賬但無法及時開機的關鍵環(huán)節(jié)。站在服務用戶的角度，最直接的應急方式便是提取已繳費入賬的號碼直接送HLR施工開機，對于存在欠費可能的用戶，其開機狀態(tài)在正常流程進行修復，但對于充值后仍欠費的用戶，其開機狀態(tài)將在經歷過信控后自動被修改為停機。
盡管該方式可能產生欠費風險，但考慮到大部分用戶將根據(jù)欠費額度進行充值，同時流程修復時間也相對較短，該方法依然是可行的。
利用BOSS接口異常數(shù)據(jù)輔助處理系統(tǒng)執(zhí)行以上應急流程的方式是：在提取號碼后，根據(jù)客服協(xié)議開機命令字10007格式要求（HandsetNo~工號~返回格式~nCode~sType~備注），將批量號碼構造成報文列表并導入系統(tǒng)執(zhí)行。主界面如圖5所示。
圖5 系統(tǒng)主界面
該系統(tǒng)的設計模型如圖6所示。由設計模型可看出，系統(tǒng)主要實現(xiàn)協(xié)議包的封裝與發(fā)送，后續(xù)流程由接口進程完成，因此，只要是接口協(xié)議支持的業(yè)務系統(tǒng)即可。統(tǒng)計《客服接口說明》命令字可知系統(tǒng)支持的業(yè)務類型約計500種，能有效滿足多種需求。
圖6 系統(tǒng)設計模型
為了調節(jié)對接口所產生的壓力，系統(tǒng)還實現(xiàn)線程數(shù)與執(zhí)行時間的動態(tài)配置，在接口壓力較大時可減少系統(tǒng)線程，并把對資源需要量多的任務定時在晚間自動啟動，避免對接口日常運作造成不良影響。
總結
本文主要研究BOSS接口的監(jiān)控方法以及應急措施，將傳統(tǒng)手段納入監(jiān)控系統(tǒng)，并重點介紹利用庫表定量分析。在應急措施中，主要討論應急方案以及自建系統(tǒng)在應急中的作用，通過監(jiān)控預防故障突發(fā)，利用應急措施降低故障影響范圍，形成較完整的接口維護體系，佛山移動目前在實踐中已經驗證了該方法的有效性。
評論