最近在思考 MDD 結(jié)合 SRE，花了兩周的時(shí)間打造了小程序端的可觀測(cè)平臺(tái)，接下來(lái)和大家分享一下整個(gè)心歷路程。談?wù)勎业囊恍﹩l(fā)，順便談?wù)劗?dāng)工程師具備 MDD 意識(shí)后，是否能如虎添翼。

事情的背景是這樣的，2 月 10 日，好大夫部分小程序用戶(hù)投訴上傳圖片失敗。整個(gè)排查過(guò)程有 10 多人參加，排查了三天才有結(jié)論。我們來(lái)回顧一下當(dāng)時(shí)的情況。

一、一團(tuán)亂麻，誰(shuí)人背鍋俠？

大家知道上傳圖片失敗問(wèn)題，一直是個(gè)老大難，因?yàn)槭〉脑蛱嗔?。?duì)一般的工程師而言，整個(gè)流程可能是一個(gè)黑盒模型，缺少一個(gè)抓手去分析問(wèn)題。

這時(shí)候工程師大腦中會(huì)有一堆問(wèn)號(hào)。

簡(jiǎn)單說(shuō)一下這個(gè)問(wèn)題是如何排查的。

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

雖然這次問(wèn)題是找到了，整整三天，包括運(yùn)維、前端、服務(wù)端、系統(tǒng)架構(gòu)組一共有 10 多人參入了排查。

痛定思痛，有沒(méi)方式縮短異常定位時(shí)長(zhǎng)呢？首先我們來(lái)看看用戶(hù)上傳會(huì)經(jīng)歷哪幾個(gè)環(huán)節(jié)。

一次網(wǎng)絡(luò)請(qǐng)求，中間其實(shí)經(jīng)歷了很多環(huán)節(jié)，細(xì)節(jié)這里就不展開(kāi)討論了，我們來(lái)看一下簡(jiǎn)化后的模型，用戶(hù)發(fā)起請(qǐng)求，到網(wǎng)絡(luò)節(jié)點(diǎn)，再到源站處理，再經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)返回響應(yīng)給用戶(hù)。

從圖中可以看出，上傳失敗存在幾個(gè)關(guān)鍵的環(huán)節(jié)中：用戶(hù)側(cè)、網(wǎng)絡(luò)節(jié)點(diǎn)、入口網(wǎng)關(guān)、后端服務(wù)。

• 可能是用戶(hù)側(cè)本地異常，如機(jī)器內(nèi)存不足，小程序閃退?？赡苁怯脩?hù)網(wǎng)絡(luò)不穩(wěn)定，還有可能是用戶(hù)在上傳圖片的過(guò)程中，中途將小程序切換到后臺(tái)，重新喚起小程序續(xù)傳失敗。
• 為了請(qǐng)求的安全和加速，在請(qǐng)求打到源站入口網(wǎng)關(guān)前，是先走運(yùn)營(yíng)商傳輸節(jié)點(diǎn)，傳輸節(jié)點(diǎn)也對(duì)接了多家運(yùn)營(yíng)商，傳輸不穩(wěn)定或命中防火墻策略也會(huì)造成上傳失敗。
• 入口網(wǎng)關(guān)用的是 kong，如果路由策略配置異常，或者 Kong 節(jié)點(diǎn)異常，或者某個(gè) upstream 節(jié)點(diǎn)異常都會(huì)造成上傳失敗。
• 后端圖片服務(wù)，如果處理能力不足，負(fù)載高，進(jìn)程夯住，或其他異常也會(huì)造成上傳失敗。

經(jīng)過(guò)思考，如何做到普適性呢，就要面臨以下幾個(gè)問(wèn)題。

• 異常能被有效地觀測(cè)到嗎？
• 異常定位對(duì)經(jīng)驗(yàn)要求很高，如何減少傳承成本？
• 異常分析有哪些提效的工具鏈，能平臺(tái)化嗎？
• 異常千千萬(wàn)萬(wàn)，再加上排練組合，真的能通過(guò)數(shù)據(jù)分析出來(lái)嗎？
• 異常分析平臺(tái)增加了學(xué)習(xí)成本，會(huì)不會(huì)增加工程師負(fù)擔(dān)，會(huì)質(zhì)疑研發(fā)平臺(tái)的受益？

深入思考，有點(diǎn)細(xì)思極恐，異常定位好難呀，提效異常定位更難！

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

很多工程師在分析異常的時(shí)候，往往聚焦單次問(wèn)題，一上來(lái)就陷入個(gè)案分析的細(xì)節(jié)，耗神耗力，心態(tài)都會(huì)查崩。

