追求卓越

打造極致文化與產品研發結合的最佳實踐

神策已啟動「卓越產品計劃」

產品功能、性能、穩定性不斷邁向新臺階

“追求卓越”是神策軍的三大信念之一。我們希望通過「卓越產品計劃」,在服務客戶數量越來越多、業務邏輯和技術架構越來越復雜的背景下,全面保障產品技術架構和技術支撐系統穩步提升。除了將產品打磨好之外,要在內部實現極致文化與產品研發結合的最佳實踐,致力于把功能做到極致,把性能做到極致,把穩定性做到極致。

神策分析是公司成立之初推出的用戶行為分析產品,支持私有化部署、云版部署等多種部署方式,如今已是神策“兩云一平臺”(神策分析云、神策營銷云、神策數據根基平臺)的重要組成部分。

本文將針對神策分析,圍繞服務質量指標、錯誤碼系統、服務治理,詳細講述解決查詢報錯類問題(如分析模型的查詢報錯、未知使用報錯等)的產品迭代實踐。

一、制定服務質量指標體系,先于客戶發現問題

在我們為客戶解決問題的過程中,通常能夠明確地定位問題,但是我們又不滿足于對具體問題的發現和解決——希望能夠在客戶發現實際問題之前消滅隱患,變被動為主動,先于客戶發現問題。

面對千余家大大小小不同規模的私有化部署集群,傳統的服務監控 + 報警的方式對運維人工的依賴較高,問題處理進度相對滯后,無法滿足我們對卓越產品的需求,因此,我們決定通過制定和完善服務質量指標體系(簡稱 SLI),先于客戶發現問題。

制定服務質量指標體系,一方面可以將問題反饋轉化為量化指標,用數據說話;另一方面,合理地監控服務質量指標的變化情況,可以在集群環境出現隱患時及時介入并處理。同時,基于服務質量指標我們也可以對產品實施效果進行持續評估,更好地指導產品優化思路。

對于不規律的查詢報錯類問題,服務質量指標通常包括:

1、分析模型查詢錯誤率。神策分析核心功能度量指標,直接影響客戶的查詢體驗。

2、單客戶平均請求報錯數。重點度量客戶的前端使用體驗,統計客戶側直觀的報錯數據量。

通過服務質量指標體系,我們可以在保證合規的前提下,全面洞察客戶服務質量技術類指標,對于提前發現問題和觀測產品服務質量的優化效果都起到重大作用。

二、自研錯誤碼系統,提升問題處理效率

神策分析功能豐富,依賴較多技術組件,加上私有化部署集群帶來的機器配置和硬件環境差異,使得快速地定位和歸因問題、解決問題成為我們提升技術支撐能力的重點。

在神策,我們一直堅持“能用產品解決的問題,就不要用服務解決”。因此,我們通過自研錯誤碼管理系統,一方面形成一套統一的錯誤碼規范和管理標準,以產品化的方式管理錯誤信息,讓技術支持和運維等售后同學能夠更準確地獲取報錯提示;另一方面也為我們提供錯誤碼的檢索能力,作為技術支持知識的一部分進行沉淀,快速針對相關錯誤碼獲取對應的原因和解決方案。

在具體的實踐過程中,錯誤碼系統包含錯誤碼規范定義、錯誤碼字典、開發工具和錯誤碼展示四個部分。

●「錯誤碼規范定義」由“應用 - 錯誤階段 - 單元 ID - 錯誤編號”組成,如 SA-D-1-1。其中,“核心編碼”是唯一標識,用于代碼開發過程,保證全局唯一性,在各種場景下固定無變更。“關鍵屬性”用于直觀描述,在錯誤碼中直觀地外顯更多錯誤定義信息;“連接符”用于功能區分及擴展,是各個組成屬性間的連接,方便各屬性之間不限位數的擴展。

● 「錯誤碼字典」用于錯誤碼注冊、查詢、編輯、審批等維護與管理,通過流程機制確保錯誤碼按照統一規范進行接入,讓每一個錯誤碼都有結構化的詳細描述錯誤信息,能夠更好地輔助問題的排查和定位。

