NFV上半場一路坎坷，走得不容易;筆者通過這幾年在NFV底層摸石頭過河的點點滴滴經驗積累，思索和分析了下半場中決定電信云能否穩步爬升和真正落地開花的關鍵點，與大家一起探討。文章結構分為以下幾點：

• 曾經的承諾，現在還好嗎?
• 困難凸顯，蹣跚前行
• 下半場的命門
• 已經在路上

[[250152]]

一、曾經的承諾，現在還好嗎?

NFV，即網絡功能虛擬化，Network Function Virtualization。通過使用x86等通用性硬件以及虛擬化技術，來承載很多功能的軟件處理，從而降低網絡昂貴的設備成本?？梢酝ㄟ^軟硬件解耦及功能抽象，使網絡設備功能不再依賴于專用硬件，資源可以充分靈活共享，實現新業務的快速開發和部署，并基于實際業務需求進行自動部署、彈性伸縮、故障隔離和自愈等。

概念是誘人的，但那些曾經許下的美好諾言，時過境遷，現在還好嗎?讓我們來一一看看。

1. NFV的引入可以降低CAPEX和OPEX

當前運營商的試驗試點驗證了整體方案的可行性，以及系統中單組件的特性滿足需求，但一個現實情況是，各廠商實現的水平還層次不齊，如果到了現網系統的復雜環境下，是否能真正做到敏捷和靈活，還有待實踐檢驗。

2. NFVI平臺靈活擴展，VNF服務快速上線、彈性擴縮容

當前試驗試點驗證了整體方案的可行性，以及系統中單組件的特性，但各廠商實現的水平還層次不齊，如果到了現網系統復雜的環境下，是否能真正做到這種敏捷和靈活，還有待實踐檢驗。

3. 云平臺可以靈活地調度和統籌資源，為上層業務提供更好地資源服務

當前的NFV，實際上剛剛度過軟硬解耦階段，云資源池還處于滿足上層業務部署需求的階段，還沒有像公有云一樣，進入到與業務深度結合，提供更好的資源服務，對整體云平臺進行高效的資源管理的階段。

4. 防止廠商鎖定(vendor lock-in)

通過云計算的技術手段，將多廠商的產品以軟件化的形式運行在統一的平臺，隨時可以替換，打破單一供應商的鎖定，這是我們美好的愿景，但廠商出于各種目的會盡量避免自家的VNF與第三方VNF集成的方案出現。廠商可能會說，兼容性不好，集成起來非常麻煩，甚至說與第三方的連接性能不如全采用自己一家。正因為此，這些年運營商花費大量時間和精力，反復進行異廠商對接測試，成熟完善企業接口規范，但即使如此，我們依然無法避免后期的集成綁定，當集成商以交鑰匙的方式把系統交給我們的時候，一種集成的綁定已經悄然形成。

曾經的海市蜃樓逐漸淡去，骨感的現實襲來，難怪圈內發出了NFV倒地的擔憂，這并非杞人憂天，以上的事實是殘酷的。但任何技術都有它的成熟曲線，筆者在NFV底層跌跌撞撞摸爬滾打三年多，歷經概念興起后的產業界追捧，然后是雷聲大雨點小，彼此觀望，然后是實際落地實踐中磕磕絆絆的前行，直至不久前的溫吞和低迷，但是從新技術成熟度曲線來看，這恰恰是后期穩步爬升的積累。

當然這個成熟度曲線只是規律上的分析，具體到NFV的技術發展路線，還是需要從這兩年NFV步履維艱的前行中去思索和分析，才能找到后續能穩步爬升的關鍵點所在。

二、困難凸顯，蹣跚前行

這兩三年運營商推進NFV真心不容易，圍墻之外的看客老是抱怨NFV推進太慢，要錯過發展窗口期了，說真心話，通信網絡服務等級高，是事關國計民生的生產系統，豈敢兒戲，所以運營商反復驗證方案，去催化產業的成熟。然而即使我們如此努力，依然凸顯出如下困難。

1. 通過規范標準來約束的廠商的互操作性，推進比較緩慢

(1)NFV系統復雜，行業標準化推進緩慢

事實上從發展之初，標準化一直在積極推進， 國際上已有多個有影響力的標準組織成立了專門的工作組來開展NFV的相關研究，比如ETSI、IETF、3GPP SAS、ITU-T SG13、CCSA等;另外，在上述的標準基礎上，也引入了一批NFV相關開源組織，如OPNFV、OpenStack、KVM、Open vSwitch、ONOS、OpenDaylight等，為NFV的開源實現技術提供了參考。

然而NFV系統太復雜了，組件眾多，不同參與方利益出發點存異，導致標準化的推進緩慢。

