??目錄

1 背景

2 客戶第一

3 性能和成本

4 功能設計

5 研發(fā)效率

6 運營效率

7 技術文檔

8 發(fā)展的思考

這幾年，眼看著中臺直上云霄，又看著它跌落神壇。最早提中臺建設的友商在去中臺，騰訊內(nèi)部的中臺建設也開始趨向務實。但騰訊的中臺并沒有消失，而是以技術產(chǎn)品的形式繼續(xù)默默耕耘，平臺型技術產(chǎn)品服務于開發(fā)團隊，曾經(jīng)被納入中臺的范疇，但它比中臺更長久，中臺隕落，而平臺長青。本文作者從零到一打造了騰訊 PCG 平臺型技術產(chǎn)品——搜索中臺 XSearch，他將以此為例，帶大家了解做好一個平臺型技術產(chǎn)品，需要考慮哪些點。

01

背景

   1.1 中臺、平臺、技術產(chǎn)品

當技術中臺建設熱潮退去，我們會發(fā)現(xiàn)留下來的“中臺”都是如同基建一般的“平臺”，盡管有很多文章在解釋中臺和平臺的差異，但我一直認為中臺和平臺在技術層面并沒有什么不同。在中臺概念下建設的平臺，我更愿意稱之為技術產(chǎn)品，是一款 ToB 的產(chǎn)品。

   1.2 為什么寫這篇文章

看過很多關于技術中臺的介紹文章，大都在介紹為什么需要、做了什么，當然也有一些在介紹為什么不需要，這里我想寫一些不一樣的內(nèi)容：我們的技術中臺是怎么做，從理念到執(zhí)行。既是對過往幾年工作做總結，也讓沒做過技術產(chǎn)品的讀者能了解我們是怎么做的。下面我會圍繞：客戶、核心競爭力、研發(fā)效率、運營效率、技術文檔、發(fā)展思考這些方面展開。

02

客戶第一

客戶是技術產(chǎn)品存在的唯一原因。在公司內(nèi)做技術產(chǎn)品，有 BG 統(tǒng)一管理的助力，我們找客戶不會太困難，但相比做 ToC 產(chǎn)品，還是有一些差異，核心可以概括為幾點：解決核心訴求、維護專業(yè)形象、保持溝通激活，下面展開講講。

   2.1 客戶的核心訴求

對于 XSearch 來說，功能、性能、成本、效率、穩(wěn)定性是最基本的要求，作為在 PCG 內(nèi)外二十多個業(yè)務線上驗證過的技術產(chǎn)品，當前大多數(shù)業(yè)務場景都能滿足。

   2.2 專業(yè)的客戶服務

（1）由誰來當 helper（客服）

在建設 helper 賬號的初期，我們有人力和效果方面的矛盾：一方面我們希望能有專職的外包同學來承擔 helper 提供業(yè)務接入、業(yè)務咨詢、告警處理，以減少研發(fā)團隊的體力勞動；另一方面，我們又期望 helper 能夠解決用戶問題，不需要再二次轉手，也不要打擾到研發(fā)同學。由誰來當 helper？

• 如果對系統(tǒng)實現(xiàn)不熟悉的外包同學能解決問題，那么文檔也能解決，如果文檔能解決，那么我們就不需要提供咨詢支持的外包同學。
• 如果文檔解決不了，那么咨詢外包同學也很難解決，他會成為任務分包的角色，這時候任務還是會落到背后的開發(fā)同學身上，此時必然打擾到開發(fā)同學，打亂原定的工作計劃，且會讓客戶覺得 helper 并不專業(yè)。
• 服務告警和運維處理涉及系統(tǒng)穩(wěn)定性，對值班同學和技術產(chǎn)品的自動運維能力要求較高，交給外包有一定風險。

權衡之后我們決定還是由研發(fā)同學做值班，同時通過持續(xù)建設文檔來減少客戶的咨詢，付出的代價：少了一位全人力的研發(fā)。帶來的收益：

