作者：王文華(連墨)
千牛是阿里巴巴商家的多端開放式工作平臺，每天服務數百萬的活躍商家在移動和桌面端操作業務，包含店鋪管理、客服接待、資訊訊息等多項功能。
同時，千牛本身是一個開放的端體系架構，二三方能通過開放體系（我們稱為外掛體系）為商家提供服務。之所以叫做外掛，是因為我們在商家的經營鏈路中，定義了若干個開放節點和標準，由業務方根據標準實現，並完成相應的功能。正是因為這些標準和規範的存在，使得不同的外掛之間可以串聯起經營鏈路，從而規避因商家選擇不同外掛所導致的功能閉環被打破問題。
下面是千牛定義的開放節點：
開放促進了業務與三方ISV的入駐，使得千牛能更加充分地利用外部資源服務，比如加快開發進度，滿足商家的定製化需求等。一款三方外掛需要經歷4個階段：ISV開發，服務市場上架，商家購買，在千牛上使用。在商家未選擇預設經營外掛的情況下，千牛也有一套規則引導使用者優先試用外掛的免費版本，ISV 則可在商家試用過程中引導升級訂購來盈利。但是開放也會帶來相應的問題 —— 商家體驗問題。
為了提升商家體驗，我們發起了開放體驗升級專案。經過持續的治理，千牛月均開放輿情數量實現了減少50%。那麼，千牛有哪些輿情，防治整體方案又是如何設計的呢？
問題和產生原因
千牛開放輿情的特點
由於開放的特點，千牛開放輿情比較分散，且成因複雜。千牛上的工具數量眾多，由二三方團隊提供，部分二方工具歷史悠久，維護投入不足，而ISV間的技術能力參差不齊。開放技術棧多，有早期的H5，中期的QAP（weex封裝的開放框架），以及小程式。外掛啟動鏈路長，從前端到ISV服務端涉及7個以上技術鏈路，容易受網路和各個服務抖動影響。眾多的不穩定因素給開放輿情治理帶來了挑戰。
開放體驗的核心問題是什麼？
開放類體驗問題多樣，主要包含以下三類核心體驗問題：
- 外掛開啟整體鏈路較長，在投放，商業化訂購，容器執行載入各個環節都會影響外掛啟動；
- 千牛端因為有主子賬號的許可權管控的設計，主賬號可以在各功能限制子賬號許可權，子賬號在使用時會出現許可權不足的阻斷性問題；
- ISV或二方業務自身邏輯問題多，千牛作為平臺目前缺少足夠線上問題感知能力和有效的推進治理的抓手。
防治整體方案
- 優化外掛啟動鏈路: 提升啟動鏈路技術產品的容錯能力，優化開啟成功率到99.7%以上。
- 建設許可權申請閉環: 提升許可權申請和審批效率，優化子賬號使用外掛的體驗。
- 建立資料衡量體系: 沉澱驅動業務優化的抓手。
千牛上業務多，輿情原因複雜且變化快，只以輿情問題切入單個解決是不夠的。開放業務的的治理是循序漸進的，需要一方面解決已知問題，另一方面對外掛啟動和執行階段的核心節點建立衡量標準和穩定性監控，鞏固治理成果。以治理-監控-預防-優化的思路驅動輿情下降。
啟動鏈路優化
啟動流程介紹
- 協議路由: 千牛官方定義了一組開放節點(坑位)和對應的標準協議(e.g.tradeDetail 檢視訂單詳情)，由ISV根據協議實現承接的功能。這個階段需要解析配置的協議，路由到使用者設定或運營配置的預設外掛appkey；
- 外掛元資訊查詢: 從服務端下發的外掛列表中，找到目標appkey對應的外掛元資訊；
- 許可權校驗: 校驗子賬號是否有許可權開啟此外掛；
- 商業化保障: 為新使用者或訂購關係過期的使用者，完成免費版本的訂購；
- 前置授權QAP：對於三方外掛，需要使用者顯式授權來允許三方ISV訪問資料；
- 容器路由和渲染: 根據外掛元資訊, 組裝業務引數並交給對應的容器渲染。
全鏈路監控
首先需要定位外掛啟動失敗的原因和分佈，並以此確定後續治理和優化方案。雖然理論上可以對每輿個情分析日誌，但實際操作中，由於工作量大，而且缺少全域性統計視角。因此，首先建立外掛啟動全鏈路監控，保留錯誤上下文資訊，統計準確的啟動成功率和失敗原因分佈，為優化提供衡量基礎。
埋點維度包括目標外掛appkey, 技術型別（H5, QAP, 小程式)，出錯階段，錯誤描述，開啟外掛來源或入口資訊，每個階段啟動和結束的時間。
這些維度有幾個作用：
- 配置不同維度的告警，比如H5的外掛成功率突然下降或者某個階段出錯的次數明顯增加；
- 在整體成功率變化時，方便比較不同維度的趨勢，快速定位是哪個級別的問題；
- 出錯階段資訊方便按階段來看出錯分佈，分階段優化成功率；
- 開啟來源和入口資訊提供了更多問題出現的場景資訊。
外掛啟動優化專項
通過全鏈路監控可以看到有兩類錯誤，一類是外掛開啟的前置鏈路失敗，另一類是訂購關係未建立；
前置鏈路容錯能力提升
啟動前置鏈路錯誤的主要原因是弱網或服務端抖動造成的啟動鏈路關鍵資訊缺失，比如外掛元資訊和小程式包，通過異常補償優化。千牛通過梳理了核心經營鏈路的頭部外掛，內建元資訊，利用訂閱關係和場景化資訊預下載小程式包, 優化後小程式包命中率從85%升高到97%，整體失敗次數下降55% 。
商業化保障方案升級
在千牛端，商家必須和外掛建立訂購關係後才能使用外掛，是週期訂購的商業化模式。在使用前千牛為商家續訂免費版保證主要功能可用。通過Review舊方案，發現原來的產品鏈路不能覆蓋訂購失敗等場景。升級商業化保障方案後相關錯誤次數下降56.7%，前置鏈路耗時下降170ms。策略如下：
- 異常補償：協調服務端增加訂購狀態資訊，如果在建立訂購中，則延時重試查詢，等待關係建立後再開啟 (訂購流程涉及匯金等外部系統，生效時間波動大)；如果訂購無法成功 (e.g.ISV被處罰，訂購凍結)，引導更換同類外掛 (並用質量分加權影響排序，驅動ISV優化)
- 效能優化：給前置訂購鏈路增加頻控策略，降低前置呼叫頻率。增加後置續訂延長有效期，避免進入前置流程，同時也能覆蓋那些沒有通過外掛流程開啟小程式的場景。對於最常用的預設外掛，增加閒時靜默續訂。
啟動優化專項結果：成功率從99%升到99.7% ，前置鏈路從350ms到130ms；
許可權申請鏈路建設
賣家端以主子賬號來做團隊協同，子賬號會遇到許可權不足的開放體驗問題。今年千牛建設了移動端的許可權申請鏈路，來優化商家的子賬號使用體驗和許可權審批效率。
申請鏈路：
- 擴充客戶端API給二方，由二方主動呼叫觸發申請引導，滿足通用需求；因為二方校驗方式靈活，缺少統一收口。
- 切面檢測三方鏈路上的許可權不足，自動觸發申請提示。由於歷史原因，三方小程式分兩類 (許可權粒度維度)，有不同的檢測方式。a. 從QAP升級的小程式: 打精細化授權標，授權粒度是許可權包(匹配TOP響應的錯誤碼) b. 直接以小程式身份入駐：沒有精細化授權標，授權粒度是小程式應用級別 (匹配 getAuthUserInfo API錯誤碼）。通過監聽小程式API呼叫，觸發申請流程；前者還需用TOP API名去服務端換許可權包和許可權點資訊後，再建立工單通知到主賬號審批。
審批鏈路： 主賬號收到待審批訊息，點開直達對應許可權審批詳情頁。
優化後，子賬號許可權不足的錯誤次數下降57% ，相關輿情下降52% 。
資料衡量體系建設
開放工具的功能和質量主要取決於業務邏輯和服務可用性和穩定性，因此要定義核心指標，監控線上異常，及時處理。資料衡量體系建設主要包括體感指標建設、輿情SOP優化、以及開放體驗大盤搭建。
體感指標建設
通過小程式的事件機制建設了TOP和雲應用的業務成功率，自建了體感白屏率（H5，weex和小程式），擴充小程式白屏率檢測方案，多次監控到業務方線上問題，推動回滾和修復。
外掛核心執行質量指標
下圖千牛外掛執行期間的核心節點，可以通過建立對應指標全面監控線上外掛執行的穩定性。除了常見的純技術指標：介面業務成功率，bridge API成功率，JS error率等，千牛還建設了體感白屏率來反應外掛線上執行質量。
體感白屏率
雖然有了核心節點的技術指標，但這些技術指標並不能完全覆蓋功能不可用的場景：某日雲應用擴容，新機器配置問題導致訂單資料為空，但介面是成功的；某些技術指標錯誤，並不代表一定會功能不可用，比如部分JS錯誤。所以需要建立指標，從體感上直接度量可用行。其中，千牛外掛功能不可用最常見的問題是白屏。
白屏率定義：在一定時間內，頁面元素得不到及時的展現，導致頁面佈局出不來，或者出現錯誤的打底頁面，或者部分的圖片出不來的頁面，定義為白屏。
檢測方案：在千牛端小程式場景下，主要分為噪點場景過濾，白屏檢測，和結果上報三個階段。其中結果上報主要使用魔兔埋點平臺上報和告警，不再贅述。
噪點場景過濾：
- 存在開啟某個小程式頁面A後，ISV程式碼自動跳轉/切換到其他頁面B，當使用者訪問頁面A才會觸發真正的渲染。因此如果在A不可見的時候檢測，會被認為是白屏。這種技術實現差異造成的偽白屏並不影響使用者體感，並不是我們的檢測目標；
- 千牛大量的小程式是三方提供的，在訪問使用者資料前強制要求授權，因此如果檢測時，還卡在授權流程中，小程式頁面是白屏的，可檢測授權彈框避免誤判。
- 部分小程式頁面使用了同層渲染的能力，比如使用了視訊，地圖等元件的小程式頁面。這些元素不是正常的html元素，無法被JS探測到，但並不是白屏，需要通過配置頁面白名單的方式過濾。
檢測策略：
白屏檢測主要策略是統計有效元素個數，有效元素指的是文字，圖片等有效資訊載體。在小程式和H5外掛上，通過注入JS到webview, 獲取介面元素的統計資訊。千牛端和大多數C端應用不同，千牛存在不少重輸入的頁面，比如問答外掛的回答頁面有大片面積的輸入框，這種情況下認為不是白屏，通過檢測是否存在輸入框相關元件判斷。在千牛端，如果商家沒有訂單，頁面可能出現較大面積的空白，所以需要過濾存在"還沒有", "暫時沒有"等白名單文案，避免誤判為白屏。
經典案例
二方業務白屏
4月某二方業務線上用4g網路訪問情況下，出現白屏。白屏率指標及時告警，白屏率可以看到分鐘級別的明顯變化，修復後回落，避免了輿情飆升。
三方業務改版觸發限流
3月收到某頭部三方外掛呼叫物流介面告警，主要錯誤是被限流，成功率只有80%，明顯低於平均水平。原因是該ISV新版本在訂單列表查詢物流資訊，導致呼叫物流介面量太大觸發被限流。通知ISV從產品層面進行了調整後成功率明顯上升。
輿情SOP方案
千牛上使用者反饋很多是從全域性反饋入口進行反饋，缺少外掛上下文；而且使用者對外掛心智不足，反饋問題的時候指向性弱，輿情分析和問題驅動難。千牛的方案是記錄外掛使用動線，在使用者反饋外掛類輿情時，展示最近使用工具，引導選擇反饋目標外掛，給輿情資訊增加目標外掛資訊和問題分類，便於統計和告警。上線後，帶有外掛appkey的開放輿情佔比從11.95%升到95% 。
開放體驗大盤
通過整合輿情、技術指標和體感資料，千牛建立了開放體驗大盤，做到了外掛體驗可跟蹤、可衡量。依據外掛輿情數，技術指標，體感指標建立外掛質量大盤，對千牛外掛質量一目瞭然，成為推進二三方優化的重要抓手。
總結
千牛優化了外掛啟動容錯能力、建設了子賬號許可權申請產品鏈路，提升了自身鏈路的可用性。也通過建設體感指標，提升輿情反饋和分析能力，搭建開放體驗大盤，對線上外掛執行質量建立了上帝視角，既能及時發現線上問題，也能通過資料有的放矢地驅動二三方業務優化，系統的提升了商家在千牛端使用開放工具的體驗。
關注我們，每週 3 篇移動技術實踐&乾貨給你思考！