【設備分析 ①】定期巡檢的極限：一台設備的完整狀態，人為什麼看不完、也看不懂？

前面五天(D14–18),我們把一個 AI 應用的骨架一塊一塊拼了出來:會呼叫工具(tool call)、把工具標準化(MCP)、有記憶、會把任務拆開分派。從今天起,這些手法要合體成一套真的在公司裡跑的系統——三系統實錄的第一套:設備運作分析系統。

主題是一件聽起來理所當然、做起來卻不可能的事:把一台設備「現在到底好不好」看清楚。
你以為那是打開設備、看一眼的事?真要看，它會吐給你一份幾萬行、幾十個指令的設備狀態檔(工程師常說的 dump,也就是 show tech-support 的完整輸出)。人要從這一大片裡看出問題，撞的是兩道牆:一是讀不完——量大到你只能挑幾個「重點指令」掃一掃、剩下認了;二是看不懂——就算那行數字擺在眼前，少了跨領域的腦袋，你也認不出它是異常。這不是誰不夠認真，是這份資料的規模 × 需要的判讀，本來就超過人逐行讀完、又看得懂的範圍。
這篇先讓你看清這兩道牆; 怎麼用實際應用把它翻過去，是 D20 的事(設備分析②實作篇)。

這張設備畫面，你看得出哪裡出問題了嗎？

首先我先帶到一個 Cisco 設備的實際情景的截圖範例，我特地截有問題的地方。 你有看出什麼嗎?

給你看看AI抓到什麼:

先解釋一下名詞 Port-Channel: 用非常廣義的說法是鏈路聚合，他可以把兩個物理分隔的port，結合到一起使用，讓邏輯線路的吞吐量提升。

這裡發生了什麼?

首先這個現象有一個專有名詞叫做 Port-Channel 偏諧，我相信多數工程師一輩子不會聽到這個名詞。 (你用中文搜尋是沒有資料的喔)

因為這東西不僅沒辦法透過很制式的知識傳遞教學，而且它只出現在Cisco 原廠的技術文件裡，根據我跟原廠Tech Support互動的經驗來看，我相信這個東西冷門到他們也不知道。

具體的描述是: 原本應該均分的流量線路，現在集中到同一邊的接口 (畫面上是 interface G/0/48)。
造成這個現象的原因有幾種，包括演算法Hash、mac address相似性、或是同一網段 (因為它下面確實都是同一批進去的設備)

這個現象會有什麼問題?

這個問題從原理上來講確實是很嚴重的問題，因為它發作的時候你是察覺不到的(這個現象不會吐Log出來)，當真的要出事的時候整個下游的設備運作都會失效。 (確切的術語說法是運作效益會打折，但是你抓不出來)

只有在下游使用者發覺流量怎麼上不去，想要往上游去抓問題的時候才有可能看到。 但這種願意跨責任追問題的場景在日常企業環境常發生嗎? (備註: 我預設這點不會發生為大前提。)

實際的影響是什麼?

從這個報告來看，它有幾個教科書式的現象確實出現了，包括:

• TCP retransmit
• UDP packet loss
• Voice 抖動
• Video freeze

在這當中的幾個描述在現實的場景確實都有出現，CLI上的流量統計也看得到。 (但通常的情況是你的眼睛看到了，你人卻沒有看到)。

所以這裡真正的牆是:看得見，不等於看得懂——就算那些數字、那張圖此刻清清楚楚擺在你眼前，少了那段跨領域的知識，你也認不出它是異常。而要「看得懂」，靠的是一顆橫跨多領域的腦袋。這就帶出一道容易被跳過的牆。

為什麼『看得見』不等於『看得懂』?

剛剛那個 Port-Channel 偏諧，能一眼認出它是異常、還知道要調 AI 去盯它——這件事本身就是一道牆。要製作這套系統、要懂得調整並指定讓 AI 產生有意義的分析指標，有幾個大前提沒辦法忽視:

1. 你得是一個具有規模架構思維的資深網路工程師，而且斜槓到產品運營的領域去(也就是 DevOps，知道哪些指標才有意義)。
2. 你得了解企業等級的 IT 設備、也擁有用程式設計去操作這些設備的技能(要在程式設計與 IT 設備工程兩個領域有 Overlap)。
3. 你得有調整 AI 的 sense——也就是這系列一直在講的 AI 設計認知與規模應用調整(能抽象且有意識地分辨:同一份資料在什麼情境下有意義、什麼情境下沒用)。

你可以拿掉其中任一項，看整套系統的前提論述還成不成立——缺一項，它就接不住。這道『能力稀缺』的牆有個特別之處:它不是「再拼一點、多熬幾夜」就補得滿的——而是連「認得出問題」的人本來就稀少。