• 每個人都有機會熟悉全系統(tǒng)所有模塊。
• 對客戶價值有更直接的認識。
• 促進用戶手冊建設。
• 更容易對不合理的設計提出挑戰(zhàn)。

未來的可能性：如果我們的技術產(chǎn)品能做到如同 MySQL 那么易于維護，也可以培養(yǎng)專門做運維的外包/同事，做到研發(fā)和運維分離。

（2）溝通的專業(yè)性

剛開始做客服的開發(fā)同學，很容易在和客戶溝通過程中陷入對立，或者是提供了錯誤的解答，所以我們在每周的值班復盤中有一個教練審查環(huán)節(jié)，對本周的所有溝通做審查并指出可提升的 case，提供指導。

   2.3 保持溝通激活

我們支持的業(yè)務是有限的，所以為每一個業(yè)務建獨立的溝通渠道是可行的，XSearch 和每個業(yè)務線都有企業(yè)微信溝通群，在群里同步研發(fā)進展、服務升級、突發(fā)告警等等重大通知。同時，我們也定義了研發(fā)月報，每月匯報一次研發(fā)進展，讓客戶能了解到什么版本做了什么升級，這也體現(xiàn)出我們的專業(yè)性。

03

性能和成本

搜索召回類的技術產(chǎn)品，需要從海量數(shù)據(jù)中取出最相關的文檔，除去業(yè)務個性化的排序效果，最容易被看到的亮點是性能和成本，這需要持續(xù)深耕以及精細運營。

   3.1 可演進的系統(tǒng)

易于修改的、可演進的系統(tǒng)，才能持續(xù)的進行性能和成本優(yōu)化，從一開始我們的系統(tǒng)架構無論是集群架構還是核心模塊內(nèi)的實現(xiàn)，都采取解耦的設計，使得這幾年來持續(xù)的性能優(yōu)化，不需要將系統(tǒng)推倒重來。

2019 年 6 月份第一版 XSearch 的設計：

現(xiàn)在（2022年7月）的 XSearch 大結構上和 2019 年的設計類似，局部架構有調(diào)整，功能也豐富了很多。

   3.2 持續(xù)的技術深耕

從 19 年中臺立項開始，我們一直投入人力在進行性能優(yōu)化，有時候是以技術專項的面目出現(xiàn)，有時候是以業(yè)務接入優(yōu)化來體現(xiàn)。在這過程中，我們積累了一系列的總結文檔，整體可以歸類為：

• 架構優(yōu)化，譬如：二級和三級扇出架構、微服務合并。
• 新技術應用，譬如：新 rpc 框架、協(xié)程、SIMD 并行指令。
• 空間換時間，譬如：業(yè)務緩存、計算緩存、jemalloc 內(nèi)存池。
• 數(shù)據(jù)結構優(yōu)化，譬如：用塊鏈代替稀疏位圖、貼合 cacheline 的內(nèi)存結構。
• 策略簡化，譬如：多次查詢改成單次，再通過更好的檢索策略補充效果。
• 實現(xiàn)細節(jié)，譬如：去掉拷貝、去掉鎖、復用對象。

   3.3 精細運營

通過技術先進性實現(xiàn)成本優(yōu)化是有門檻的工作，而精細運營則顯得像是體力勞動，以至于很多內(nèi)部的技術產(chǎn)品在早期會忽略掉精細運營（XSearch 早期也不例外）。

后來我們對 XSearch 的精細運營投入了很多精力，治理歷史包袱，并將精細化運營制度化，服務 20+ 業(yè)務線，管理上百個業(yè)務集群，沒有出現(xiàn)因為 CPU 空跑而導致客戶成本暴漲的“成本事故”。

