最近在思考 MDD 結合 SRE，花了兩周的時間打造了小程序端的可觀測平臺，接下來和大家分享一下整個心歷路程。談談我的一些啟發，順便談談當工程師具備 MDD 意識后，是否能如虎添翼。

事情的背景是這樣的，2 月 10 日，好大夫部分小程序用戶投訴上傳圖片失敗。整個排查過程有 10 多人參加，排查了三天才有結論。我們來回顧一下當時的情況。

一、一團亂麻，誰人背鍋俠？

大家知道上傳圖片失敗問題，一直是個老大難，因為失敗的原因太多了。對一般的工程師而言，整個流程可能是一個黑盒模型，缺少一個抓手去分析問題。

這時候工程師大腦中會有一堆問號。

簡單說一下這個問題是如何排查的。

• 懷疑用戶網絡問題，聯系用戶切換網絡嘗試依然失敗。加上分析 Kong 日志，發現部分用戶重試多次都是失敗，切換到好大夫的 APP 能上傳成功，前端認為不是用戶側網絡問題。
• 懷疑鏈路傳輸問題，我們有多家網絡節點運營商，嘗試切換鏈路，甚至直接回源，問題還依然存在。期間通過抓包并和運營商技術一起排查未能明確問題原因，給出的反饋還是用戶側問題。
• 懷疑小程序版本問題，2 月 9 日有個業務方向上線了小程序，修改的是 http2 相關的，大家很興奮，時間點也能對上，覺得抓到罪魁禍首了，然后就是緊急上線，用戶更新包后問題依然存在，這下打擊有點大。
• 懷疑 Kong 進程處理異常。前面幾個關鍵點都懷疑了，大家誰都說服不了誰的問題。11 日晚上重啟 Kong 進程，擔心 Kong 進程啟動太久，有垃圾沒有回收，有點病急亂投醫了，試一試總不差。重啟后第二天問題依然沒有得到緩解。
• 經過幾輪排查，對比最近幾天 code=400 的占比趨勢，2 月 10 ~ 11 日比之前多了一倍，code=400 的 route_name 基本上也都是小程序側的上傳圖片接口?；旧隙ㄎ皇切〕绦蚨说膯栴}，越發懷疑微信端是否異常了。聯系微信社區，聯系微信內部開發，2 月 13 日下午才得到反饋：“2 月 9 日下午微信升級了基礎庫，灰度了 1%IOS 用戶，并于 2 月 11 日回滾，部分用戶還有異常需要清理緩存”。

雖然這次問題是找到了，整整三天，包括運維、前端、服務端、系統架構組一共有 10 多人參入了排查。

痛定思痛，有沒方式縮短異常定位時長呢？首先我們來看看用戶上傳會經歷哪幾個環節。

一次網絡請求，中間其實經歷了很多環節，細節這里就不展開討論了，我們來看一下簡化后的模型，用戶發起請求，到網絡節點，再到源站處理，再經過網絡節點返回響應給用戶。

從圖中可以看出，上傳失敗存在幾個關鍵的環節中：用戶側、網絡節點、入口網關、后端服務。

• 可能是用戶側本地異常，如機器內存不足，小程序閃退。可能是用戶網絡不穩定，還有可能是用戶在上傳圖片的過程中，中途將小程序切換到后臺，重新喚起小程序續傳失敗。
• 為了請求的安全和加速，在請求打到源站入口網關前，是先走運營商傳輸節點，傳輸節點也對接了多家運營商，傳輸不穩定或命中防火墻策略也會造成上傳失敗。
• 入口網關用的是 kong，如果路由策略配置異常，或者 Kong 節點異常，或者某個 upstream 節點異常都會造成上傳失敗。
• 后端圖片服務，如果處理能力不足，負載高，進程夯住，或其他異常也會造成上傳失敗。

經過思考，如何做到普適性呢，就要面臨以下幾個問題。

• 異常能被有效地觀測到嗎？
• 異常定位對經驗要求很高，如何減少傳承成本？
• 異常分析有哪些提效的工具鏈，能平臺化嗎？
• 異常千千萬萬，再加上排練組合，真的能通過數據分析出來嗎？
• 異常分析平臺增加了學習成本，會不會增加工程師負擔，會質疑研發平臺的受益？

深入思考，有點細思極恐，異常定位好難呀，提效異常定位更難！

二、追本溯源，能否提效異常定位？

很多工程師在分析異常的時候，往往聚焦單次問題，一上來就陷入個案分析的細節，耗神耗力，心態都會查崩。

