很長一段時期內，銀行的網絡工程師重點關注一件事：網絡平臺的高可用性,即網絡節點、模塊、鏈路單點失效時的保護機制。與之配套的運維模式，是典型的勞動密集（人工巡檢、評估與變更）與經驗驅動（應急處置）。然而,伴隨金融科技的快速發展,網絡生態已發生了深刻的變化：應用線上化，服務7×24；流量規模與復雜程度同步快速增長；網絡增值服務推高網絡與應用的耦合度；技術變更頻度顯著加大。

由此帶來的直接影響，一是運維需要往下沉，重點由關注網絡連通性，擴展至關注網絡通信質量（諸如丟包、時延、資源占用等指標的細微變化）；二是運維需要提前做，由事中應急與事后補救,逐漸轉向預測性維護；三是運維需要換觀念，單純依靠人力提升運維能力的空間越來越窄。

當前的網絡運維模式很難適應上述工作要求的變化：人工操作效率嚴重滯后，本質上也不適合處理海量數據；支撐運維的數據不完整而碎片化，決策主要基于人工經驗。因此，網絡運維轉型勢在必行。

網絡運行數據，是支撐運維轉型的重要資源，也是新模式下替代粗放化的經驗主導，實現精細化決策的基礎。數據匱乏，是人工運維階段普遍存在的問題。傳統的網管平臺可以積累很多運行數據，但不便于使用：體系封閉，很難被直接運用于自動化與智能化運維；基于設備/接口之類的孤立視角，缺乏綜合處理與整合；來源主要是SNMP和SYSLOG，靈活性不足。

受限于性能，網管平臺通常并不掌握數據中心所有節點和鏈路的運行數據。而人工巡檢天然受限于人力效率，只能以點代面。更大的問題在于，許多傳統網管平臺對于異常事件的判斷，主要基于靜態告警閾值，以及異常日志，局限性非常明顯：告警閾值設置過高，低于設定閾值的突變不會被感知；告警閾值設置過低，產生大量虛警，淹沒有效告警；網絡通信質量問題通常不會在設備中產生異常日志；數據顆粒度不足以反映短促發生的網絡通信質量問題。

因此，有必要建立全新的運行數據采集機制，并實現多樣化的數據來源。至少應滿足以下要求：能夠模擬網絡工程師的人工檢查操作；無論網絡設備是否具備可編程接口，均能支持；至少能實現1分鐘級別的取數頻度；部分關鍵對象，粒度應能進一步縮??；實現對數據中心所有節點、鏈路的全覆蓋。

基于當前的實踐，在江蘇銀行數據中心一個中等規模網絡功能區，24小時內采集的運行數據，可以達到約1000萬條的規模，涉及交換機接口流量、丟包數增長、校驗錯誤增長、時延、ARP表項，防火墻會話數，以及F5中各資源池吞吐量、連接數、CPU占用率等指標。后續版本中，我們將持續拓展取數渠道，包括F5的HSL高速日志協議吐數，以及華為CE系列交換機的TELEMETRY主動推數機制，運行數據樣本集的質量將可以得到進一步提升。

業務大規模線上線后，服務客戶的時間與空間前所未有地擴展，應急處置的時效性要求同樣今非昔比。從實踐來看，相當一部分故障是有癥候的，例如：一組骨干鏈路中的某個光模塊出現異常，導致整個區域的進出流量出現一定比例的丟包。日間的小報文短連接交易對此并不敏感，用戶無反饋，監控也無告警。拖延到夜間，依賴網絡傳輸大文件的批量作業開始出現大量延誤。

又如：某應用投產新版本后，客戶端緩存機制出現異常，導致F5相關資源池的并發連接數開始大量增加，但當夜并不足以拖累系統性能，直至次日業務高峰時段，影響才徹底顯現。

諸如此類事件，從突變產生，到損害爆發，常常留有足夠長的時間可供實施預防性處置，關鍵是能否及時識別出突變。

嘗試獲得預測性維護能力時，往往會面臨缺乏故障樣本的麻煩：一年內數據中心網絡可供評估的真實故障數量通常是個位數，而網絡中可能會發生的故障場景卻又難以窮舉，很難讓系統藉此建立起自動預測故障的能力。所幸我們至少可以積累海量的健康樣本數據，一旦某些指標發生明顯偏離，一定是哪里出現了問題。

很多運行指標突變，數值未必很高，既不是當日峰值，也未觸發靜態閾值告警，往往不易察覺。解決這個問題，需要引入新的機制替代僵硬的靜態閾值：基于歷史數據生成動態基線，用于實時數據同比突變識別；當前采集的實時數據，與上一輪數據，進行環比突變識別。