(2)大企業以企業標準來要求廠商，規范NFV系統，但各廠商對規范的理解有偏差，實現能力和出發點也各不相同，只能通過試驗試點去打磨成熟，但這需要大量的時間和人力。

(3)需求發展變化太快，這些標準和要求都需要不斷演進和成熟，于是出現了運營商疲于去制定和修正，廠商疲于去適配。

2. 希望充分發揮云的優勢，使得云平臺的能力服務化，資源靈活調度分配，整體提升資源效率，但是當前產業依然是軟硬解耦的初級階段徘徊

(1)多數網元的設計還處于將傳統電信設備上的軟件直接移植到虛擬機鏡像的階段，并沒有按照云化的方式設計和使用云平臺。

(2)云平臺也沒有充分結合業務需求，提供豐富的云服務，進行資源靈活調度管理，也不能通過有效的手段，基于運行的業務情況，優化和提升整體的資源使用效率。

3. 運維模式轉變，運維難度增加，不知該如何應對

相比較傳統的以設備運維為主的模式，電信云是一個平臺級的系統，涉及的組件眾多，如何有效進行運維分工，如何進行有效地監控，如何通過協作，進行運維問題分析定位，甚至如何進行問題預測，都是不小的挑戰，在這些方便，當前還尚未形成明確的解決方案和定義。

所有的這一切都使得NFV遲遲不能大規模上線，使得業界對NFV的成熟度一直存疑，于是有了NFV倒地出局的悲觀論調。那問題到底出在哪里了?

• 是運營商不需要一張靈活的網絡嗎?不是
• 是技術上有難以克服的瓶頸嗎?不是
• 是產業界生態不支持嗎?不是

既然有運營商需求，有技術方案，有產業生態，那到底是什么原因導致這些困難的?

答案是NFV的落地模式，解決NFV建設使用***一公里的問題，千萬不要小看這***一公里，多少好的概念因為沒有解決好***一公里，長期處于雷聲大雨點小的窘境，遲遲不能推進，甚至錯過風口被淘汰。

那電信云的落地模式是什么，如何解決以上問題呢?筆者個人認為這正是NFV決勝下半場的關鍵，決定了電信云能否穩步爬升和真正落地開花。

三、下半場的命門

NFV使得通信網絡由橫向的設備連接，轉變為縱向的分層系統構建，傳統針對CT設備的建設使用模式要轉變為針對IT云系統的建設使用模式，在這種轉變中，如果還是以純粹依賴廠商提供產品和服務的傳統模式進行落地建設，就必然會出現以上的問題，從而使得NFV的建設步履維艱、NFV的優勢也最終會大打折扣。

那么NFV的落地模式到底什么，也就是如何找到行之有效的方法保證NFV的快速落地，并發揮出云計算的優勢，這還得從前文提到的困難點來一一探討。

1. NFV系統組件復雜，所以在初期要加強對接適配工作，不能完全依賴規范和標準解決。而是將集成標準化，透明化，提升集成問題解決效率，加速落地建設

傳統的模式，以case by case的項目建設出發，廠商產品通過標準、規范和技術要求保證其集成對接，集成商以交鑰匙的方式提供集成服務，但是對于復雜系統，很多在集成中或者后期使用中出現的適配、調優等系統性問題，都是前期技術要求不容易覆蓋全的。一種考慮就是打開集成工作的黑盒，標準化集成的流程，標準化集成設計，標準化集成對接等，將其中一些關鍵的系統設計、對接驗證或者系統驗證的工作提取出來，提前在一個集中平臺上進行處理，并且在NFV系統集成中實施和后期使用中，也能夠持續保障，這就保證了系統集成建設效率。另外，標準化后，自然地演進到自動化，幫助我們高效地發現那些規范標準所觸摸不到的問題，快速地迭代規范和標準要求，加速新業務和新技術的引入。總之，這樣就實現了集成過程的透明和高效，而不是低效得去對系統做黑盒的驗證，緩步推進規范和標準的完善。

2. 構建IT化的集成驗證模式，使云計算的優勢迅速構建起來，提升NFV系統的落地質量

發揮云計算的優勢，本質上來說是推動網元業務的云化設計，并完善云平臺的構建和資源使用。云計算的發展歷程證明這個過程不是一蹴而就，需要持續的迭代優化，需要將開發/集成/使用有效聯動起來，但傳統的建設和使用模式其實是產品和服務采購的方式，難以做到這一點，因而應對云模式的時候就顯得力不從心了，這也是為什么我們那么辛苦，但結果卻不盡如人意。

由于當前NFV組件都是廠商來提供，一種考慮是運營商構建一套和廠商聯動的機制，引入 IT領域的DEVOP的模式，聯合合作伙伴，把廠商的產品開發演進和運營商的集成驗證結合成一個體系。推進NFV組件的快速迭代演進，以下是這***程的初步構想。

