張彥滿 王蘭 王奇 張力 陳寶平
DOI:10.19850/j.cnki.2096-4706.2021.08.006
摘? 要:文章針對業務支撐中心CRM中的用戶數據和網絡運營中心網元中的用戶數據不一致或網元與網元間用戶數據不一致的問題,介紹提升用戶數據一致性的方法,重點講解安全、精準、智能的用戶數據一致性稽核、修復的系統流程:多源用戶數據采集、根據配置解析入庫、依據稽核規則開展批量稽核、差異數據進行二次實時稽核、按照實時稽核結果自動下發修復指令、修復后復測一致性結果、投訴關聯智能化跟蹤修復。
關鍵詞:用戶數據;數據解析;數據稽核;數據修復;投訴關聯
中圖分類號:TP274.2? ? ? 文獻標識碼:A 文章編號:2096-4706(2021)08-0020-04
Discussion on Methods to Improve the Consistency of User Data
ZHANG Yanman,WANG Lan,WANG Qi,ZHANG Li,CHEN Baoping
(China Mobile Group Gansu Company Limited,Lanzhou? 730070,China)
Abstract:In view of the inconsistency between the user data in CRM of the business support center and the user data in the network elements of the network operation center,or the inconsistency of the user data among the network elements,this paper introduces the methods to improve the consistency of the user data,and focuses on the system process of safe,accurate and intelligent user data consistency audit and repair:multi source user data collection,analysis and warehousing according to configuration,batch audit according to audit rules,secondary real-time audit of difference data,automatic issuance of repair instructions according to real-time audit results,retesting consistency results after repair,intelligent tracking and repair of complaint association.
Keywords:user data;data analysis;data audit;data repair;complaint association
0? 引? 言
根據日常用戶投訴處理分析,CRM(Customer Relationship Management)和網元用戶數據不一致或網元間用戶數據不一致已經是影響用戶使用和感知的重要因素,同時業務支撐中心、網絡運營中心的數據一致性比對不足,部分業務功能數據不一致也會造成收入損失,對公司營業收入產生嚴重影響。因此業務支撐中心和網絡運營中心組成虛擬團隊,協同開展提升用戶數據一致性的攻堅工作。
本文結合用戶數據一致性提升專項優化工作,從細化稽核規則、嚴控稽核過程、復測修復結果、關聯投訴處理等方面入手,安全、精準、智能的把控用戶數據稽核、修復的全流程。
1? 用戶數據不一致產生的原因分析
現網CRM與網元間的數據是多對多的網狀對應關系,各業務間依賴、關聯、互斥關系繁雜,且系統間是異步交互的方式,隨著相關業務數量的增多,CRM與網元之間的交互流程和邏輯越來越復雜,容易引起網業(網元與業務支撐系統)之間的數據不一致。
1.1? 多原因引發網業數據不一致
1.1.1? 機制缺陷
現網部分業務規則設計不合理,同時管理機制不健全:(1)業務規則不對稱:如有些業務在支撐側是立即生效,而在網元側是下周期生效;(2)后臺開通業務:從業務平臺側或從接口層手工開通業務;(3)操作異常:割接操作不規范或業務梳理不夠徹底。
1.1.2? 異步交互
業務平臺煙囪林立,系統間采用異步交互的模式:(1)支撐系統異常:業務訂購或退定時未給平臺成功發送指令;(2)外圍平臺異常:外圍平臺未執行支撐系統發送的指令或未向支撐系統成功發送反向指令;(3)相關配置錯誤:系統參數、產品配置錯誤。
1.2? 修復難度大
多方面原因導致網業數據一致性修復困難重重:(1)規則梳理、維護難度大:業務相互融通、關聯,規則復雜,相應的稽核、修復規則梳理困難;產品頻繁上、下線,需要調整對應的稽核、修復口徑;(2)數據修復風險大:不同系統間數據抽取時間難以保證一致,以及數據抽取到稽核出結果期間用戶可能發生業務變更,直接按批量稽核出的結果修復數據,有可能“把對的數據修錯”;(3)難以手工處理:由于業務繁多、各系統提供的數據格式千差萬別,若由人工處理,其效率低下且效果不佳。
2? 總體架構搭建
虛擬團隊以安全、精準、智能的開展用戶數據一致性修復為目標,搭建了“面向異構網元的智能化數據管控平臺”。平臺整體架構如圖1所示。
3? 梳理用戶數據稽核規則
根據用戶在網元側的全量數據備份文件和SOAP指令實時查詢結果,梳理了用戶四類基礎數據(手機號碼、IMSI、上網功能、停開機)、六類VoLTE網元數據、十六類業務數據(彩鈴、來電顯示、呼轉、“呼死你”防護、呼叫保持、呼叫等待、高頻騷擾電話防護、三方通話、國際直撥、國際漫游、歡樂家庭網、集團V網、5G簽約、來電提醒、彩印、寬帶)的解析規則。
4? 通過平臺實現手段智能化
4.1? 數據采集
通過FTP、SFTP、數據表方式采集網元數據和業務數據。支持以固定分隔符分隔的文本文件,主要為業務平臺數據(彩鈴、寬帶、來電提醒、專線、彩印、VPMN數據等);支持華標HSS全量數據和VOLTEAS透明數據的.gz格式,采集后自動解壓縮處理;支持跨庫方式進行數據同步,設置源庫和目標庫,CRM多采用按月或按地市分表模式,平臺表名支持通配模式,以減化配置復雜度。
平臺可根據網元側備份文件生成時間,靈活配置采集開始時間點、采集路徑、用戶名、密碼、采集文件名等關鍵字,實現自動采集,并保存到相應的路徑。
4.2? 數據解析
文件采集到本地后根據配置自動進行解析入庫。用固定分隔符方式采集的文件其解析的字段數、入庫表名、分隔符均可根據需要進行配置;HSS全量文件和VOLTEAS透明文件通過配置提取所需業務數據進行解析入庫,后臺進程再對數據進行清洗、規整、格式化,降低批量稽核工作難度。舉例如下:
VOLTEAS透明數據格式復雜,業務數據采用“鍵值對+XML報文”格式進行保存,平臺采用鍵值解析,對XML報文通過XPATH方式進行匹配,提高配置的靈活性和準確性。
對用戶152XXXX6523的VOLTEAS透明數據解析后的結果如圖2所示。
4.3? 批量稽核
數據解析入庫后根據稽核規則進行批量稽核。批量稽核先按提取規則提取CRM和網元數據,再以稽核規則稽核出差異數據。
用戶152XXXX6523在CRM中為雙停狀態,網元上語音和短信閉鎖,2/3/4G上網功能沒有閉鎖,批量稽核后結果如圖3所示。
4.4? 二次稽核
數據采集時間一般在凌晨4點左右,網元數據提取時間點和CRM數據提取時間點之間會有誤差,批量稽核的數據結果只能作為初步參考,不能以此數據直接進行修復,故平臺會對差異數據進行二次稽核,確保修復的準確性。二次稽核以單條號碼為索引,同時查詢網元狀態數據和CRM狀態數據,確保將數據查詢的時間點誤差保持在毫秒級。
二次稽核是實時稽核,需配置CRM動態查詢語句及網元動態查詢指令,并對結果中的關鍵數據進行提取,然后通過實時稽核規則判斷是否屬于差異數據。
用戶152XXXX6523實時解析結果如圖4所示。
4.5? 數據修復
修復前會再做一次實時稽核,稽核一條修復一條,按照稽核結果、匹配數據規則,發送相關修復指令。
用戶152XXXX6523的稽核結果為語音停機但2/3/4G上網未停機,故發送2/3/4G上網停機指令:
SEND DIRECTIVE:
RECEIVE RESP:HTTP/1.1 200 OK
Server: Huawei web server
Content-Type: text/xml; charset="utf-8"
Content-Length: 418
<?xml version='1.0' ?>
PARSE RESAULT:9
4.6? 修復后再次稽核
修復完成后,通過前臺對CRM和網元上的數據再次進行查詢,核查用戶狀態是否修復到一致,確保修復的正確率。用戶152XXXX6523修復后前臺查詢結果如圖5所示,可以看出修復之后鎖狀態全部變為TRUE,和CRM里面的狀態2(雙停)一致。
4.7? 投訴關聯
通過智能化的手段跟蹤修復結果,保障用戶使用。平臺與一級客服系統對接,按小時獲取在線公司受理的投訴工單,將修復過的用戶與投訴用戶進行自動匹配,投訴比例超過設定閾值時下發告警,人工核查確認數據修復是否正確。
5? 本方法的先進性
安全、精準的修復保障:(1)修復數據通過多重驗證。采用“批量稽核+二次實時稽核+修復驗證”等全方位的控制模式,實現自動化的“能修復、能修對”目標,將對用戶的影響減到最小;(2)根據差異數量判定是否自動修復。對稽核出來的差異數據根據不同的業務設置不同的閾值,差異數量超過閾值時暫停自動修復并下發告警,由人工確認是否需要修復,減少因業務規則改變導致稽核結果不準確引起的數據修復錯誤;(3)修復數據可恢復。根據修復前的備份數據和數據修復工單可將用戶數據恢復至修復前的狀態。
智能的數據關聯:(1)用戶數據縱橫關聯。現網CRM與網元間的數據是多對多的網狀對應關系,平臺將各網元的數據和業務平臺的數據進行集成,通過業務邏輯、用戶類型,歸類用戶業務正確的數據實現方式,將一個用戶業務數據在網元和CRM上應該具備的業務要素進行統一展示,并采用“配置說明+動態幫助”模式進行輔助。同時修復業務時會連帶稽核、修復與其有關聯、依賴、互斥關系的業務;(2)設置白名單用戶。稽核出的差異數據在自動修復時會智能過濾白名單用戶并下發告警,人工判斷是否修復,避免對特殊業務及號碼進行常規修復;(3)啟動流控功能避免數據查詢、修復影響正常業務。一致性平臺生成的每一條工單在插入統一開通接口表前,會查詢接口表當前未處理的工單量,超過設定閾值時暫停操作,避免引起工單積壓;(4)靈活的自適應性:平臺可根據產品上下線自動調整稽核規則,適應業務產品的發展需要。
完善的跟蹤處理:(1)投訴關聯跟蹤修復結果。數據修復完成后,可通過集中化平臺數據關聯用戶投訴信息,檢查修復用戶是否有與修復操作相關的投訴,如有平臺會自動上報告警。及時發現由于修復導致的用戶投訴,迅速啟用應急措施,避免批量用戶投訴;(2)數據一致性工單可識別。數據一致性平臺生成的查詢和修復工單均進行備注,以便在數據統計、投訴、故障核查時進行區分。
6? 用戶數據一致性提升效果檢查
6.1? 百萬級的修復數據
平臺現已納入11個地市23類業務、212個場景(配置了137條采集規則、1 260條批量稽核規則、219條實時稽核規則、190條實時解析規則、198條實時修復規則、123條業務關聯規則、15條特殊過濾規則),全部實現按日自動稽核、自動修復。
截止目前累計修復存量數據約492萬條,涉及約487萬用戶。
6.2? 大幅下降的一致性投訴
平臺有效運轉,開始自動進行用戶數據一致性稽核及修復后,涉及數據一致性的投訴從2021年2月開始出現明顯下降,投訴占比降低了3.5%,極大提升了用戶感知和滿意度。
6.3? 顆粒歸倉的收入保障
通過用戶數據一致性修復,截至2021年4月,計費錯單量(流量業務為主)從去年同期的148萬下降到23萬,錯單用戶數從8 217戶下降至1 619戶,約挽回收入損失396萬/年((8 217-1 619)×50×12=3 958 800)。
7? 結? 論
用戶數據在CRM和網元間及網元與網元之間必須是一致的,這是保障用戶業務正常使用和業務正確計費的基礎。本文的目的,就是想通過提升用戶數據一致性,來減少用戶投訴,穩定用戶群,確保運營商正常的營業收入,同時提出了用戶數據一致性稽核、修復的系統方法,供用戶數據一致性的優化人員參考。
參考文獻:
[1] 張立成,楊敬巍,褚堯,等.論業務支撐系統數據一致性的保障機制 [J].通訊世界,2015(23):2-4.
[2] 李彬.一種智能網與BOSS數據一致性校對方法 [J].信息通信,2018(10):237-238.
[3] 陸松,王睿,劉桂青.BOSS和外部平臺常態化數據一致性保障機制探討 [J].電信工程技術與標準化,2010,23(3):34-37.
[4] 李麗玲.論運營商增值業務數據一致性保障機制 [J].軟件,2020,41(10):141-145.
[5] 黃淑冬.客戶數據一致性管理系統的研究與應用 [J].計算機光盤軟件與應用,2013,16(21):291-292+294.
作者簡介:張彥滿(1984—),男,漢族,甘肅慶陽人,工程師,碩士研究生,研究方向:計算機應用;王蘭(1980—),女,漢族,甘肅蘭州人,高級工程師,本科,研究方向:通信網技術;王奇(1992—),男,漢族,甘肅張掖人,工程師,本科,研究方向:通信網技術;張力(1988—),男,漢族,甘肅平涼人,高級項目經理,碩士研究生,研究方向:電子與通信工程;陳寶平(1981—),男,漢族,甘肅白銀人,工程師,碩士研究生,研究方向:大數據技術和應用。
收稿日期:2021-03-15