在目前已投產的版本中，我們提供了工作日與非工作日兩組基線數據集，以更好地契合銀行業的典型通信場景。而環比識別則有助于感知網絡短促抖動。對于新應用上線帶來的某類指標的持續突變，也能很好地予以識別。

擁有足夠多的運行數據，以及有效的突變檢測手段后，就可以開始著手做很多事情。最具價值的場景如下。

1.自動化巡檢。人工巡檢工作量大，技術含量低，巡檢質量受人為因素制約嚴重，以點代面，并與工程師個人素養關聯，不確定性很大。盡管如此，人工巡檢仍然每天必須要做。

日常巡檢用到的很多數據并不需要登錄設備進行采集，在網管平臺中采集相關峰值數據即可用于評估。也就是說，網管平臺產生了數據，但不負責給結論。而網管平臺的告警都是針對孤立的事件與故障，信息零散，缺乏基于網絡整體視角的評估。

前面的內容也談過，網管平臺采集數據高度依賴網絡設備的MIB庫和SYSLOG，局限性很大，覆蓋面上也存在缺陷，導致人工登錄網絡設備采集實時數據的操作不能完全避免。

但是，耗時耗力的人工巡檢并不能解決所有問題。自動化巡檢則可以幫助我們實現以下目標：相對于概略式的人工巡檢，自動化巡檢基于自動采集的海量數據，對整張網絡進行更為完整的評估，依據突變級別與數量，自動生成24小時網絡運行健康度報告；對于所檢測到的突變，自動判斷是否存在相關資源消耗的危險增長趨勢，供網絡團隊判斷是否需要提前采取預防性措施。

2.故障定位輔助。網絡工程師不希望看到的場景之一：數據中心重要區域涌現來歷不明的異常流量。此時，工程師可以做的事情通常有：使用NPM類工具對鏡像報文進行分析溯源。這是一種比較有效的方法，但成本高昂，不易覆蓋全網，如果流量沒有波及被鏡像接口，則無能為力；登錄網絡交換機，排查異常流量來源。這種方式依賴工程師的經驗與心理素質，并且需要人工拼接獲取到的各類零散的信息，網絡路徑復雜時，效率很低。

如果自動化運維體系已經擁有了豐富的運行樣本數據和有效的突變檢測手段，那么我們可以獲得另一種低成本解決方案：基于全網視角獲取高吞吐量鏈路清單，結合突變數據進行甄別，獲取可疑接口相關聯的MAC/ARP/IP/APP信息，提供自動化的快速定位輔助。

另一類故障場景：兩個主機之間通信質量下降，其間可能有10跳路徑或者更多。同樣可以在自動化系統中模擬人工操作獲取通信路徑，標記其中發生了突變的環節，實現快速定位。

再比如，F5LTM的Self IP被非法占用。這類故障癥狀具備迷惑性，情急之下工程師會立即采取HA切換、重啟等常規應急操作但無濟于事。不過我們現在可以識別到關鍵ARP緩存的突變，只需要檢索受影響區域內的突變記錄，便足以提醒我們可能發生了什么事情，甚至可以通過自動化的MAC來源定位實施快速干預。

因此，從人工巡檢等勞動密集型工作中得以解放的網絡工程師，可以投入更多的精力去研發場景，這才是更有意義的事情。

3.回溯與預測。網絡工程師經常會接到應用團隊的求助：“幫我們看看10分鐘前網絡有沒有抖動過？”很遺憾，如果沒有被NPM覆蓋，我們可能提供不了多少有價值的線索，以證實是否發生過通信質量問題。

但現在數據都是現成的。相對于回溯，預測可能更為重要，也更具難度。

其中，預測資源瓶頸具備重大意義，因而我們也將其納入自動化巡檢，成為其中的一個子場景。人工運維模式下的工程師，不可能在成千上萬的性能曲線中注意某個并未成為峰值的指標突變，并結合同比數據，預測其增長到危險臨界點的剩余時間。但是自動化系統天然地適合處理這樣的任務，從而為帶寬提速、設備更新爭取到足夠的處置時間。這也是我們“將工作提前做”的核心訴求之一。

而預測故障更具挑戰性。前文提到過，由于缺乏足夠多的真實網絡故障樣本，很難簡單地讓系統將某類運行指標的突變，直接與某種故障進行關聯，需要模擬工程師的判斷邏輯進行自動化評估。這方面還有許多工作需要開展。

江蘇銀行正在推進的網絡運維轉型，讓工程師們獲得全新的技術手段以改進運維質量。更重要的意義在于，今后可以圍繞運維中不斷涌現的挑戰與收獲，持續擴展運維體系的自動化與智能化特性，實現數據驅動的精細化運維新模式。