• 設備選型：
• 高內(nèi)存高計算型的服務，使用 AMD 設備，并且不開 NUMA。
• 無須實時訪問磁盤的服務，選用非 SSD 磁盤。
• 配額最小化：CPU/磁盤/內(nèi)存，全部最小化配置。
• 自動化調(diào)度：通過 123 平臺（注：內(nèi)部容器服務管理平臺）的調(diào)度配置，配置自動縮容閾值。
• 云原生看板建設 CPU 使用率看板，查看 CPU 變化趨勢。
• 利用率監(jiān)控 CPU 峰值利用率低于 50% 的發(fā)出告警。
• 專人檢查 CPU 使用率、使用量、流量變化，最晚 T+1 和業(yè)務溝通處理。
• 對 CPU 有毛刺的離線計算業(yè)務做針對性治理，和業(yè)務團隊溝通將流量打散。

04

功能設計

功能也是業(yè)務是否使用我們產(chǎn)品的重要參考點，可以分為以下幾點：新業(yè)務接入和老業(yè)務遷移是否方便；上手門檻高不高；好不好做個性化定制；有沒有配套的 debug 工具 等等。下面從功能設計、XSearch 能力舉例、debug 能力展開介紹。

   4.1 功能設計關注點

（1）方便遷入

• 采用類 json 的 DSL 語法，既滿足通過任何檢索規(guī)則組合實現(xiàn)復雜檢索策略的需求，后來也為使用 ES 的業(yè)務遷移到 XSearch 提供了便利。

（2）一致性

• 風格一致的代碼、文檔可以提高閱讀效率，對于技術產(chǎn)品的功能設計也一樣有價值，產(chǎn)品在不斷的增加功能，一致性的設計會讓一個技術產(chǎn)品顯得越來越強（而不是增加多個需要重新學習的技術產(chǎn)品），在增加向量召回功能的時候，我們把向量當作一種和倒排、正排、枚舉并列的一種索引能力，復用原來 XSearch 的全套流程，既減少開發(fā)量，使用上也不突兀。

（3）易用性

• 通用檢索能力，大多數(shù)的客戶不需要了解分詞、query 理解、檢索語句組裝，所以我們將檢索策略做成可視化配置，只需要在界面上做選擇，就能獲得一個不錯的召回能力。
• 個性化能力，如果通用檢索無法滿足，需要定制化怎么辦？我們通過 DSL 語法、排序插件、腳本插件提供廣闊的個性能定制。
• debug 能力，業(yè)務在使用檢索引擎時，用于 debug 的時間往往不比寫一段召回代碼的時間短，所以 debug 能力的建設一樣非常重要。

（4）通用和定制的權衡

• 想要規(guī)模化的產(chǎn)品，必然是通用的。而業(yè)務產(chǎn)品又可能提出來定制需求，我們通過配置化、插件系統(tǒng)解決大多數(shù)定制問題，譬如：要搜索標題還是搜索標簽、要用默認排序還是自定義排序等等。但部分問題沒辦法完美解決，會付出代價，譬如：架構設計和協(xié)議設計。
• 代價-架構設計：當只服務一個業(yè)務的時候，系統(tǒng)的變數(shù)少，不需要考慮太多插件擴展，架構簡單服務耗時短、開發(fā)周期短。
• 代價-協(xié)議設計：不用考慮多業(yè)務有不同字段的需求，當有新增字段時，直接追加新字段即可。而考慮到多業(yè)務時，要么是犧牲性能，定義 map 類型來應對不同業(yè)務的差異化字段，要么是使用 oneof，把不同業(yè)務的個性化字段拆分到不同 message 中，不管那種方式，都會給協(xié)議增加復雜度，對性能有影響。

（5）性能和便利的權衡

• 單個業(yè)務下的技術產(chǎn)品，選擇一般是單一明確的，追求性能或者追求易用，而平臺化的技術產(chǎn)品則需要考慮提供多種選擇。譬如：接口協(xié)議的設計上，正排索引值是返回序列化后的字符串，還是返回原始數(shù)字，追求性能的用戶希望返回原始數(shù)字，追求易用性的用戶希望返回字符串直接用來展示。

   4.2 XSearch 的檢索能力

