由于業務變化很快不斷有新的業務支撐需求, 經常出現當需求提出時，由于新、老業務有一些邏輯區別，為了實現快速上線，每次都新起一套功能, 長期下來給系統的維護帶來很大的挑戰。 同時業務同事還不停抱怨需求兌現慢。 那么運滿滿的運營平臺是怎么解決這些問題的呢? 進行了怎樣的技術變革和組織變革呢？為此，我們采訪了運滿滿運營平臺和技術學院負責人劉洋岐，聽他如何解讀運滿滿運營平臺的技術架構升級之路。

1、運營平臺的構成模塊

運滿滿的運營平臺的主要功能在于通過數字化、智能化的方式支撐起日常運營，提升運營效率，同時兼顧部分創新項目。目前，整個運營平臺包含營銷、 CRM、 客服支撐、內網系統和探索業務等幾個模塊。其中：

• 營銷模塊涵蓋了目前常見的一些活動，如優惠、 積分和廣告， 同時還有會員計費系統，它支持了運滿滿的線上運營和會員費業務的開展；

• 探索業務模塊是一些新業務形態的摸索，包含對新車 / 二手車，商城，滿滿卡和話費等業務的支撐；

• CRM 模塊包含前線地推和中臺電銷的系統，支撐了平臺、交易和購車等業務線；

• 客服支撐模塊則包含客戶服務和客戶投訴系統，不僅有傳統的電話客服還有在線客服的功能；

• 內網系統提供了公司內部系統的基礎功能，如內部網關，SSO 和權限，還有綜合工單服務來實現內部審批流程。

在這幾大模塊功能基礎上，運營平臺還抽象出了底層的服務給運滿滿內部使用，如電子合同、電子發票、流程引擎、MDM(主數據管理、提供內部基礎數據、如組織架構信息) 等內容。

2、運營平臺痛點與平臺化 / 中臺化建設

此前，運營平臺所面臨最大的挑戰就是業務變化過快所帶來的業務支撐要求。由于新、老業務有一些區別，當需求提出時，為了實現快速上線，很容易每次都新起一套功能，這就是所謂的“煙囪式”系統建設。 其帶來的第一個痛點就是重復功能建設和維護帶來的成本浪費；第二個痛點就是沒有能力沉淀，導致新業務支撐速度還是不夠快。

例如，活動系統中每次的活動邏輯和頁面都很類似，但運營同學每提一個活動方案都需要兩三天的時間來開發活動頁面，期間要和前端反復溝通樣式和效果。 有時還需要花更多時間改代碼來支持新玩法，響應速度慢，不利于針對突發熱門事件做營銷推廣。

另一個是 CRM 系統， CRM 之前功能按業務線是獨立的。新車 CRM 需求提出的時候，必須完整實現報單和客戶流轉的所有邏輯，哪怕類似的功能在車貨匹配平臺和交易業務線是現成的。因此，CRM 就是典型的煙囪式系統建設。 首先，之前的功能按業務線是獨立的，類似功能每條業務線都要重新開發，功能無法內聚，存在重復建設； 其次，由于歷史原因，針對前線地推和中臺電銷的系統是兩套， 客戶在前線地推和中臺電銷人員之間流轉很復雜，容易出問題。

針對以上問題，解決方案就是平臺化和中臺化。 平臺化就是把業務需求的變化點抽象出來，通過配置化的方式，實現對不同的業務需求的支撐。 其中常見的一種配置方式是使用流程引擎配置工作流。 在新的活動系統中，通過平臺化實現玩法的配置化和頁面的自助生成。一般來講，中臺化的本質是將公共的、通用的業務以服務的方式沉淀到為基礎服務，并實現服務的重用。 在 CRM 系統中就通過中臺化實現了在車貨匹配平臺，交易和新車幾個業務間基礎服務的重用。

首先，拆分 CRM 系統為業務服務與基礎服務兩層。將其中穩定的、具有通用能力的共享功能放到基礎服務中；將偏向具體業務的功能建設到業務服務層，以適應快速業務試錯的需要。客戶信息是各個業務線都需要的，抽象出了客戶服務。 銷售的公私海，客戶的流轉也是通用的功能，抽象出了客情服務。 客情服務中通過規則引擎和流程引擎，能實現客戶流轉和報單流程的靈活定制。

其次，抽象出了獨立的報表服務，實現了報表的配置化。 大數據將數據推送到對應的數據表后，只需要做一些配置，就可以完成報表的展現，大幅提升了對業務報表需求的響應速度。

