幾個主要的通信服務提供商（CSP）正在朝著支持網絡功能虛擬化（NFV）架構發(fā)展，這有助于降低成本并為他們的用戶提供靈活、按需的服務，包括所謂“anything-as-a-service”。但NFV正在面臨一系列服務保證相關的問題，這些問題亟待解決。
NFV支持的環(huán)境正在改變我們對網絡管理應用程序的思考方式，“解決一切”的專有大型解決方案的時代一去不復返了。在不斷變化的環(huán)境中，我們可以看到運營商正在部署不同的松耦合混合軟件組件：一些是內部開發(fā)的，一些是商業(yè)化的，一些是開源的。最關鍵的是，他們都需要能夠通過業(yè)界定義的開放API進行通信并實時交換信息，以更靈活的方式支持網絡管理和服務保證功能。
這促使運營支持系統(tǒng)（OSS）/業(yè)務支持系統(tǒng)（BSS）行業(yè)的創(chuàng)新者對傳統(tǒng)的方式進行反思，并提出一套全新的工具和方法來解決新的服務保障的挑戰(zhàn)。例如，一些傳統(tǒng)的故障管理用例包括通過高級報警過濾、二級報警抑制和根本原因分析來減少平均修復時間（MTTR）并提高網絡操作中心（NOC）效率。
很多傳統(tǒng)方法都能解決這個問題，如專家系統(tǒng)（expert-system）、規(guī)則驅動的原因分析（RCA）甚至是更高級的基于拓撲的方法，在NFV的環(huán)境中都不能完全解決這個問題。專家系統(tǒng)（expert-system）不能通過基于規(guī)則的引擎準確地預測和防止網絡行為并在遇到問題時報警。基于拓撲的方式也具備有限性和不可靠的后果，因為啟用NFV的網絡將具備高度的動態(tài)性。同樣需要注意的是，應用于故障管理的分析，要提供高水平的分析結果，僅僅是簡單地指向可能存在的原因是不夠的，甚至可能會造成無法估量的損失。由于NOC在保持網絡正常運行方面的關鍵和實時性，最好是采用手動分析故障原因，而不是試圖解決由RCA引擎提供的錯誤故障原因。但顯然，這也不是企業(yè)所需的。為了實現(xiàn)NFV真正的優(yōu)勢，我們在朝著更大的自動化方向發(fā)展，在可靠性方面的要求將會提升。
可以肯定的是，所有這些挑戰(zhàn)都需要新的方法。投資于當今混合NFV環(huán)境進行優(yōu)化的新一代分析功能，將有助于CSP更好的實現(xiàn)其NFV的價值。這種進步的一個例子是利用自然語言處理算法來消除報警數據中的數據標準化和clean-up的需求，并且使用機器學習技術來支持RCA，而不再需要利用網絡拓撲等方式來增加報警數據信息等。因為數據通常很不容易獲得，使之成為成功分析的障礙。我們近期在這個領域頗有進展，通過使用報警歷史數據，我們能夠更準確地確定報警的根本原因，然后將這些結果實時反饋到故障管理系統(tǒng)，以更快、更準確地解決網絡故障。
另一個獨特的需求是管理和確認混合“pre-NFV”和NFV環(huán)境中物理和邏輯組件的性能，將網絡向軟件定義網絡（SDN）和網絡功能虛擬化（NFV）的遷移是漸進性的，并且需要時間來實現(xiàn)，很多網絡組件不會發(fā)生改變。很有可能這種混合網絡將會成為未來幾年的標準，運營商需要更多的臨時補丁來管理并確保其underlay網絡組件（物理、虛擬、抽象）的性能。因此，服務保證解決方案需要能夠跨域網絡感知，結合傳統(tǒng)的數據模型如TM Forum的共享信息/數據模型（SID），以實現(xiàn)端到端服務性能視圖如OASIS的云應用程序拓撲和編排規(guī)范（TOSCA）。
以上只是新技術的轉變如何推動當今服務保障解決方案創(chuàng)新的一些實際案例，目的是為網絡管理和運營方面提供更好地支持，并順利地向NFVi過渡。我們看到很多行業(yè)的領導者將之視為優(yōu)先實現(xiàn)的工作，并利用它重新思考其OSS環(huán)境，但也有一些運營商比較謹慎，因為他們的OSS環(huán)境非常復雜。隨著運營商對其服務保障策略的重新評估，無論他們采用何種方式，無論他們部署本地系統(tǒng)、開源解決方案還是商業(yè)化的產品，他們應該關注三個關鍵的業(yè)務點：自動化、分析和API。如果沒有這三者，基本上不可能監(jiān)視和確保當今的混合網絡的性能。
原文鏈接：https://www.sdxcentral.com/articles/contributed/automation-analytics-and-apis-nfv-driving-service-assurance-innovation/2016/12/
京公網安備 11010502049343號