XSearch 的功能按照層次劃分，涵蓋召回、Query 理解、插件定制、數(shù)據(jù)通道、運營系統(tǒng)這幾個層次，可以用一張圖表達：

   4.3 XSearch 的 debug 能力

基于我們自己做業(yè)務開發(fā)時遇到的案例，我們建設比較豐富的 debug 技能點，涵蓋：

• 模擬查詢。
• 解釋查詢。
• 文檔查詢。
• 索引信息查看。
• 全鏈路 trace。

有了這些能力，為什么不召回、為什么召回、召回經(jīng)過哪些運算，都可以通過工具看到。

05

研發(fā)效率

研發(fā)效率是技術產(chǎn)品保持競爭力的根基，從 2019 年立項開始，我們就在持續(xù)投入，但和大多數(shù)初創(chuàng)期的團隊一樣，早期做得比較粗糙，2020 年在 PCG 推行 EPC 的大趨勢下，順勢將單元測試、MR 流水線、代碼評審、代碼規(guī)范等各類配套設施補全，并在 2021 年借力 iCode\iRead\iWork，讓我們在代碼質量上更進一步。

   5.1 流程制度

規(guī)定一套唯一的、符合高效率原則的流程制度，減少選擇、減少出錯。

   5.2 基礎設施

基于公司平臺配置項目基礎設施，確保流程制度可實施。功能點包括：

（1）流水線

• MR 流水線。
• 主干提交流水線。

（2）工蜂倉庫設置

• 分支和 tag 命名規(guī)范，提升可讀。
• 主干代碼只能通過 MR 合入。
• MR 必須經(jīng)過有經(jīng)驗開發(fā)者、綠帶認證者評審。

（3）基于流水線做的攔截

• 開發(fā)者必須獲得開發(fā)者資質，包括：編碼規(guī)范考試、代碼安全考試。
• 增量代碼單測覆蓋率 > 85%。

（4）工具

• 需求扭轉流程管理。
• 基于 VSCode 或者 Vim 的代碼格式化工具。
• 測試、灰度、全量發(fā)布工具。

   5.3 代碼評審

代碼評審是一個團隊的事情，讓一個團隊有效率、有質量的執(zhí)行代碼評審，需要文化、人、制度和工具多方面的配合。

• 公司文化，受益于這幾年公司對工程素養(yǎng)的重視，大量的宣導、強制課程學習、內(nèi)部論壇討論，團隊全員受過 CR 的基礎培訓和引導。我們也通過小團隊內(nèi)的討論和制度的強制落實，讓每個人會意識到：
• 代碼可以寫得更好；
• CR 活動需要花費不少時間；
• CR 是完成需求過程中的必要環(huán)節(jié)。
• 團隊制度，設計一套代碼評審流程，并由核心同學帶頭落實。
• 團隊成員，借力公司課程、職級晉升的代碼質量要求，讓多數(shù)人有意愿、有能力、有時間執(zhí)行代碼評審。
• 評審工具，通過流水線、工蜂、研效看板，確保代碼評審過程可高效執(zhí)行。

06

運營效率

技術產(chǎn)品的運營有規(guī)模化效應，相比每個業(yè)務團隊自己運維 XSearch，搜索中臺采用全托管的模式，讓業(yè)務團隊更省力，也促使 XSearch 建設一套完整的運營流程。

   6.1 關鍵能力

• 一站式運營系統(tǒng)，用戶使用 XSearch 的所有的操作都在運營系統(tǒng)中完成，包括數(shù)據(jù)接入、檢索策略、debug；管理員操作的審批、部署也都在運營系統(tǒng)中完成；
• 用戶手冊，減少人工咨詢；
• helper 賬號，人工咨詢和業(yè)務接入審批等；
• 值班制度，全職投入，處理告警、用戶咨詢、云原生治理、業(yè)務審核等工作；
• 群溝通渠道，每個業(yè)務一個溝通群；

   6.2 運作模式

我們通過技術文檔、運營系統(tǒng)、溝通渠道、云服務，將用戶、客戶、值班人員聯(lián)系到一起，如下圖所示：