現在重構完成后，通過底層基礎服務的重用，可以保證兩周內接入一個新的業務，能支撐集團新業務的快速開展。

3、新系統的流程配置

在新的系統上線后，活動玩法就可以抽象成：用戶行為（發貨、支付等）+ 行為條件（對用戶行為的約束規則）+ 獎勵方式（抽獎、送禮）的模式。徹底跟具體的玩法解耦，擴展性高，新增玩法只需要配置新的用戶行為即可，開發維護成本大大降低。

所有的玩法采用統一的配置流程，選擇不同的用戶行為，配置不同的行為條件和獎勵方式即可配置不同的活動。 這樣讓運營配置更加方便。

用戶在活動中的每個狀態，都被抽象為一個節點。 在調度模塊中按預設的流程調度。每個節點內部使用流程引擎來靈活組合不同的模塊，來實現不同的活動玩法。

主要有以下幾個大的節點類型：

• 通用主流程節點：一般是活動的主體流程，例如發貨后抽獎，主要涉及活動校驗模塊，用戶校驗模塊，計數器模塊和抽獎模塊；

• 分支流程節點：主要用于催動用戶跟進活動流程，主要涉及計數器模塊、觸達模塊和抽獎模塊；

• 分享流程節點：用戶分享后獎勵，或者邀請拉新，主要涉及計數器模塊、邀請模塊和抽獎模塊；

在此期間，運滿滿還上線了碼良平臺來提升整體效率。碼良平臺是一個在線 H5 編輯器，用于快速制作 H5 頁面。用戶無需掌握復雜的編程技術，通過簡單拖拽、少量配置即可制作精美的頁面，可用于營銷場景下的頁面制作。同時，也為開發者提供了完備的編程接入能力，通過腳本和組件的形式獲得強大的組件行為和交互控制能力。碼良上線后 95% 的營銷頁面可以由運營人員自己在碼良平臺創建。 InfoQ 上已經有相關文章詳細描述了碼良的設計思路 (如何設計高擴展的在線網頁制作平臺)。

（https://www.infoq.cn/article/A4610ba*mtsd2Jr5leHV）

通過活動系統的平臺化建設，現在可以在 2 個小時左右完成從頁面創建，頁面評審到活動配置的全流程，并支持在活動未開啟的情況下，進行活動全流程測試，提升了響應速度，降低了活動配置出錯的概率。

4、平臺穩定性提升與組件研發

隨著滿幫集團的體量擴大，穩定性和安全性就越來越受重視。 車貨匹配業務的一大特征是流量高峰在早上 7~9 點，而大家通常是每天晚上發布。 這樣很多性能問題會在早上直接爆發。 所以在流程上，需要規定了核心鏈路上的服務，比如發貨、搜貨、交易和會員的服務發布之后，必須進行生產環境的全鏈路壓測， 通過這種方式來提前發現性能問題。

其次，在提交代碼過程中加上了代碼 Peer Review 的環節，保證了代碼邏輯有人復查。 持續集成中加入了 Sonar 的靜態掃描和依賴包的版本管控，代碼不符合規范或者使用了企業不允許的依賴包版本會無法打包。 同時，核心流程還實現了自動化測試的覆蓋，平均成功率 97.53%。

最后，也加強了組件化的建設，將一些邏輯封裝成組件。一方面是減少了重復造輪子，提升代碼復用率 ; 另一方面規范了基礎中間件的使用，統一封裝了常見解決方案，減少了出錯的可能性。

在組件的選擇方面，比較成熟的組件有 YCache。 YCache 是一套緩存應用解決方案，能夠對緩存使用更加合理，更加方便，更加簡單。它有如下幾個特點：

• 易使用：接入的應用只需要配置相應注解，即可使用，簡潔方便。 并強制要求加上過期時間，規范了對緩存的使用方式。

• 防穿透：當對應 key 的數據為 null 時，會在緩存中插入特殊字符來表示值為空，防止訪問壓力落到數據源。

• 防雪崩：首先，通過異步刷新緩存的機制，避免大量緩存集中在某一個時間段失效，減輕給后端服務帶來的壓力。 其次，當有多個請求訪問同一個數據時，如果數據失效，只有一個會去數據庫加載，其他的請求會等待其拿到數據。

• 整合本地緩存和 Redis: 通過注解指定緩存是在本地還是在 Redis，還是兩個都有。 能很方便的實現多級緩存體系。 并且可以讓本地緩存特定的 key 失效時，可以同時讓集群中對應的 key 都失效。

