平均自證清白時間：如何證明問題不在 WiFi

以英式英語、自信、權威且口語化的口吻說話 - 就像一位資深網路顧問一邊喝咖啡一邊向客戶簡報。語速沉穩、吐字清晰、偶爾帶點冷幽默。不是在上課，也不是推銷。只是來自一個看過這問題上百次的人的直言不諱： 歡迎來到 Purple 的技術簡報。我今天想和各位談談，每位網路經理都心知肚明、即使他們從未聽過這個正式術語的事情。那就是：平均洗清嫌疑時間（Mean time to innocence），簡稱 MTTI。[短暫停頓] 也就是你花在證明「這不是你的錯」的時間。 場景是這樣的。早上九點，租賃公寓大樓的住戶開始打電話給前台，說 WiFi 壞了。物業經理打給託管 WiFi 供應商。託管 WiFi 供應商打給網路服務供應商（ISP）。ISP 說檢查路由器。路由器團隊說檢查基地台。基地台廠商說檢查用戶端設備。就在這一切扯皮的中間，四十五分鐘過去了，卻沒有人真正解決任何問題。這，就是平均洗清嫌疑時間在發揮作用。[短暫停頓] 而且它讓你付出的代價比想像中還要高。 讓我給它下個妥當的定義。平均洗清嫌疑時間是指從偵測到問題開始，到任何特定團隊能夠拿出證據，證明自己的領域並非根本原因之間的平均流逝時間。這與平均識別時間（Mean time to identify）不同，後者是整個組織尋找實際根本原因的指標。MTTI 是條塊分割的，是針對個人的。這是網路團隊在說：數據在這裡，不是我們的問題，現在去看看別的地方。問題是，如果沒有合適的工具，這種證明是需要時間的。而 MTTI 的每一分鐘，都會直接增加到你的平均修復時間（MTTR）中。兩者密不可分。 那為什麼 WiFi 總是第一個被指責？[短暫停頓] 三個原因。第一，WiFi 是看得見的。當有東西壞掉時，人們會看著他們能看到的東西，而手機上的 WiFi 訊號格就是最顯眼的連線指標。第二，WiFi 是設備之前的最後一哩路，因此當設備無法連上網際網路時，它最先看起來令人起疑。第三，也是最令人無奈的一點，WiFi 團隊往往無法快速證明清白，因為他們缺乏合適的遙測數據。如果你無法在兩分鐘內出示無線層運作良好的健康證明，你接下來的一小時就只能忙著為自己辯解了。 現在，在單租戶企業環境中，這很令人惱火。而在多租戶環境中，這確實會造成損害。想想看像 Premier Inn 這樣的飯店、或是一棟租賃型公寓大樓、又或是連續舉辦活動的會議中心。您有一位不擁有網路的物業經理，有一群不了解網路的住戶或賓客，還有一家負責無線網路層但不負責 ISP 線路、不負責大樓內佈線、也不負責用戶端裝置的託管 WiFi 供應商。當某個環節損壞時，物業經理會歸咎於 WiFi 供應商，因為那是他們能指出的合約對象。住戶會歸咎於大樓，因為那是他們付租金的對象。而 WiFi 供應商必須快速排除網路責任，否則雙方關係就會惡化。[短暫停頓] 在這種情況下，MTTI 不僅僅是一個技術指標，更是一個商業指標。 因此，讓我們來談談實際縮短 MTTI 的方法。這包含五個層級，而您這五個層級都需要。 第一層：持續的模擬合成檢查。在提出任何工單之前，您應該讓網路本身運行自動化探測，測試 DNS 解析、HTTP 可達性、到已知端點的延遲以及驗證流程。像 Juniper Mist 的 Marvis 或是整合到 ThousandEyes 等平台中的模擬合成測試工具，每隔幾分鐘就會執行一次這些檢查。當事件發生時，您可以拉出圖表並準確顯示 WiFi 層上一次進行乾淨模擬合成檢查的時間，以及在投訴發生時該檢查是乾淨的還是已降級。單憑這一點就能大幅縮短 MTTI，因為您要麼確認 WiFi 是健康的，要麼確認它不健康，從而停止對此爭論不休。 第二層：逐跳路徑可見性。這是大多數團隊失敗的地方。您可以證明存取點是健康的，也可以證明交換器是健康的。但您能證明從交換器到 ISP 介接點的路徑是健康的嗎？在多租戶大樓中，通常會有您不擁有的跳數。大樓內的分配網路、房東的核心交換器、與 ISP 的分界點。您需要跨越這些邊界的路徑追蹤數據。不只是對 8.8.8.8 進行 ping。而是實際的 traceroute 式可見性，顯示每一個跳數、其延遲以及是否正在丟包。當您可以顯示第一到第四跳是乾淨的，而第五跳（即 ISP 的邊緣路由器）顯示百分之四十的丟包率時，對話立馬就會改變。 第三層：依需求進行封包擷取的流量數據。NetFlow 和 IPFIX 讓您能以對話級別檢視網路上的通訊狀況。當住戶表示串流服務無法使用時，流量數據會告訴您前往該服務 IP 範圍的流量是否根本沒有離開網路。如果流量正常離開網路，而問題出在下游，這就是您的證據。如果流量完全沒有離開網路，您就知道該去哪裡尋找問題。依需求進行的封包擷取功能（在 Cisco Meraki 和 HPE Aruba 等平台上提供）讓您無需接觸硬體，即可針對特定用戶端或 VLAN 進行定向擷取。這就是您的鑑識層。您很少會用到它，但當您需要時，它就是決定性的關鍵。 第四層：拓撲與相依性對應。在多租戶環境中，您需要一張即時地圖，顯示哪些存取點為哪些租戶提供服務、這些 AP 連接到哪些交換器、這些交換器使用哪些上行鏈路，以及每個上行鏈路由哪個 ISP 線路提供服務。當事件發生時，您可以立即確認受影響範圍。這是影響單一租戶還是所有租戶？一個樓層還是整棟大樓？一個 VLAN 還是所有 VLAN？這個範圍評估問題，透過拓撲地圖在 30 秒內就能得到解答，告訴您問題是出在 WiFi 層、大樓網路還是 WAN。它還能告訴您應該將誰納入協調範圍，以及可以立即排除誰。 第五層：事件關聯。這是將所有內容聯繫在一起的關鍵。變更日誌、ISP 維護警報、裝置韌體更新、電源事件和使用者投訴，全都必須放在同一個時間軸上。當您將用戶端關聯失敗的激增，與 12 分鐘前進行的韌體推送進行比對時，您就找到了根本原因。當您將延遲激增與未通知您的 ISP 維護期進行比對時，您就有了呈報問題的證據。事件關聯並不耀眼，但它卻是「經歷 45 分鐘推卸責任的爭吵」與「4 分鐘內證明清白」之間的差別。 現在，談談文化層面的問題，因為這正是許多團隊出錯的地方。降低 MTTI 的目標不是為了更快贏得推卸責任的爭論，而是為了徹底結束這種爭吵。 [短暫停頓] 共同的證據改變了這種互動關係。當 WiFi 供應商可以傳送一個儀表板連結給物業經理，顯示無線層為綠燈、大樓內交換器為黃燈、ISP 線路為紅燈時，對話就不再具有敵意，而是轉為協同合作。物業經理會聯絡 ISP，ISP 修復線路，住戶恢復連線，而 WiFi 供應商的合約得以續約，因為他們是發現問題的人。 這就是投資觀測工具的商業理由。這不僅能加快疑難排解的速度，還能與向您付費的人建立更好的關係。 讓我快速舉幾個場景，讓這個概念更加具體。 情境一：一家擁有 350 間客房的飯店。入住類似 Premier Inn 風格飯店的賓客開始反映客房內的 WiFi 速度很慢。櫃台向託管 WiFi 供應商提報工單。透過執行綜合檢測，供應商可以發現 DNS 解析時間在早上 7 點 43 分從 12 毫秒飆升至 400 毫秒。WiFi 層運作良好。路徑追蹤顯示延遲發生在第三跳（Hop），即網際網路服務供應商（ISP）的聚合路由器。供應商向飯店經理傳送了路徑追蹤的螢幕截圖，並用紅色標示出效能降低的跃點，同時附上顯示 WiFi 層全程運作正常的綜合檢測圖表。隨後聯絡了 ISP。ISP 確認其端存在路由問題。從接到投訴到排除 WiFi 層責任的總時間：6 分鐘。整個事件的平均修復時間（MTTR）：22 分鐘，因為 ISP 的修復花費了 16 分鐘。如果沒有觀測性工具，那 6 分鐘的責任排除將會是 40 分鐘的來回溝通，而 MTTR 將會超過一個小時。 情境二：零售連鎖店。一家在全國擁有 200 家門市並提供 WiFi 的零售商發現，某一地區的 POS 終端機與付款處理商的連線斷斷續續。網路團隊立刻成為被歸咎的對象。流量數據顯示，前往付款處理商 IP 範圍的流量正常地離開了門市網路。問題並不在於網路。在付款處理商 VLAN 上的封包擷取顯示 TCP 重傳次數飆升，這指向了付款處理商端伺服器的問題。網路團隊與付款處理商的支援團隊分享了流量數據和擷取摘要。付款處理商確認其端負載平衡器設定錯誤。網路團隊的平均辨識時間（MTTI）：8 分鐘。付款處理商的修復時間：35 分鐘。如果沒有流量數據，網路團隊將會花費那 35 分鐘重新設定 VLAN 並重新啟動運作完全正常的交換器。 好。讓我快速回答關於這個主題我常被問到的關鍵問題。 是 WiFi 的問題還是裝置的問題？從 AP 本身執行綜合檢測。如果 AP 可以正常連線至網際網路而裝置不行，那就是裝置的問題。如果 AP 無法連線至網際網路，那就是裝置上游的問題。 是 WiFi 的問題還是 ISP 的問題？進行至網際網路的路徑追蹤。如果延遲或丟包發生在您網路邊界之外的跃點，那就是 ISP 的問題。 MTTI（Mean Time to Innocence）與 mean time to identify 有何不同？MTTI 是您的團隊證明清白的時間。Mean time to identify 是組織尋找真正元凶的時間。MTTI 是 mean time to identify 的子集。 如何在不購買新工具的情況下縮短 MTTI？從您現有的資源開始。大多數企業級存取點平台，包括 Cisco Meraki、HPE Aruba 和 Juniper Mist，都內建了模擬測試與用戶端診斷功能。請善用這些功能。記錄您的拓撲結構。建立一個物業經理或營運團隊可以查看的共享儀表板。透明度是降低 MTTI 最經濟實惠的工具。 總結來說，平均澄清時間（Mean time to innocence）是每次網路事件中的隱形成本。在多租戶環境中，由於權責分散在供應商、房東和網路服務供應商（ISP）之間，這個指標決定了您是能留住合約還是失去合約。降低該指標的方法並不複雜：模擬檢測、路徑可視性、流量數據、拓撲對照和事件關聯。我們的目標不是要在責任歸屬的爭論中勝出，而是要用共同的證據來取代互相指責，好讓每個團隊都能專注於解決問題，而不是忙著為自己辯護。 [短暫停頓] 因為每花一分鐘來證明清白，您的住戶、訪客或顧客沒有網路連線的時間就會多增加一分鐘。而這才是真正關鍵的數據。 感謝您的收聽。如果您想了解 Purple 的多租戶 WiFi 平台如何跨 80,000 個現場場域呈現這類型的觀測數據，請前往 purple.ai。