隨著網(wǎng)站拓?fù)涞难葸M(jìn)，異常定位也越來(lái)難，很多公司都在推進(jìn) SRE 體系建設(shè)，其中對(duì)可觀測(cè)性呼聲也越來(lái)越高。異常如何被量化，被觀測(cè)。這其實(shí)是一個(gè)“工程問(wèn)題”。

所謂工程問(wèn)題本質(zhì)上是數(shù)學(xué)，需要在一個(gè)定義良好的環(huán)境里，用定義良好的參數(shù)描寫(xiě)一個(gè)定義良好的問(wèn)題。引起網(wǎng)站異常的的原因有各種各樣，就像診斷患者一樣。統(tǒng)計(jì)分析健康的人和病患各項(xiàng)身體基能指標(biāo)的差異性，從而判斷病患程度及探究病因。

結(jié)合我的一些日常排障經(jīng)驗(yàn)，來(lái)看一下異常定位這個(gè)工程問(wèn)題。

異常定位需要在一個(gè)參照系中進(jìn)行，通過(guò)可視化界面去呈現(xiàn) SLI 的波動(dòng)性，而 SLI 的波動(dòng)性往往是和引起異常的根因相關(guān)聯(lián)。分析不同 SLI 波動(dòng)振幅差異性大小，從而推斷異常的可能性原因。

簡(jiǎn)單來(lái)說(shuō)，就是給異常進(jìn)行數(shù)學(xué)建模，并關(guān)聯(lián)到可觀測(cè)的 SLI 上。透過(guò) SLI 的表象反查異常原因。說(shuō)起來(lái)比較簡(jiǎn)單，和醫(yī)生診斷一樣，往往一種病理現(xiàn)象對(duì)應(yīng)了不同的病因，而同一種病因也會(huì)有不同的表象。有急性有慢性，還有擴(kuò)散傳遞性，一種病變可能引發(fā)一系列身體其他的病變，溯源病因可能需要多次會(huì)診。當(dāng)然經(jīng)驗(yàn)越豐富，數(shù)據(jù)越多，模型分析也就越準(zhǔn)確。

總結(jié)一下提效異常定位，首要任務(wù)就是需要量化異常，讓異?？杀挥^測(cè)到。其次就是友好的界面提示一步步引導(dǎo)大家定位問(wèn)題。

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

三、破而后立，MDD 劈開(kāi)黑盒模型

具體到上傳圖片的場(chǎng)景中，SRE 體系關(guān)注各個(gè)環(huán)節(jié)及整體鏈路的可用性。MDD 思想就是需要我們提煉合適的 SLI，設(shè)定 SLO，達(dá)成共識(shí)，進(jìn)而圍繞這些 SLO 開(kāi)展工作。

來(lái)一起看一下，上傳圖片各個(gè)環(huán)節(jié)中我們感興趣的點(diǎn)。

這里總結(jié)一些經(jīng)驗(yàn)：”兩點(diǎn)一線，分兩面，一面監(jiān)控畫(huà)像，一面異常定位“。

為了盡可能的觀測(cè)各個(gè)環(huán)節(jié)，我們需要梳理一個(gè)脈絡(luò)，如請(qǐng)求的開(kāi)始到結(jié)束，抓住這兩點(diǎn)，連成一線，分兩面，一面關(guān)注長(zhǎng)期趨勢(shì)，一面關(guān)注異常分析。

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

從圖中我們可以看出，評(píng)估鏈路各個(gè)環(huán)節(jié)是否有風(fēng)險(xiǎn)或者有異常，需要一個(gè)參考系，長(zhǎng)期的指標(biāo)趨勢(shì)和經(jīng)驗(yàn)閾值都是參考的數(shù)據(jù)源。故而設(shè)置 SLO 有兩種模式，第一根據(jù)經(jīng)驗(yàn)設(shè)置固定閾值，如 QPS 峰值不得大于 10k；第二是設(shè)置相對(duì)值，如 code=404 環(huán)比增加 20%。

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

為了異常的可觀測(cè)性，需要按不同的維度去細(xì)分 SLI，這次上傳圖片異常是由于微信灰度了特定的基礎(chǔ)庫(kù)，改造后需要收集終端相關(guān)信息，如設(shè)備平臺(tái)，設(shè)備型號(hào)，微信版本，微信基礎(chǔ)庫(kù)版本以及小程序版本。

在為上傳圖片鏈路建模分析的時(shí)候，也一直在考慮能否將這些經(jīng)驗(yàn)延伸到小程序整體的可觀測(cè)性中呢？