隨著網站拓撲的演進，異常定位也越來難，很多公司都在推進 SRE 體系建設，其中對可觀測性呼聲也越來越高。異常如何被量化，被觀測。這其實是一個“工程問題”。

所謂工程問題本質上是數學，需要在一個定義良好的環境里，用定義良好的參數描寫一個定義良好的問題。引起網站異常的的原因有各種各樣，就像診斷患者一樣。統計分析健康的人和病患各項身體基能指標的差異性，從而判斷病患程度及探究病因。

結合我的一些日常排障經驗，來看一下異常定位這個工程問題。

異常定位需要在一個參照系中進行，通過可視化界面去呈現 SLI 的波動性，而 SLI 的波動性往往是和引起異常的根因相關聯。分析不同 SLI 波動振幅差異性大小，從而推斷異常的可能性原因。

簡單來說，就是給異常進行數學建模，并關聯到可觀測的 SLI 上。透過 SLI 的表象反查異常原因。說起來比較簡單，和醫生診斷一樣，往往一種病理現象對應了不同的病因，而同一種病因也會有不同的表象。有急性有慢性，還有擴散傳遞性，一種病變可能引發一系列身體其他的病變，溯源病因可能需要多次會診。當然經驗越豐富，數據越多，模型分析也就越準確。

總結一下提效異常定位，首要任務就是需要量化異常，讓異?？杀挥^測到。其次就是友好的界面提示一步步引導大家定位問題。

接下來一起探討一下如何建設小程序上傳圖片整體鏈路的可觀測性，去嘗試建模分析異常定位這個工程問題。

三、破而后立，MDD 劈開黑盒模型

具體到上傳圖片的場景中，SRE 體系關注各個環節及整體鏈路的可用性。MDD 思想就是需要我們提煉合適的 SLI，設定 SLO，達成共識，進而圍繞這些 SLO 開展工作。

來一起看一下，上傳圖片各個環節中我們感興趣的點。

這里總結一些經驗：”兩點一線，分兩面，一面監控畫像，一面異常定位“。

為了盡可能的觀測各個環節，我們需要梳理一個脈絡，如請求的開始到結束，抓住這兩點，連成一線，分兩面，一面關注長期趨勢，一面關注異常分析。

具體提煉 SLI 可參考 Google VALET(Volume、Available、Latency、Error、Ticket)模型。

從圖中我們可以看出，評估鏈路各個環節是否有風險或者有異常，需要一個參考系，長期的指標趨勢和經驗閾值都是參考的數據源。故而設置 SLO 有兩種模式，第一根據經驗設置固定閾值，如 QPS 峰值不得大于 10k；第二是設置相對值，如 code=404 環比增加 20%。

有了這些準備工作，提煉了以下 SLI 和 SLO，大家可以參考一下。

為了異常的可觀測性，需要按不同的維度去細分 SLI，這次上傳圖片異常是由于微信灰度了特定的基礎庫，改造后需要收集終端相關信息，如設備平臺，設備型號，微信版本，微信基礎庫版本以及小程序版本。

在為上傳圖片鏈路建模分析的時候，也一直在考慮能否將這些經驗延伸到小程序整體的可觀測性中呢？

于是進一步細化了分析維度，按不同的小程序包，統計了不同 code 碼、路由、domain 的請求數及時延。這樣就能更好地支持下鉆，并能遷移到整個小程序異常分析中。接下來一起看一下如何落地改造各個環節以便 SLI 的收集。

四、順勢而為，落地整體鏈路改造

1、用戶側

• 每次小程序啟動的時候發起一個探包請求，會上報一下版本信息(平臺/版本/微信版本/微信基礎庫版本/小程序包名/小程序版本)，當然為了安全審計不會收集用戶隱私相關的信息。探包請求還額外獲得了小程序啟動頻次的粗略統計數據。
• 通過 hash 算法生成版本信息的指紋 hash_key，后續的用戶請求 url 和 http header 中都攜帶這個 hash_key。
• 通過 hash_key 關聯 kong 日志和版本信息，從而能提煉出終端不同維度的 SLI。
• 為了將整個鏈路串聯起來，小程序每次請求生成 trace_id，并通過 header 透傳下去。
• 小程序網絡不佳的時候，會先將 Error 等日志信息暫存到 LocalStorage 隊列中，等有網了再次上報。所有記錄日志的地方都會記上 trace_id，方便后續異常定位分析。

2、網絡節點

• 新增運營商標識，方便對比分析不同運營商傳輸的可用性。
• 收集運營商的日志，存儲到 Clickhouse 中，方便后續分析，盡可能讓網絡傳輸節點可觀測。

3、入口網關