所以「看不懂正才是要處理的重點(知識頻譜牆)」，不是每個人都應該要懂所有事情，所以要有一個機制去接這個漏洞，而這份系統就是為了補足這件事情。

一份設備狀態檔到底有多大？為什麼人讀不完？

回到最前面那道牆:規模。你可能以為設備狀態就是幾個燈號、幾個數字;實際上，一台設備吐出來的完整狀態(就是 D20 要處理的那種 show tech-support)，動輒幾萬行、幾十個指令區段——版本、設定、每個介面的計數器、生成樹、CPU/記憶體、環境、日誌……全擠在裡面。

更麻煩的是:真正的異常(像剛剛那個 Port-Channel 偏諧)往往不在某一行，而是藏在跨指令的交叉裡——你得同時讀懂介面計數器和聚合埠的成員組成，才看得出「流量該均分卻沒均分」。一份幾萬行的東西，人的現實是:挑幾個重點指令掃一掃，剩下的認了。不是不夠認真，是這份資料的規模,本來就超過人逐行讀完的範圍。

而這還只是一台。你手上是一整批設備，每一台真要細看都是這樣一份設備狀態檔——每台都讀不完，那就等於全都沒真的讀過。

所以，這種「一份就幾萬行、人讀不完」的活，本來就該交給不會累的那一方？

把前面幾道牆疊起來，你就看清了:一份設備狀態幾萬行、人讀不完(規模);就算讀到了，少了跨領域的腦袋也看不懂(知識頻譜)——而且能看懂的人本來就稀缺(門檻牆)。 這幾件事沒有一件是「認真一點」就補得上的。

那答案是「請個更厲害的人、盯得更緊」嗎?不是。你要的其實不是「一直盯著看」——真要每秒不停跟設備要狀態，反而像在打它、也沒必要 - -lll;你要的是:在你需要知道的那一刻，幾分鐘內就把一台設備的完整狀態讀完、而且看得懂。 而這件事人補不起來:一份設備狀態檔幾萬行(量)，還要每次都認出 Port-Channel 偏諧這種不吐 Log 的異常(懂)——一位專家再厲害，也沒辦法親自把每一台、每一份設備狀態檔都這樣讀一遍。

所以把這件事交給不睡覺、不麻痺、幾分鐘就能把整份讀完的那一方，不是取代巡檢的人、也不是取代那位專家——是去接手他們到不了的規模。設備分析系統站的就是這個位置:它不是站在那 24 小時盯哨，而是你一把設備狀態交給它，它幾分鐘內把整份讀完、把異常標出來。而它之所以認得出 Port-Channel 偏諧，不是因為它比你懂——是你把「看得懂」的判準寫給了它; 它做的，是把你這份判斷，覆蓋到一個人讀不完的量上。

至於這件事交出去、那些精力空出來會落到哪裡——這篇先不替你寫答案，D21 我用「真的被誰用、換來了什麼」來說。

講一下系統定位

• 讀不完:撞的是規模，不是態度: 一份設備狀態檔動輒幾萬行，人只能挑重點掃、剩下認了——不是不夠認真。
• 異常藏在「交叉」裡: 像 Port-Channel 偏諧，不在某一行，而在跨指令的交叉——得同時讀懂兩三個指令才認得出，這正是最花時間、最容易漏的地方。
• 看得見 ≠ 看得懂: CLI 上數字明明都在，少了跨領域的知識，你就是認不出那是異常(知識頻譜牆)。
• 認得出問題的人本來就稀缺(門檻牆): 這道牆不是熬夜補得滿的——要一顆橫跨網路工程、DevOps、設備程式、調 AI sense 的腦袋，本來就少。
• 系列主張 —— 交出去的是「規模」，不是判斷: 機器讀完一個人讀不完的量; 認出異常的判準，仍出自那位專家。人空出來後，要做什麼判斷，留白給人自己。

「一台設備到底好不好」——聽起來像打開來看一眼就好，實際上是一份幾萬行、還得跨領域判讀的東西。人面對它的極限很具體:讀不完(規模),而且看不懂(要一顆橫跨多領域的腦袋才認得出異常)。這不是誰不夠認真，是這兩道牆本來就擋在那裡。

但人做不到，不代表沒辦法。明天 D20，我把這套隨選深度分析實際做給你看:你丟一份設備狀態檔進去，它在幾分鐘內做完人做不到的事——把整份幾萬行讀完、認出 Port-Channel 偏諧這種不吐 Log 的異常，產出一份掃一眼就懂的報告。