于是進(jìn)一步細(xì)化了分析維度，按不同的小程序包，統(tǒng)計(jì)了不同 code 碼、路由、domain 的請(qǐng)求數(shù)及時(shí)延。這樣就能更好地支持下鉆，并能遷移到整個(gè)小程序異常分析中。接下來(lái)一起看一下如何落地改造各個(gè)環(huán)節(jié)以便 SLI 的收集。

四、順勢(shì)而為，落地整體鏈路改造

1、用戶(hù)側(cè)

• 每次小程序啟動(dòng)的時(shí)候發(fā)起一個(gè)探包請(qǐng)求，會(huì)上報(bào)一下版本信息(平臺(tái)/版本/微信版本/微信基礎(chǔ)庫(kù)版本/小程序包名/小程序版本)，當(dāng)然為了安全審計(jì)不會(huì)收集用戶(hù)隱私相關(guān)的信息。探包請(qǐng)求還額外獲得了小程序啟動(dòng)頻次的粗略統(tǒng)計(jì)數(shù)據(jù)。
• 通過(guò) hash 算法生成版本信息的指紋 hash_key，后續(xù)的用戶(hù)請(qǐng)求 url 和 http header 中都攜帶這個(gè) hash_key。
• 通過(guò) hash_key 關(guān)聯(lián) kong 日志和版本信息，從而能提煉出終端不同維度的 SLI。
• 為了將整個(gè)鏈路串聯(lián)起來(lái)，小程序每次請(qǐng)求生成 trace_id，并通過(guò) header 透?jìng)飨氯ァ?/li>
• 小程序網(wǎng)絡(luò)不佳的時(shí)候，會(huì)先將 Error 等日志信息暫存到 LocalStorage 隊(duì)列中，等有網(wǎng)了再次上報(bào)。所有記錄日志的地方都會(huì)記上 trace_id，方便后續(xù)異常定位分析。

2、網(wǎng)絡(luò)節(jié)點(diǎn)

• 新增運(yùn)營(yíng)商標(biāo)識(shí)，方便對(duì)比分析不同運(yùn)營(yíng)商傳輸?shù)目捎眯浴?/li>
• 收集運(yùn)營(yíng)商的日志，存儲(chǔ)到 Clickhouse 中，方便后續(xù)分析，盡可能讓網(wǎng)絡(luò)傳輸節(jié)點(diǎn)可觀測(cè)。

3、入口網(wǎng)關(guān)

• 按業(yè)務(wù)類(lèi)型拆分 route_name，如上傳，訂單提交等等。
• route_name 支持打標(biāo)簽，如業(yè)務(wù)部門(mén)，所屬頁(yè)面等，方便告警監(jiān)控及識(shí)別到的風(fēng)險(xiǎn)通知到具體的業(yè)務(wù)部門(mén)。
• 插件支持生成 trace_id 或透?jìng)饕焉傻?trace_id，打通 KongLog 和后端服務(wù) TraceLog。

4、后端服務(wù)

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

5、可觀測(cè)平臺(tái)

• 鑒于之前研發(fā)了強(qiáng)大的分析器，只用添加分析，告警規(guī)則就能滿足這次場(chǎng)景需求。
• 為了節(jié)約研發(fā)成本，SLI 存儲(chǔ)到了 Clickhouse，可視化基于 Grafana 寫(xiě) SQL 繪制。
• 新增地理位置分析，將請(qǐng)求 ip 轉(zhuǎn)換成經(jīng)緯度，方便提煉地區(qū)維度的 SLI。

整個(gè)小程序日志上報(bào)的流程如下：

在改造的過(guò)程中也遇到了不少問(wèn)題。

• 控制 Error 信息大小。單條信息過(guò)大會(huì)導(dǎo)致 Flume 收集異常，重復(fù)收集獲丟失日志。
• 采樣上報(bào)，控制頻次。一般異常發(fā)生可能會(huì)產(chǎn)生連鎖反應(yīng)，瞬時(shí)產(chǎn)生大量日志，需要避免頻繁上報(bào)導(dǎo)致用戶(hù)帶寬的消耗。
• 降噪處理。如騰訊周期性安全掃描可能會(huì)產(chǎn)生一些干擾異常，如 499 等，會(huì)影響用戶(hù)維度 SLI 的準(zhǔn)確性，需要識(shí)別這些干擾進(jìn)行降噪處理。
• 提升分析性能，簡(jiǎn)化 SQL，很多分析需要連表查詢(xún)，數(shù)據(jù)量增大的時(shí)候，會(huì)存在性能問(wèn)題。于是添加了大量視圖，重建了不同維度的索引表。將數(shù)據(jù)按分鐘維度聚合成 SLI，避免了分析查詢(xún)?cè)既罩镜男阅荛_(kāi)銷(xiāo)。