• 按業務類型拆分 route_name，如上傳，訂單提交等等。
• route_name 支持打標簽，如業務部門，所屬頁面等，方便告警監控及識別到的風險通知到具體的業務部門。
• 插件支持生成 trace_id 或透傳已生成的 trace_id，打通 KongLog 和后端服務 TraceLog。

4、后端服務

• 增加日志埋點，分析不同圖片尺寸大小的上傳下載相關的指標。
• 定義好不同的 code 碼，方便異常定位分析。

5、可觀測平臺

• 鑒于之前研發了強大的分析器，只用添加分析，告警規則就能滿足這次場景需求。
• 為了節約研發成本，SLI 存儲到了 Clickhouse，可視化基于 Grafana 寫 SQL 繪制。
• 新增地理位置分析，將請求 ip 轉換成經緯度，方便提煉地區維度的 SLI。

整個小程序日志上報的流程如下：

在改造的過程中也遇到了不少問題。

• 控制 Error 信息大小。單條信息過大會導致 Flume 收集異常，重復收集獲丟失日志。
• 采樣上報，控制頻次。一般異常發生可能會產生連鎖反應，瞬時產生大量日志，需要避免頻繁上報導致用戶帶寬的消耗。
• 降噪處理。如騰訊周期性安全掃描可能會產生一些干擾異常，如 499 等，會影響用戶維度 SLI 的準確性，需要識別這些干擾進行降噪處理。
• 提升分析性能，簡化 SQL，很多分析需要連表查詢，數據量增大的時候，會存在性能問題。于是添加了大量視圖，重建了不同維度的索引表。將數據按分鐘維度聚合成 SLI，避免了分析查詢原始日志的性能開銷。

接下來，一起看一下最終成果。

五、應運而生，建設可觀測性平臺

在整個改造的過程中，大家也看到了基本上都是一次投入，后續持續受益。整個流程運轉起來后，后續就是提煉感興趣的 SLI，并基于 Grafana 展示即可。

整個可觀測性平臺是基于 Grafana+Clickhouse+Prometheus 構建的，符合低代碼平臺研發，只要會寫 SQL 就行。

我們一起看一下具體的看板。

1、小程序分析首頁

首頁看板用于大盤投屏使用的，包括兩個部分，上部分是最近 15min 的瞬時數據，大于某個經驗閾值會標紅顯示，下部分是長期趨勢，比對同比和環比，各個面板都支持下鉆分析。

首頁一定要清爽，列出最關心的 SLI，如 QPS/UV、慢路由請求數、異常請求數。根據時延和 ErrorCode 分布，下鉆到具體的分析頁面。也可以通過分析長期趨勢，查看小程序整體的狀態，如慢路由風險是否在增加。

2、長期趨勢分析

通過首頁跳轉到長期趨勢分析，可以查看最近 1 周/1 月/1 年的宏觀趨勢，這塊可以結合項目上線計劃，分析上線節點前后的變化，如 UV 是否有增加，慢路由是否有增多的趨勢，還可繼續下鉆分析具體哪些路由慢了。

3、Code 異常分析

在首頁可以觀察異常 code 分布，下鉆到具體的 code 分析頁，這里模擬分析一下 code=400 量增加的場景。

整個過程其實是一個模型匹配問答的模式。

• 是否需要人工介入？假定 SLO 為 code=400 的錯誤率<0.5%，p = total_400_request / (total_200_request + total_400_request)，如 code=200 訪問量是 10K，如果這時候 400 訪問量達到 500 則需要人工介入排查。

• 同比環比是否具有差異性？分析當日請求判斷是否具有突發性，分析一周數據判斷是否具有周期性。比如每晚直播訪問量就會到峰值，這個點錯誤率增加了可能是機器負載過高了，從而給排查提供一個方向。

• 是否具有路由差異性？是大面積無異常報錯還是特定的路由異常，結合一周趨勢，從而給出排查方向。

• 同理分析異常特征是否具有終端平臺、微信版本、微信基礎庫版本、小程序版本差異性？

• 整個差異性分析的過程，其實是判斷差異顯著程度的過程，這里可能存在認知誤區，如 iPhone 異常數比 oppo 大，很可能是 iPhone 總體訪問基數大，這個時候其實是看各自長期占比趨勢的。

如果判斷出來特定 route_name 異常具有顯著差異，可能是有突出抓取，或者業務代碼異常，或者業務機器負載過高等等，這時候需要下鉆分析?？上裸@到”NO5.路由詳情分析“，”NO6.抓取分析“。

4、慢路由風險分析

慢，會影響用戶體驗，隨著業務的發展，如果不關注性能問題，整個接口會朝熵增的方向惡化，可能會越來越慢。