• 方便的后臺管理：可以查看到集群中緩存的命中情況，并能查詢緩存內容，讓緩存失效。

目前，運滿滿在廣告服務中已經使用 YCache， 接口訪問時間的 99 線 從 55ms，降到 10ms，性能提升近 5 倍。

盡管通過各種方式保證代碼質量，但各種偶發性故障還是會出現。 出現故障要求及時響應。 針對業務特征，每天會有人值班。 每天早上 7：00 釘釘值班報道。 每天早上 9：30 發值班情況郵件。 值班人員需要及時處理值班群的告警、業務群反饋的系統問題，按故障處理流程快速處理。

5、團隊建設

在團隊人才的培養方面，首先，定期舉行各團隊 leader 論壇，討論了團隊的未來的技術方向，項目管理規范，質量管理規范和團隊建設哲學。 同時，針對各團隊的常見問題，針對性的培訓核心成員的架構能力，溝通技巧和敏捷開發流程等。

其次，根據過往內部做敏捷開發的經驗，規范化了 Scrum 流程中每個 Sprint 里面的需要查看的數據，同時也標準化了每個 Sprint 的必須流程，然后將其工具化為 Sprint 面板，保證團隊的一個 Scrum Master 都能按照輕松的按照標準流程執行。 在 Sprint 面板上可以看到每天的 block issue、燃盡圖、需求延期情況，開發中的內容，需求變更情況， 員工的任務飽和度。 同時團隊負責人也有一個 Sprint 大盤，可以一目了然的看到團隊內各 Sprint 的整體情況。 Sprint 大盤主要包含燃盡圖，需求延期情況，各 Sprint 的整體飽和度。

除了人員培養和流程優化之外，平時也不斷地打造技術氛圍。 鼓勵新技術的學習，各團隊都會定期展開內部分享和外部交流。同時內部建設了技術興趣小組，大家腦暴出新想法，用工作外的時間完成原型, 評價高的再正式立項來推進，YCache 就是這樣產生的。

6、平臺未來

運營平臺的發展方面，首要任務是通過數字化、智能化來提升運營效率。 其一是打造完整的經營分析系統，整合營銷審計等系統，提供實時的經營情況分析，實現運營指標預警和運營成本透明化。另外計劃實現從預算審批，AB 測試，快速投放到實時效果的活動平臺全流程化，讓運營同學能快速得到反饋，調整活動方式，提升活動效果。

其次是繼續推進業務系統平臺化 / 中臺化。 第一步工作臺平臺化，打通各個運營系統，讓內部運營人員看到全面的用戶信息。 同時通過底層的工單串聯現有各個業務系統中的任務。 這樣一個用戶在滿幫全生命周期的信息就能實現在各個系統之間的流動，能大幅提升運營的效率和客服服務的滿意度。 然后由于歷史原因現在有多套訂單系統，要建設訂單中臺，將現有的訂單系統底層都遷移到訂單中臺，減少類似系統的維護成本，也為新的業務接入提供更好的支持。

在管理上面，目前運滿滿的運營平臺團隊基本上是自管理型，不僅僅能執行上級的命令，也能監控過程和進度。 但團隊成員還很少自己去規劃團隊和與運營相關的組織環境。 希望再用一年的時間來更近一步， 達到“自規劃型團隊”。 另外還會持續通過“傳帶幫”的方式持續提升團隊成員能力，特別是團隊內核心同學。 “傳帶幫”中，所謂“傳帶幫”就是先把對應職責需要的方法論和知識總結出來交給對應的同學。 所謂“帶”就是自己做，對應的同學在旁邊觀摩。 所謂“幫”就是對應的同學做，自己在旁邊糾正。

在采訪最后，劉洋岐還談到了在負責的技術運營和技術學院的相關工作。 運滿滿技術學院內部有一整套的課程體系，有面向新人的“追風堂”(追風少年)，面向普通員工的“演武堂”，也有邀請外部嘉賓來分享的“羅漢堂”。 其中“追風堂”是特別重要的一環，主要負責給新人介紹企業的規章制度，宣導研發的“快， 擔當，做精彩”文化，解答新人的困惑。這是新人融入企業很重要的一步。同時, 運滿滿產研有專門的技術門戶，其功能類似阿里的 ATA。技術門戶是打造運滿滿技術氛圍的很重要一環，專門發表技術預研、 項目總結、用戶調研和專業知識分享類的文章，也會把內外部分享的視頻沉淀在上面。