07

技術文檔

文檔可以跨越時間的限制，進行信息的規(guī)?；瘋鬟f和交流，可以幫助團隊也可以幫助個人，它是主干開發(fā)、代碼評審、流水線等效率技能的放大器。

   7.1 新人文檔

怎么讓團隊新人、中臺共建者能更快的參與 XSearch 系統(tǒng)開發(fā)？這是我們的《新人大禮包》要解決的問題。

首先整理《搜索中臺開發(fā)入門手冊—通用篇》，讓讀者可以了解 XSearch 的目標、XSearch 的整個研發(fā)流程、了解需要獲得開發(fā)者資質、5 分鐘能搭建開發(fā)環(huán)境、流水線是怎么回事、怎么做代碼評審等等基礎入門信息。

再進一步，團隊在需求協(xié)作過程中，是否能有良好的職業(yè)素養(yǎng)？

基于這幾年工作中的觀察，整理《如何成為一名靠譜的程序員：職業(yè)素養(yǎng)入門指南》一文，記錄一些職業(yè)素養(yǎng)的思考和建議，涵蓋：需求溝通、開發(fā)技能、代碼評審、文檔規(guī)范、協(xié)作交流、效率產(chǎn)品、服務運營等方面，所有這些組合形成團隊的導向。

   7.2 開發(fā)和運營文檔

怎么讓知識傳播以獲得更大的價值？怎么讓技術產(chǎn)品不因人員更替而受損？這些都要求 XSearch 有優(yōu)質的代碼和技術文檔，這幾年我們把文檔的“架子”搭起來了。

   7.3 用戶手冊

XSearch 用戶手冊是讀寫比很高的文檔，當前基本覆蓋客戶使用過程中可能遇到的所有問題：能力了解、入門使用、細節(jié)功能、自助 debug、合作共建。

08

發(fā)展的思考

任何產(chǎn)品都有它的生命周期，平臺型技術產(chǎn)品和 ToC 產(chǎn)品有什么樣的不同，它和過去我們的平臺又有哪些區(qū)別，未來可能往哪些方向發(fā)展，下面講講我的思考。

   8.1 長周期

XSearch 是復雜的技術產(chǎn)品，它的建設周期比一般的 ToC 產(chǎn)品要長得多，技術產(chǎn)品也許需要一年的時間才能萌芽，而對于 ToC 產(chǎn)品可能一年就是一生。因為周期長所以收益可能是滯后的，一個從業(yè)務產(chǎn)品中成長出來的技術產(chǎn)品非常依賴業(yè)務的穩(wěn)健發(fā)展、業(yè)務負責人和公司的長期主義，另一方面，技術產(chǎn)品團隊本身也要不斷的證明自身的價值，需要有強烈的自驅追求卓越的沖動。

   8.2 市場化

以前公司內(nèi)的技術產(chǎn)品一般作為平臺基建存在，不用考慮營收，而在各種設施都上云的趨勢下，基礎組件也可以作為技術產(chǎn)品售賣，現(xiàn)在也在逐步的強調(diào)技術產(chǎn)品及其費用結算，這讓開發(fā)者有機會用公司內(nèi)的業(yè)務孵化技術產(chǎn)品，最后能走出公司創(chuàng)造更大的價值。對技術產(chǎn)品開發(fā)者來說是很好的鼓勵和壓力，對于 XSearch 來說，期望有一天能實現(xiàn)云上售賣，在國產(chǎn)軟件上占一席之地。

   8.3 考核導向

公司內(nèi)技術產(chǎn)品的發(fā)展，有必要提一下考核導向，這幾年中臺技術產(chǎn)品考核，包括：研效、SLA 簽約、成本結算、問卷調(diào)查等等，在往高效率高性能低成本的技術產(chǎn)品研發(fā)上引導，為促進技術產(chǎn)品的健康發(fā)展提供了很大助力。

-End-

原創(chuàng)作者｜吳銀光