立足NFV整體的集成過程，將NFV軟件組件開發/集成/驗證相結合，形成一個閉環過程，篇幅所限，這里不再展開技術細節。

有了這樣的平臺，就可以和廠商一起迅速集成驗證，生產中有了任何問題，迅速展開回歸驗證，這樣各種網元的適配問題、云化改進、以及云平臺的各種技術演進都能進行充分驗證和迭代。

3. 對于復雜系統，運維問題的有效解決，需要構建建設/運營運維一體化，保障落地使用

構建建設、運營、運維一體化的新型集成，將承擔落地建設的角色和技術研究驗證的角色密切結合。一種運維模式的考慮是，構建集成驗證中心，將屬地建設和集成驗證中心進行聯動，幫助快速分析定位，加速運維問題的技術驗證，并且沉淀下來，形成運維知識庫和能力的積累，篇幅所限，這里不再詳述。

在以上的這些工作中，我們看到運營商已經不能再像買產品和服務一樣置身事外，而是要深度地走進自己的系統，把控自己的系統，取代客戶與供應商的老式交易，形成合作共贏的伙伴式關系。具體操作上，主要是提升NFV落地中的可控性，利用廠商提供給我們的產品和服務，在技術上主導平臺的設計、建設、運營運維和演進，也就是形成一種新型的落地模式。

4. 縱觀國際上的實踐，大家在落地模式上也在朝著這兩個方向推進，強調對系統的把控，也強調產業合作

(1) AT&T的歷程

在AT&T Vision 2020轉型計劃中，AT&T董事長兼***執行官蘭德爾•斯蒂芬森說：”到2020年，我希望AT&T成為一家科技公司，我們將通過云計算來管理所有的數字業務，包括手機、有線、衛星電視和海量數據等，就像谷歌和亞馬遜那樣“，其實就明確了其IT化轉型和自主轉型的思路，而從這些年向外部釋放的種種信號來看，也確實在朝這個方向邁進。

Domain2.0的云戰略提出之初，ATT和IBM展開云計算和大數據的合作;2015年AIC云架構形成，構建基于openstack開源云架構，和當時的IT集成商Mirantis深度合作，歷經AIC1.O/ACI2.O/AIC3.O，2018年演進到NC云架構，依靠自身的力量構建了基于容器的云平臺持續集成開發體系(DEVOPS)，并且將該架構開源成AIRSHIP項目。 從工作流角度看，AIRSHIP包含了基于容器的云平臺持續集成開發，同時也包含了集成部署和系統測試。

坦白的說，AT&T的實踐，雖然目前成敗未卜，但確實有幾百人的技術團隊，對整個NFV系統有很強的把控力。

(2) 瑞士電信的實踐

看完了大廠，再來看看瑞士電信，他們建設NFV并不是對通信網絡整體的改造，而是從TV業務出發，構建Media Cloud，承載當前和未來與娛樂相關的網絡服務，一方面，他們選擇了惠普作為合作伙伴，提供云平臺和集成解決方案，負責生產環境的系統集成;另一方面構建了自己的實驗室，開展平臺以及業務的兼容性和性能、可靠性等測試。并且聯合合作伙伴，就平臺的容器化演進、構建基于公有云和電信云的混合云，開展技術演進的實踐驗證。

四、已經在路上

用NFV去重構傳統CT架構。這意味著CT要接受IT的技術，接受IT的思維，于是我們看到X86通用服務器、OpenStack云平臺、微服務業務設計等一系列IT的技術在CT中廣泛應用，而伴隨NFV步入下半場，快速規模落地，成為關注焦點，這時一個重要的IT建設模式逐步走進我們的視野，那就是快速迭代、快速演進的思維和技術體系，而這一體系的構建基礎就是可控的技術能力，以及合作伙伴式的產業生態。

行文至此，已經凌晨2點多了，伏案遐思，回想這些年在NFV一線的摸爬滾打，感慨良多，雖然各種吐槽，雖然也曾經深陷各種技術細節問題，萌生沮喪，但也深深體味著NFV前進路上點點滴滴的進步，可以看到產業界在思想上，從消極抵制過渡到慢慢接受，技術上從完全不能對接到大部分問題已經解決，企業標準接口逐步細化完善，集成內容和集成流程的定義從無到有，集成設計逐步規范化，提升集成效率的自動化探索也如火如荼，雖然和我們理想中高大上的那朵云還有較遠的距離，雖然落地起來還磕磕絆絆，但是NFV已然可行，同時運營商在可控模式上也一直在努力，點點滴滴默默積累。

邁進下半場后，我們只要在電信云建設/使用/演進過程中，將把控力和產業合作上結合起來，建立起集成/運營運維一體化的快速迭代模式，就必然能把NFV規模落地構建起來，那時候還會有人討論NFV的倒地和出局嗎?