中臺實踐:通用化黑名單平臺
業務中臺的價值主要體現在對通用化業務能力的沉淀、整合,通過對可復用業務流程和業務功能的設計,向不同業務方提供標準化且可擴展的服務能力。本文來聊一聊筆者工作過程中設計的通用化黑名單平臺,通過將用戶管控能力的下沉,為各業務團隊提供一套通用的黑名單/白名單業務能力。
業務定義
黑名單平臺,泛指在業務流程當中,需要對特定用戶進行管控的方式,通常會有黑名單、白名單兩種用戶類型。
業務場景
在風控識別、業務運營等流程當中,會涉及到對于某類用戶進行“特殊對待”,比如惡意用戶、高風險用戶,在業務流程中可能會增加對用戶的使用功能的限制,這類用戶就屬于黑名單用戶。在不同的業務場景中,會基于不同規則去定義黑名單用戶,并這種符合這類特種的用戶進行統一化的管控。
當然還有一類特殊的用戶群體,他們因為使用場景的特殊化也可能命中黑名單用戶的規則。但是業務場景中又是允許這類用戶存在的,那么這類用戶就屬于白名單用戶,屬于凌駕于黑名單規則之上的一類特殊用戶群體。
業務問題
目前在現有中臺架構下,不同業務模塊都維護各自的黑名單體系,存在同一個業務場景的黑名單維護多套,或者同一套黑名單可以多個業務團隊共用的問題。這就導致各團隊開發既可能產生數據冗余,重復開發資源浪費的問題。
基于當前的問題,通過搭建中臺黑名單平臺,由各業務團隊介入黑名單平臺,針對各業務場景維護統一黑名單,可以由不同業務團隊共享黑名單數據資源進行業務使用。
業務邊界
既然做通用化,那么黑名單平臺盡可能不做具備業務屬性的邏輯,即通用戶平臺負責提供黑名單/白名單數據的統一使用服務,也就是針對數據的增、刪、改、查能力。同時,為了保證各業務使用方可以實時獲取數據,平臺提供一套消息廣播機制,可以讓業務使用方可以快速獲取數據的更新狀態,即時針對不同狀態做出業務響應。
業務架構
基于上面提到的業務場景、業務邊界,設計了業務架構模式如下:
業務設計
(1)通用化平臺由業務方接入,針對不同業務場景和業務規則,由業務方(如上圖中業務方A、B)定義什么是黑名單用戶、什么是白名單用戶;由通用化平臺提供黑名單數據的統一服務,這個服務包含增刪改查能力。
(2)業務方(如上圖中業務方A、B)可以通過通用戶平臺提供的前端可視化頁面,通過給不同業務方配置不同權限體系,支持業務方進行數據的增刪改查。同時也支持基于系統調用的API接口方式,進行數據的使用。
(3)為保證數據更新后的即時響應,在數據更新后,如數據的新增、刪除,通用化平臺通過消息廣播機制,向業務使用方(如上圖中業務方C、D)進行廣播,如果業務方關系數據更新消息,可基于業務場景做出相應的業務動作,保證數據更新與業務的同步性。
中臺化設計的關鍵
(1)統一化
在設計數據的使用方式方面,做了盡可能的統一化設計。在設計底層數據接口方面,針對增刪改查的數據接口,先對盡可能全的業務場景進行梳理,針對不同顆粒度的業務進行規劃,保證數據接口服務的統一性,后續各業務團隊接口,都是統一的接入流程和接口服務。
(2)個性化
針對不同業務場景,數據的表現形式終歸會有不同的地方,除了對整個業務流程中沒有異議的數據內容進行標準化定義外,為滿足不同團隊的業務需求,在數據存儲方面,數據結構中增加了可擴展的json字段。這個字段的數據內容由各業務方自助定義數據的業務含義,在數據查詢時基于各業務的團隊的場景進行解析后使用,既保證了各業務團隊數據使用的個性化需求,由保證了中臺通用化模塊的通用能力。
(3)擴展性
對于黑名單/白名單數據存儲,數據存在多維度屬性,通過數據業務類型分類進行區分,例如用戶維度類型,可通過枚舉區分身份證號、會員卡號、手機號等類型,字段的類型設計相對兼容,在后續數據類型擴展上,可以做到減少底層邏輯的重新開發帶來的時間、資源成本。
(4)如何做到上述3點呢?
關鍵是要對業務有充分的了解,這樣才能更好的把握統一化和個性化的平衡。例如,針對于用戶維度的黑名單設計,要對當前業務場景中標識用戶的方式有相對全面的了解:手機號、會員卡號、微信賬號、支付賬號等等,只有對實際業務的了解,才能設計符合業務方需求的功能。
綜上
所有的中臺化產品設計都是在對業務充分了解的基礎上,將統一化、個性化、擴展性進行設計與權衡,當然在方案落地過程中不可避免的要做出各種各樣的妥協與讓步,但是作為業務中臺設計者,要堅守產品設計的邊界與底線,這才是中臺產品存在的意義與價值。
#專欄作家#
記小憶,公眾號:PM龍門陣,人人都是產品經理專欄作家,OTA中后臺產品經理。
本文原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自?Unsplash,基于 CC0 協議
感覺這個應該是消息中臺的功能一部分吧?