一般重點關注 Top10 的慢路由，可以分析是長期慢，還是突發抓取的慢，結合 APM 鏈路分析，整個請求慢在哪，是依賴中間件慢還是請求路徑過長抑或是存在其他慢風險。這部分依然可下鉆到”NO5.路由詳情分析“，”NO6.抓取分析“。

5、路由詳情分析

這部分依然在做問答題，主要是圍繞給定的 route_name 展開分析的。

• code 分布是否具有顯著差異性，如 P99 時延增加了，可能是緩存命中率 code=304 過低了。

• 同比環比是否具有差異性？尤其是周期性存在明顯波動，或突發波動的會被優先懷疑。由于是在分析具體的路由，首要懷疑是否有線上變更，如圖中 P99 具有顯著差異性，是因為當天業務有修改線上配置造成的。結合鏈路分析慢的問題，最終優化了鏈路請求解決了這個問題。

• 是否是抓取造成的？另外一個常見的異常是由于蜘蛛突發抓取造成的，為了資源最大利用率，一般不會冗余過多的機器，當蜘蛛突發抓取冷數據的時候可能會造成波動。這部分主要是分析 UA，為了避免 UA 過長帶來的分析性能損耗，采用了 hash ua 的方式。結合 ua 占比，ClientIP 占比，評估是否存在抓取的可能，具體可以下鉆到”NO6.抓取分析“。

• 是否存在地域差異性？如北京用戶異常占比過高，可能是北京鏈路出現了異常。

• 異常分布運營商節點是否存在顯著差異？比如騰訊回源造成緩存穿透。

• 異常分布在后端節點上是否具有顯著差異性？從而判斷是否存在機器問題。這部分可以繼續往機器的維度下鉆，分析是 CPU 或其他資源異常。

• 如果以上常見場景都沒命中，可以分析客戶端相關信息是否具有顯著差異性。

6、抓取分析

抓取分析就比較簡單了，判斷 UA 和 ClientIP 訪問占比，抓取一般特征是單個 UA 訪問量突增，ClientIP 比較集中，結合 QPM 長期趨勢，判斷是正常訪問還是抓取。

7、程序異常分析概覽

為了更好的反映小程序的異常，會收集異常信息進行統計分析，這里和前面類似了，就不展開分析了。

六、道阻且長, 思考從 1 到 n 的演化

做到這，小程序可觀測性平臺已經從 0 到 1 了，但這只是一個開始，后續要如何演化推進，還面臨了很多困難。

1、如何驗證？

可觀測性平臺是否能幫助異常定位呢，線上真實異常可以驗證，但太被動了，能否主動模擬異常？如模擬抓取，或單個機器異常。這部分也是今年主要發力的地方，會通過混沌實驗平臺去輔助故障演練。

2、如何推廣？

小程序面向的業務場景茫茫多，如何讓工程師轉變習慣去適應新的排障工具，也是一個難點。這部分除了培訓分享以及持續迭代平臺外，可以召集大家攻防演練，在實踐中讓大家快速掌握新工具，發現平臺的不足一起共建。

3、如何橫向遷移？

其實這次只是做了小程序端的可觀測性，能否延伸到其他各端(觸屏/PC/APP)呢？能否推廣到中間件，能否推廣到其他業務呢？試想一下，業務團隊基于 MDD 達成共識后，工程師很多工作就能被量化了，比如優化了幾個慢路由，降低了 p99 時延，先于用戶發現問題，加速定位問題，是否提升了 UV 等等，都可被觀測到。其次工程師可以主動發現一些問題，如上線后接口變慢了，到底慢在了哪里，是否存在慢 SQL 風險等等，就會主動去探尋風險點。

4、如何更快定位異常？

工程問題是需要數學建模，可觀測性只是第一步，要想提效不能靠人腦經驗分析，如何評估異常的顯著差異及關聯性，需要選擇相應的算法，通過函數擬合建模分析。

5、如何優化用戶體驗？

數據分析，不同的人會有不同的思路，可觀測性反映的現象由于每個人的經驗不同，排查思路可能也迥異。另外異常分析定位平臺無法窮舉所有的異常，就像患者病因溯源一樣，很多分析場景具有跳躍性。平臺能做的就是盡可能多的給出工程師常用排障按鈕，就像超鏈接一樣，讓大家按照自己的思路去排查。后續分析這些行為，選擇最短路徑，固化到程序中，從而達到 AI 智能根因定位。

縮短 MTTR 還有很長的路要走，一起共勉，道阻且長, 行則將至，行而不輟, 未來可期。

? ?