接下來(lái)，一起看一下最終成果。

五、應(yīng)運(yùn)而生，建設(shè)可觀測(cè)性平臺(tái)

在整個(gè)改造的過(guò)程中，大家也看到了基本上都是一次投入，后續(xù)持續(xù)受益。整個(gè)流程運(yùn)轉(zhuǎn)起來(lái)后，后續(xù)就是提煉感興趣的 SLI，并基于 Grafana 展示即可。

整個(gè)可觀測(cè)性平臺(tái)是基于 Grafana+Clickhouse+Prometheus 構(gòu)建的，符合低代碼平臺(tái)研發(fā)，只要會(huì)寫(xiě) SQL 就行。

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

1、小程序分析首頁(yè)

首頁(yè)看板用于大盤(pán)投屏使用的，包括兩個(gè)部分，上部分是最近 15min 的瞬時(shí)數(shù)據(jù)，大于某個(gè)經(jīng)驗(yàn)閾值會(huì)標(biāo)紅顯示，下部分是長(zhǎng)期趨勢(shì)，比對(duì)同比和環(huán)比，各個(gè)面板都支持下鉆分析。

首頁(yè)一定要清爽，列出最關(guān)心的 SLI，如 QPS/UV、慢路由請(qǐng)求數(shù)、異常請(qǐng)求數(shù)。根據(jù)時(shí)延和 ErrorCode 分布，下鉆到具體的分析頁(yè)面。也可以通過(guò)分析長(zhǎng)期趨勢(shì)，查看小程序整體的狀態(tài)，如慢路由風(fēng)險(xiǎn)是否在增加。

2、長(zhǎng)期趨勢(shì)分析

通過(guò)首頁(yè)跳轉(zhuǎn)到長(zhǎng)期趨勢(shì)分析，可以查看最近 1 周/1 月/1 年的宏觀趨勢(shì)，這塊可以結(jié)合項(xiàng)目上線計(jì)劃，分析上線節(jié)點(diǎn)前后的變化，如 UV 是否有增加，慢路由是否有增多的趨勢(shì)，還可繼續(xù)下鉆分析具體哪些路由慢了。

3、Code 異常分析

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

整個(gè)過(guò)程其實(shí)是一個(gè)模型匹配問(wèn)答的模式。

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

• 同比環(huán)比是否具有差異性？分析當(dāng)日請(qǐng)求判斷是否具有突發(fā)性，分析一周數(shù)據(jù)判斷是否具有周期性。比如每晚直播訪問(wèn)量就會(huì)到峰值，這個(gè)點(diǎn)錯(cuò)誤率增加了可能是機(jī)器負(fù)載過(guò)高了，從而給排查提供一個(gè)方向。

• 是否具有路由差異性？是大面積無(wú)異常報(bào)錯(cuò)還是特定的路由異常，結(jié)合一周趨勢(shì)，從而給出排查方向。

• 同理分析異常特征是否具有終端平臺(tái)、微信版本、微信基礎(chǔ)庫(kù)版本、小程序版本差異性？

• 整個(gè)差異性分析的過(guò)程，其實(shí)是判斷差異顯著程度的過(guò)程，這里可能存在認(rèn)知誤區(qū)，如 iPhone 異常數(shù)比 oppo 大，很可能是 iPhone 總體訪問(wèn)基數(shù)大，這個(gè)時(shí)候其實(shí)是看各自長(zhǎng)期占比趨勢(shì)的。

如果判斷出來(lái)特定 route_name 異常具有顯著差異，可能是有突出抓取，或者業(yè)務(wù)代碼異常，或者業(yè)務(wù)機(jī)器負(fù)載過(guò)高等等，這時(shí)候需要下鉆分析。可下鉆到”NO5.路由詳情分析“，”NO6.抓取分析“。

4、慢路由風(fēng)險(xiǎn)分析

慢，會(huì)影響用戶(hù)體驗(yàn)，隨著業(yè)務(wù)的發(fā)展，如果不關(guān)注性能問(wèn)題，整個(gè)接口會(huì)朝熵增的方向惡化，可能會(huì)越來(lái)越慢。

一般重點(diǎn)關(guān)注 Top10 的慢路由，可以分析是長(zhǎng)期慢，還是突發(fā)抓取的慢，結(jié)合 APM 鏈路分析，整個(gè)請(qǐng)求慢在哪，是依賴(lài)中間件慢還是請(qǐng)求路徑過(guò)長(zhǎng)抑或是存在其他慢風(fēng)險(xiǎn)。這部分依然可下鉆到”NO5.路由詳情分析“，”NO6.抓取分析“。

