作者白玙、左知、四拾背景一支技術(shù)能力成熟的團隊業(yè)務(wù)全棧上云可觀測棧完備——這樣的團隊最需要回答的不是“能不能做”而是“哪些該自己做、哪些該交給云”。武漢精臣面對的正是這道選擇題在自建 SRE 平臺已成體系的前提下可觀測數(shù)據(jù)底座和運維數(shù)字孿生是繼續(xù)自己造還是接入一套更完整的現(xiàn)成能力NIIMBOT 精臣致力于以創(chuàng)新讓物的管理更簡單。自 2012 年創(chuàng)立以來精臣在智能標(biāo)簽標(biāo)識打印硬件、打印云服務(wù)平臺及企業(yè)效能管理系統(tǒng)領(lǐng)域不斷革新技術(shù)產(chǎn)品與解決方案重塑標(biāo)簽標(biāo)識打印的智能化和便捷性。精臣的產(chǎn)品應(yīng)用已覆蓋商業(yè)零售、通信、辦公、工業(yè)、醫(yī)療實驗、家居生活等領(lǐng)域累計服務(wù)全球 2200 萬用戶。業(yè)務(wù)挑戰(zhàn)伴隨業(yè)務(wù)快速發(fā)展與全球化戰(zhàn)略推進系統(tǒng)規(guī)模與復(fù)雜度呈指數(shù)級增長運維復(fù)雜度被拉升到新量級。精臣的業(yè)務(wù)系統(tǒng)部署在阿里云上可觀測能力也已經(jīng)用齊了阿里云的產(chǎn)品矩陣——RUM 采集前端用戶體驗數(shù)據(jù)、Prometheus 托管容器與云資源指標(biāo)、ARMS 做應(yīng)用性能追蹤、SLS 承接日志并通過自建 Grafana 對接云上數(shù)據(jù)源做統(tǒng)一展示。但即便工具棧已經(jīng)相當(dāng)完備三個結(jié)構(gòu)性難題依然存在。一全局拓?fù)淇床磺鍛?yīng)用內(nèi)調(diào)用和應(yīng)用外依賴各是一張圖業(yè)務(wù)系統(tǒng)跑在云上但“這個應(yīng)用調(diào)了哪些接口、依賴了哪些云資源”這張全局拓?fù)涫冀K不夠清晰。應(yīng)用內(nèi)部的接口調(diào)用關(guān)系在 ARMS 里能看到一部分應(yīng)用對外依賴的 RDS、Redis、消息隊列等云資源又散落在各自的監(jiān)控里兩者拼不成一張完整的動態(tài)圖。業(yè)務(wù)規(guī)模一漲純?nèi)斯な崂硗負(fù)湓絹碓降托А裉炖砬宓囊蕾囮P(guān)系下周一次發(fā)布就變了。二多維觀測數(shù)據(jù)齊全但串不起來Metric、Log、Trace、Event 各類觀測數(shù)據(jù)都采到了問題在于“采得全”不等于“串得起”。一次故障排查往往要在指標(biāo)曲線、調(diào)用鏈、日志、變更事件之間反復(fù)橫跳、手動對時間戳缺少一條把多維數(shù)據(jù)自動關(guān)聯(lián)起來的主線。數(shù)據(jù)在線索卻要靠人拼。三告警噪音大跨域根因定位動輒數(shù)十分鐘業(yè)務(wù)故障發(fā)生時整條鏈路上的組件——從前端到后端、中間件、數(shù)據(jù)庫、容器——都在同時發(fā)告警真正的問題源頭被淹沒。定位根因高度依賴人工經(jīng)驗需要工程師憑直覺判斷“從哪一層切入排查”一次跨域故障的定位與分析時間動輒數(shù)十分鐘。在這些挑戰(zhàn)之上還疊加了一層精臣特有的判斷作為一支有能力自建 SRE 平臺的團隊團隊深知多維觀測數(shù)據(jù)的自動關(guān)聯(lián)、拓?fù)涞膭討B(tài)實時感知是一件投入巨大、且需要持續(xù)維護的重活——這塊輪子到底值不值得自己造解決方案多維數(shù)據(jù)底座UModel 數(shù)字孿生OpenAPI 嵌入自建 SRE 平臺在與阿里云進行技術(shù)交流后精臣發(fā)現(xiàn)阿里云可觀測體系已經(jīng)把“多維觀測數(shù)據(jù)自動關(guān)聯(lián)”和“全鏈路拓?fù)鋭討B(tài)感知”這兩塊能力做得相當(dāng)完整——關(guān)聯(lián)維度全、拓?fù)淠軇討B(tài)更新正是自己想做的部分。于是精臣做出決策不再重復(fù)造輪子把可觀測數(shù)據(jù)底座和運維數(shù)字孿生交給阿里云自建 SRE 平臺通過 OpenAPI 調(diào)用 STAROps 的診斷能力專注做貼合自身業(yè)務(wù)的編排與閉環(huán)。整套方案分四層落地。一多維觀測數(shù)據(jù)統(tǒng)一底座把已有的四套采集能力匯入一個數(shù)據(jù)面精臣已經(jīng)在用的 RUM、Prometheus、ARMS、SLS 不推倒重來而是基于阿里云云監(jiān)控 2.0CMS 2.0把指標(biāo)、日志、鏈路、事件、變更等多維度數(shù)據(jù)統(tǒng)一采集、統(tǒng)一存儲、統(tǒng)一查看、統(tǒng)一分析。前端用戶體驗數(shù)據(jù)RUM、容器與云資源指標(biāo)Prometheus、應(yīng)用性能與調(diào)用鏈ARMS、業(yè)務(wù)日志SLS匯聚到同一個數(shù)據(jù)面上為上層的拓?fù)浣：椭悄茉\斷提供一致的數(shù)據(jù)基礎(chǔ)——這一步解決的是“數(shù)據(jù)串不起來”的問題數(shù)據(jù)不再各自為政而是進入統(tǒng)一口徑的關(guān)聯(lián)底座。二UModel 運維數(shù)字孿生自動建模全鏈路拓?fù)鋭討B(tài)實時更新這是精臣從“自建”轉(zhuǎn)向“采用”的核心原因。UModel 自動為業(yè)務(wù)系統(tǒng)建模構(gòu)建應(yīng)用內(nèi)接口調(diào)用和應(yīng)用外云資源依賴的全鏈路拓?fù)潢P(guān)系圖——前端 → 后端 → 中間件 → 數(shù)據(jù)庫 → 容器一張圖完整呈現(xiàn)且支持動態(tài)實時更新應(yīng)用發(fā)布、依賴變化、擴縮容拓?fù)鋱D跟著自動刷新不需要人工維護。這意味著在這個應(yīng)用上點開拓?fù)鋱D的任一節(jié)點就能看到它關(guān)聯(lián)的觀測數(shù)據(jù)——拓?fù)洳辉偈且粡堨o態(tài)的架構(gòu)示意圖而是帶著實時數(shù)據(jù)的“活地圖”。UModel 在關(guān)聯(lián)維度的完整度和拓?fù)鋭討B(tài)感知上更成熟省去了團隊自己持續(xù)投入建模和維護的重活。三STAROps 智能診斷基于 UModel 拓?fù)渥詣涌缬蛘腋蛴辛私y(tǒng)一數(shù)據(jù)底座和 UModel 拓?fù)銼TAROps 就能在故障發(fā)生時自動做根因分析沿著 UModel 的上下游鏈路關(guān)系自動找尋相關(guān)節(jié)點、拉取對應(yīng)的觀測數(shù)據(jù)快速給出排查思路與分析結(jié)果把原來“工程師憑經(jīng)驗判斷從哪層切入 手動跨系統(tǒng)查數(shù)據(jù)”的過程轉(zhuǎn)變?yōu)?AI 自動跨域關(guān)聯(lián)分析。在實際故障排查過程中 STAROps 對基礎(chǔ)資源的單域分析如某個 Pod 的資源水位、某個云資源的指標(biāo)異常表現(xiàn)穩(wěn)定。對于需要跨觀測域關(guān)聯(lián)的復(fù)雜場景——例如“Pod 頻繁 GC”這類既涉及容器層、又需要下鉆到應(yīng)用層 JVM 指標(biāo)的根因分析——從應(yīng)用監(jiān)控切入時STAROps 能完整地沿鏈路關(guān)聯(lián)到 JVM 指標(biāo)并精準(zhǔn)定位根因。這類跨域自動關(guān)聯(lián)能力正是把“數(shù)據(jù)在、線索靠人拼”升級為“AI 自動貫通多維數(shù)據(jù)”的關(guān)鍵。四STAROps 無縫對接自建 SRE 平臺OpenAPI 把診斷能力嵌進客戶自己的平臺精臣不需要工程師離開自己熟悉的 SRE 平臺去另一個控制臺排查問題。STAROps 通過 OpenAPI 方式對接精臣自建 SRE 平臺作為診斷引擎被平臺直接調(diào)用把問題分析過程與診斷結(jié)果以流式方式返回。工程師在自己的 SRE 平臺內(nèi)點擊一鍵診斷就能實時看到 STAROps 的分析推理過程和最終結(jié)論全域問題診斷在客戶自有平臺內(nèi)閉環(huán)完成。這種“能力嵌入”而非“平臺替換”的集成方式讓精臣既拿到了阿里云可觀測體系的完整診斷能力又保留了自建 SRE 平臺承載自身業(yè)務(wù)邏輯的自主性。實現(xiàn)價值把重活交給云把精力還給業(yè)務(wù)一自建 SRE 平臺里一鍵閉環(huán)全域診斷過去一次跨域故障的排查要在 ARMS、Prometheus、SLS、Grafana 之間反復(fù)橫跳工程師手動對時間戳、拼線索定位根因動輒數(shù)十分鐘?，F(xiàn)在業(yè)務(wù)系統(tǒng)的問題在精臣自建 SRE 平臺里一鍵觸發(fā)診斷STAROps 沿 UModel 拓?fù)渥詣涌缬蜿P(guān)聯(lián)多維觀測數(shù)據(jù)并返回根因分析——運維團隊不再需要人工梳理多維數(shù)據(jù)、逐層尋找線索。二不重復(fù)造輪子成熟團隊把精力放回業(yè)務(wù)過去精臣作為一支有能力的技術(shù)團隊一度要自己投入人力去搭建和維護拓?fù)浣?、多維數(shù)據(jù)關(guān)聯(lián)這類通用運維基礎(chǔ)能力?，F(xiàn)在這塊“投入大、需持續(xù)維護”的重活交給了阿里云可觀測體系和 UModel——團隊從造輪子中抽身把精力重新投入到云資源管理、系統(tǒng)架構(gòu)優(yōu)化這些真正貼近自身業(yè)務(wù)價值的地方。對成熟團隊而言“什么該自己做、什么該交給云”這道選擇題精臣給出了自己的答案。三運維角色從“被動救火”重塑為“主動經(jīng)營”過去運維團隊的日常是等告警、追故障、事后復(fù)盤?，F(xiàn)在借助 UModel 全鏈路拓?fù)涞膭討B(tài)更新和多維觀測數(shù)據(jù)的 AI 化分析團隊得以從被動響應(yīng)轉(zhuǎn)向主動巡檢、提前發(fā)現(xiàn)問題。在保證業(yè)務(wù)系統(tǒng)穩(wěn)定的前提下運維的角色定位從“故障響應(yīng)者”升級為“系統(tǒng)健康的經(jīng)營者”——全面轉(zhuǎn)向 AI 智能運維體系。未來展望從“能診斷”到“更懂精臣的診斷”隨著 STAROps 嵌入自建 SRE 平臺更多核心業(yè)務(wù)系統(tǒng)將獲得全鏈路拓?fù)浣Ｅc智能診斷能力讓“活地圖 一鍵跨域診斷”覆蓋到全域業(yè)務(wù)。每接入一個新系統(tǒng)精臣自建 SRE 平臺的智能運維能力就隨之生長——業(yè)務(wù)版圖擴張到哪里智能運維的守護就延伸到哪里。一讓跨域根因關(guān)聯(lián)從“鏈路引導(dǎo)”走向“任意入口自動貫通”當(dāng)前 STAROps 沿 UModel 拓?fù)渥隹缬蜿P(guān)聯(lián)已經(jīng)能精準(zhǔn)定位根因。下一步的打磨方向是讓工程師無論從哪一層入口切入排查——無論是從應(yīng)用監(jiān)控視角還是從 Pod、容器等基礎(chǔ)資源視角——系統(tǒng)都能自動向上下游延伸、貫通全維度觀測數(shù)據(jù)把“跨域關(guān)聯(lián)”做得更無感、更智能讓根因定位不依賴切入角度的選擇。二讓 OpenAPI 嵌入式集成的交互體驗更流暢STAROps 通過 OpenAPI 把診斷過程流式返回到自建 SRE 平臺是這套集成方案的關(guān)鍵交互。圍繞精臣在實際使用中的體驗反饋雙方將持續(xù)優(yōu)化流式返回的實時性與信息完整度讓工程師在自己的平臺里看到的分析過程更細(xì)致、更連貫——把“能力嵌入”進一步打磨成“體驗無縫”。