● 「開發工具」是指錯誤碼系統提供適用于不同技術端的錯誤碼開發工具、適用于不同語言的 SDK & 編輯工具等,實現低成本的快速接入與開發。

● 「錯誤碼展示」可以根據錯誤碼的定義規范,提供產品化的通用錯誤提示框,以更加詳細、清晰的結構化方式具體描述錯誤,同時提供描述信息的復制、截圖、錯誤文件下載等功能。

到目前為止,錯誤碼系統包含了 20+ 類錯誤信息,其中累計完善錯誤碼數 700 多個。基于該錯誤碼系統,我們的產品和技術圍繞報錯信息形成了更加高效的問題處理和反饋機制。

三、基于服務治理“三板斧”,減少報錯數量

通過服務治理指標的采集與分析、錯誤碼系統的構建,我們可以對業務中存在的各種報錯問題進行統計和歸因。但是在解決實際問題的過程中,我們會發現很多問題都不是復雜技術架構下對單一節點進行優化就能夠解決的,通常需要進行一些系統性的治理工作。因此,結合神策的技術架構和業務特點,我們制定了服務治理的三板斧策略。

第一板斧:“應用化”重構

神策分析發展至今,產品組件的數量明顯增加,不同產品組件之間也存在復雜的依賴關系。與此同時,隨著公司業務的快速發展,過去的管理方式已經不能夠滿足產品迭代和質量標準提升的需求。因此,在神策私有化部署和云版部署多種部署模式共存的背景下,我們定義了一套服務管理標準——從技術和產品層面將服務模塊劃分為應用、產品組件、模塊三個級別,通過明確職責范圍以降低組件之間的依賴和團隊之間的溝通成本。同時,將所有不符合新規范定義的服務間訪問定義為“飛線”問題。圍繞著新的“應用化”定義,啟動多個技術重構類項目,消除“飛線”訪問,降低服務間的技術耦合,實現應用化定義要求的高內聚、低耦合的目標。

第二板斧:容器化

在完成“應用化”重構的基礎之上,我們將服務間存在的無狀態服務和有狀態服務進行剝離,同時嚴格避免無狀態服務對本地文件、本地服務等的依賴。另外,對于新產品組件內的服務模塊,我們統一構建了 Docker 鏡像,將原來只能在物理機上進行裸機部署的服務進行了容器化部署的改造,支持容器化的方式進行部署。除此之外,對于打包、升級、安裝等一系列流程,按照容器化標準進行改造,使產品組件的管理更加輕量和靈活。

第三板斧:容錯和降級

隨著產品組件數量的增多,我們需要進行服務間容錯和降級的處理,以避免當部分服務出現故障時對整體業務產生影響,盡量減少底層組件的報錯對實際用戶體驗造成的干擾。

首先,我們將依賴的底層應用組件劃分為強依賴和弱依賴兩種類型。對于強依賴類型的應用組件,我們提供一定的服務降級能力,比如,當查詢引擎不可用時,查詢請求會進行重試;但當系統整體查詢資源緊張時,查詢接口會嘗試降級并查找歷史緩存數據。對于弱依賴類型的應用組件,我們提供足夠的服務容錯能力,比如,當標簽系統完全不可用時,在分析模型中仍然可以使用基礎的元數據和屬性,只是不再提供關聯用戶標簽的分析能力。通過對服務容錯和降級的處理,大大減少了服務故障對客戶實際產品體驗的影響。

通過以上服務治理“三板斧”,我們已經取得了預期的效果。下圖是某客戶上線私有部署集群之后的查詢錯誤率情況統計,可以看到,分析模型查詢錯誤率已經從最高時 1.2% 降低到目前的 0.2% 左右。

圖 模擬數據

神策分析作為數據分析領域的代表產品,追求極致性能亦是我們持續努力的方向。在下一篇文章中,我們將在神策數據公眾號針對神策分析產品性能優化的五個方面做詳細介紹,敬請期待!