最常見網路和使用者體驗問題的根本原因分析

當資料速率增加到100G時，故障診斷網路問題變得越來越關鍵。為了成功識別和補救影響服務的問題，並降低MTTR(平均解決時間)，ITOps需要實時監控各種指標和資料來源，包括資料包資料。

網路基礎設施故障排除是一個多層次的過程--從模糊的 "有問題 "到具體問題的根本原因分析。這個過程越規範，對網路行為和影響終端使用者的問題之間的相關性理解得越透徹，問題就能越快地得到解決或交給適當的團隊進行補救。

這個過程中常年面臨的挑戰是，使用者投訴通常是模糊的。使用者(無論是員工、客戶，甚至是對網路條件敏感的演算法)通常會遇到三種情況："我無法連線"、"網路太慢 "或 "我的語音/視訊通話質量不好"。由於每一種情況都可能是由多個潛在問題引起的，因此IT團隊往往難以縮小事情的範圍。例如，網路速度慢可能是由網路、應用程式或協議延遲引起的，其中每一個都可能透過任何一個不同的指標顯示出來。但對於沮喪的終端使用者來說，這一切看起來都是一樣的--而且很多東西可能會在轉換中丟失。

為了找到根本原因並加快問題的解決，IT團隊不僅需要正確的工具來評估網路指標，還需要清楚地瞭解使用者體驗、可測量的網路行為和潛在網路問題之間的相關性。為了說明這一點，讓我們來看看故障排除的過程。

第一步：收集相關指標

各組織依靠許多來源和型別的網路資料來為終端使用者的投訴提供背景。他們的基本需求是建立網路監控基礎設施，以便IT能夠訪問資料包資料、流量資料、事件和遙測資料以及伺服器KPI。這將為他們提供所需的洞察力，以確定各種場景的根本原因。有一些特定的指標與具體問題相關。對於 "網路很慢"，相關指標將是單向延遲、往返時間、Z-Win、DNS或HTTP延遲、吞吐量(Gbps)、每秒資料包(PPS)、每秒連線數(CPS)或併發連線數(CC)。對於 "質量差"，要看抖動、序列錯誤、重傳和碎片。當 "連線性 "是問題時，檢查ICMP、HTTP和SYN/ACK錯誤。

第二步：縮小問題範圍

一旦IT團隊獲得了所需的資料，他們就可以開始關聯各種網路行為，以排除可能的原因，並將實際問題歸為零。這根據他們所要解決的投訴而有所不同。

網路速度慢--這很可能是由網路過載引起的，但也有可能是伺服器太忙或DNS伺服器沒有響應。正如討論過的，相關的指標是單向延遲(網路問題)、往返時間或Z-Win(應用問題)，以及DNS或HTTP延遲(協議問題)。如果網路延遲很高，那麼要麼是網路上的整體流量太大，要麼是 "爆棚"。觀察整體效能和吞吐量(Gbps)、每秒資料包(PPS)、每秒連線數(CPS)或併發連線數(CC)應該有助於確定是哪一種。如果應用或協議延遲是原因，那麼可以將問題傳遞給相應的團隊來解決。觀察資料包和流量資料對於排除緩慢網路的故障尤為重要。流量資料可以識別每秒的頂級通話者或資料包，但它無法判斷網路的突發程度或每秒的連線數--這需要資料包資料。

質量差--IT應該監控抖動、序列錯誤、重傳和碎片，以診斷這些投訴。高比率的抖動和序列錯誤表明問題出在網路流上，而重傳和碎片則表明問題出在資料包丟失上。這些問題可能是由路由問題或MTU(最大傳輸單元)碎片配置錯誤引起的。

連線性 - 這種投訴可能是由認證、授權或裝置的訪問控制列表中的錯誤問題引起的。要弄清楚是哪一種，IT團隊應該首先檢視相關裝置的協議錯誤。接下來，他們應該檢查連線錯誤，比如檢視資料包資料是否有SYN/SYN ACK錯誤，以確保客戶端和伺服器之間的TCP/IP三方握手是完整的。

第三步：找出根本原因

至此，IT部門應該已經找到了問題的根本原因，可以著手進行補救。問題經常是網路配置錯誤，但其他的可能性包括網路裝置故障、應用程式錯誤或bug、DDoS攻擊或某些其他安全事件。但是，如果不能訪問廣泛的網路指標和資料包資料，IT人員將不得不猜測到底是哪個問題在起作用。