5、路由詳情分析

這部分依然在做問(wèn)答題，主要是圍繞給定的 route_name 展開(kāi)分析的。

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

• 同比環(huán)比是否具有差異性？尤其是周期性存在明顯波動(dòng)，或突發(fā)波動(dòng)的會(huì)被優(yōu)先懷疑。由于是在分析具體的路由，首要懷疑是否有線上變更，如圖中 P99 具有顯著差異性，是因?yàn)楫?dāng)天業(yè)務(wù)有修改線上配置造成的。結(jié)合鏈路分析慢的問(wèn)題，最終優(yōu)化了鏈路請(qǐng)求解決了這個(gè)問(wèn)題。

• 是否是抓取造成的？另外一個(gè)常見(jiàn)的異常是由于蜘蛛突發(fā)抓取造成的，為了資源最大利用率，一般不會(huì)冗余過(guò)多的機(jī)器，當(dāng)蜘蛛突發(fā)抓取冷數(shù)據(jù)的時(shí)候可能會(huì)造成波動(dòng)。這部分主要是分析 UA，為了避免 UA 過(guò)長(zhǎng)帶來(lái)的分析性能損耗，采用了 hash ua 的方式。結(jié)合 ua 占比，ClientIP 占比，評(píng)估是否存在抓取的可能，具體可以下鉆到”NO6.抓取分析“。

• 是否存在地域差異性？如北京用戶(hù)異常占比過(guò)高，可能是北京鏈路出現(xiàn)了異常。

• 異常分布運(yùn)營(yíng)商節(jié)點(diǎn)是否存在顯著差異？比如騰訊回源造成緩存穿透。

• 異常分布在后端節(jié)點(diǎn)上是否具有顯著差異性？從而判斷是否存在機(jī)器問(wèn)題。這部分可以繼續(xù)往機(jī)器的維度下鉆，分析是 CPU 或其他資源異常。

• 如果以上常見(jiàn)場(chǎng)景都沒(méi)命中，可以分析客戶(hù)端相關(guān)信息是否具有顯著差異性。

6、抓取分析

抓取分析就比較簡(jiǎn)單了，判斷 UA 和 ClientIP 訪問(wèn)占比，抓取一般特征是單個(gè) UA 訪問(wèn)量突增，ClientIP 比較集中，結(jié)合 QPM 長(zhǎng)期趨勢(shì)，判斷是正常訪問(wèn)還是抓取。

7、程序異常分析概覽

為了更好的反映小程序的異常，會(huì)收集異常信息進(jìn)行統(tǒng)計(jì)分析，這里和前面類(lèi)似了，就不展開(kāi)分析了。

六、道阻且長(zhǎng), 思考從 1 到 n 的演化

做到這，小程序可觀測(cè)性平臺(tái)已經(jīng)從 0 到 1 了，但這只是一個(gè)開(kāi)始，后續(xù)要如何演化推進(jìn)，還面臨了很多困難。

1、如何驗(yàn)證？

可觀測(cè)性平臺(tái)是否能幫助異常定位呢，線上真實(shí)異常可以驗(yàn)證，但太被動(dòng)了，能否主動(dòng)模擬異常？如模擬抓取，或單個(gè)機(jī)器異常。這部分也是今年主要發(fā)力的地方，會(huì)通過(guò)混沌實(shí)驗(yàn)平臺(tái)去輔助故障演練。

2、如何推廣？

小程序面向的業(yè)務(wù)場(chǎng)景茫茫多，如何讓工程師轉(zhuǎn)變習(xí)慣去適應(yīng)新的排障工具，也是一個(gè)難點(diǎn)。這部分除了培訓(xùn)分享以及持續(xù)迭代平臺(tái)外，可以召集大家攻防演練，在實(shí)踐中讓大家快速掌握新工具，發(fā)現(xiàn)平臺(tái)的不足一起共建。

3、如何橫向遷移？

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

4、如何更快定位異常？

工程問(wèn)題是需要數(shù)學(xué)建模，可觀測(cè)性只是第一步，要想提效不能靠人腦經(jīng)驗(yàn)分析，如何評(píng)估異常的顯著差異及關(guān)聯(lián)性，需要選擇相應(yīng)的算法，通過(guò)函數(shù)擬合建模分析。

5、如何優(yōu)化用戶(hù)體驗(yàn)？

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

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

? ?