目前國內的網絡運維還處于初級階段，工作人員每天就像救火一樣，天天疲于奔命。“什么破網絡怎么又斷了”，“我去，服務器宕機啊”，“這個網速慢的跟烏龜爬的一樣”，這些埋怨聲每天都在運維人員耳邊回蕩。運維人員只能埋頭查找系統運行的日志，耗時耗力，老眼昏花不說，有時候忙了半天還一無所獲，作為運維工程師的你，有木有遇到過類似苦逼的經歷?

[[247314]]

傳統網絡的運維痛點

傳統的網絡運維每天都是針對不同的廠商設備敲不同的命令行，從 Cisco、Juniper、到華為、華三，變化的只是換一種命令show / display 、no/undo。網絡管理分散，網絡和云管平臺、安全、IT/業務系統互相獨立，需要分別維護，效率低;網絡結構，配置、拓撲、鏈路狀態的不可視化，運維人員只能依賴經驗和記憶，變更調整網絡，這為網絡留下了大量隱患;管理模式單一，基于單設備或單機架構管理，錯漏多、排障難等等。當網絡出現問題時，公司的各個大小部門都在埋怨運維部門，可是運維人員也很無辜，每天面對繁雜的工作不說，最后出了問題也只能“打碎牙齒和著血往肚子里面咽”，成了名符其實的“背鍋俠”。

運維部門每天都要制定不同的規章制度，較大規模的公司會有自己的開發人員對開源軟件和開源產品做二次開發。在傳統的網絡中，隨著企業業務上漲，該公司的網絡運維部門規模也會跟著擴大。一個典型的網絡運維部門，開始團隊只有十幾人，當四五年后，業務系統變得復雜，網絡設備涉及的種類越來越多，運維人員也越來越多，基本翻了兩倍。他們每天都需要7*24小時值班，哪怕是已經下班回家的工作人員也是手機不離身。處理舊的故障時會有故障模板。當遇到新的故障時，除了要辛辛苦苦找方法解決，最后還要再寫新的故障模板。于是，運維人員的故障模板庫越來越來越長，越來越復雜。然只能嘆息“吾心甚累!”

網絡的發展

網絡在發生什么樣的變化?我們只能看到網絡的變化，才能看到網絡運維需要對應做什么變化。

從1974年TCP/IP協議的發布，到今天的SDN,網絡技術一直在發展。在這期間產生了快速以太網、MPLS、SDN技術、Openflow 1.0以及后續的版本、Open Daylight的發布等，促進了網絡的發展。

20世紀60年代，很多大學和研究機構都在致力于新的通信技術，其中有一家美國國防部最為突出，當時為實現迂回的通信傳輸方式，分組交換方式便應運而生了。到20世紀60年代下半葉，已有大量的人員投入分組交換和分組通信的研究中。后來為給互聯計算機中提供可靠的通信，到1982年全球性的組織提出了TCP/IP協規范，1990年左右不論是局域網還是廣域網，都開始傾向TCP/IP協議。

互聯網投入商用是從1995年開始，當時互聯網服務供應商數目劇增，1996年IPv6規范出爐，載入RFC。

1995年開始做快速以太網標準，1997年IETF成立MPLS工作組。2005年中國出現了電信級以太網概念，同年，全球骨干網絡基礎建設大規模興起。

2006年了SDN 誕生，從誕生至今，在中國商用落地的項目并不多。2009年的時候，Openflow1.0 正式發布，在全球掀起了一陣風潮，大家開始意識到網絡要改變了。2011年開始 ONF 的成立又掀起另一股浪潮。2012年谷歌B4全面運行，2013年 OpenDaylight 發布，2014年 ONOS 發布。各行各業的玩家開始進入SDN領域。

那SDN是什么

SDN是Software Defined Network的縮寫，也就是軟件定義網絡。SDN是一種網絡架構，將網絡的控制平面與轉發平面分離，并通過開放和可編程接口直接對控制平面進行編程。SDN的核心理念就是希望通過應用程序來控制轉發行為，完全通過軟件來定義整個網絡。

SDN架構分為應用層，控制層和基礎設施層：

• 應用層包括各種不同的業務和應用，負責各種網絡資源的編排;
• 控制層也就是SDN的控制軟件，負責處理各種數據轉發資源，維護網絡拓撲、狀態信息，進行網絡全局管理;
• 基礎設施層包含了各種網絡設備，負責數據的處理、轉發和狀態收集。

SDN是對現有網絡架構重新構建的技術。傳統網絡架構是由交換器、路由器等網絡基礎設施定義的網絡流量的傳輸，就像城市道路上的車流一樣，在沒有GPS導航前，每個十字路口如何轉向，基本是司機根據當前看到的情況走自認為最短最好的路徑，但高峰時段往往塞成一鍋粥。而SDN是從全城動態交通狀況，根據每輛車的需求(如時間最短、費用最省、不走高速等)來安排調度每輛車如何到達目的地，從全局視角調度，也保證了每輛車的最優線路。

SDN技術因其架構的開放性和靈活部署及編程能力，成為下一代網絡核心技術的首選。無論是Google對于其DC(數據中心)系統完成的SDN改造，還是IT巨頭微軟和阿里巴巴分享的SDN云服務經驗，無一例外都為此技術的應用描繪了美好的前景。基于SDN的網絡虛擬化，能夠將業務的邏輯網絡拓撲與物理網絡拓撲解耦，極大提升業務交付速度，簡化網絡運維，同時能夠滿足運營商、政企對于降低網絡成本、提升業務創新速度的訴求。

SDN給運維帶來的優勢

傳統網絡由具有集成控制和數據轉發平面的設備組成，因此每個盒子都需要獨立配置和管理。即使對網絡進行簡單更改也可能需要數周甚至數月才能完成，因為必須對每臺設備進行更改。但隨著物聯網(IoT)，云計算和移動性的興起，SDN架構中控制和數據平面的分離使控制能夠從設備中抽象出來并集中化，以便網絡管理員可以集中控制管理底層復雜基礎設施。從理論上講，所有網絡節點只需要轉發或數據平面來推送數據包。SDN給運維帶來的優勢具體如下：

• 減少開銷

由于網絡管理員不再需要從一個設備到另一個設備來更改網絡配置，因此他們可以更有效地進行必要的更改。不僅可以通過集中控制有效地控制網絡配置，還可以自動化許多配置。

• 整體的集中式網絡管理

SDN方法的最大好處之一是可以通過單個設備控制所有網絡組件。物理和虛擬設備都可以通過單個API進行控制，使得網絡管理員的生活更加輕松。

• 啟用“無網絡影響的網絡實驗“

SDN為網絡帶來的靈活性允許管理員“跳過”SNMP所施加的限制并嘗試網絡配置，而網絡也不會受到影響。

• 更詳細，粒度安全

虛擬化，云計算和移動設備為信息安全帶來了重大挑戰。SDN控制器提供單點控制，其中信息安全策略和規則可以在整個組織中分發。此外，SDN控制器還提供了一個附加點，可以放置安全策略來解決特定的軟件和應用程序漏洞。

• 提高應對網絡威脅的能力

SDN通過為IT人員提供網絡活動的實時可見性，幫助他們應對安全事件。您還可以對網絡進行編程，以自動響應某些類型的事件，從而減輕人為依賴。例如，假設有一臺筆記本電腦檢測到有人正在發送惡意軟件或攻擊另一個系統。SDN允許您對網絡進行編程，以根據設備地址或應用程序等屬性有選擇地阻止特定流量。

• 提高對網絡的可見度

整體提高組織網絡的可見性是軟件定義網絡的最大好處之一。首先，集中控制可以識別網絡安全性，性能和挑戰。所有這些都可以在不干擾網絡活動的情況下進行分析。通過找出帶寬或安全挑戰的源頭，可以在網絡中斷之前防止中斷和停機。

• 可擴展性

此外，這種集中化的靈活性允許包含更多選項，因為SDN允許程序員編寫公共接口并管理多個設備，而無需了解網絡上每個設備的復雜功能。

• 更有效地使用網絡資源

在傳統網絡中，確定數據如何傳播的網絡控制平面位于硬件中。在SDN基礎設施中，控制平面是獨立于網絡硬件操作的軟件功能。這種網絡和數據控制平面的邏輯分離使SDN能夠支持高級應用和服務，包括大數據分析，同時跟上不斷增長的網絡服務需求。

• 提高正常運行時間和可靠性

SDN程序內置的靈活性和冗余可以消除在部署網絡期間可能發生的人為錯誤。此外，SDN支持大多數物理和虛擬網絡設備的虛擬化，允許您在網絡的一個組件上執行升級或替換，而無需使整個系統脫機。在發生停機時，SDN支持對配置進行快照，從而可以快速地從升級導致的中斷中恢復。

網絡的未來將越來越依賴于軟件，SDN在應對傳統網絡方法所面臨的許多挑戰方面邁出了一大步。IT通過提高可見性和安全性，同時簡化和自動化操作，將網絡運營帶到現代領域。

SDN運維工具的改變

在傳統網絡運維中，運維規章制度定了那么多，運維人員能做到的其實也就那么多，針對不同廠商的硬件設備敲不同的命令行，出現問題查查日志，寫寫故障報告。SDN網絡的主要特點是集群化、采虛擬的軟件網絡數據流，通過圖形化的方式簡易呈現，方便業務上線，以及后期內容的維護。那么SDN這么牛，難道就不需要運維工具了嗎，答案當然是否定的!

在 SDN 系統里，有獨立的中央控制器和上層應用層，轉發層只是作為最底層的數據轉發，業務編排在控制器做，控制器是純軟件系統，這套系統可以實現對外API對接，這時候 DevOps 就派上用場了。

DevOps促進開發人員，運營團隊和基礎架構專業人員之間的溝通和協作，以實現統一和自動化的IT開發，實施和管理。同時，SDN允許工程師將軟件控制應用于網絡元素，集中管理和配置大量虛擬和物理基礎架構。

1. SDN與NetDevops相遇

DevOps(Development和Operations的組合詞)是一組過程、方法與系統的統稱，用于促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。它是一種重視“軟件開發人員(Dev)”和“IT運維技術人員(Ops)”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。它的出現使軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。

2. DevOps和自動化網絡需求

DevOps利用小型applet(或微服務)中應用程序的組件化，這些applet 可以分布在一系列數據中心資源(即公共云或私有云)中。容器(例如，Docker)正在成為快速引入新微服務流行方式。

微服務和DevOps應用程序需要快速配置計算和存儲網絡資源，使其能夠快速運行，根據需要進行擴展，以高可靠性執行并保證服務的安全性。網絡需要管理工具來滿足開發和自動化的需求——減少停機時間和處理時的復雜性，同時又不需要發送Opex的數據。。

網絡負責為DevOps應用程序快速配置適當的資源，并在保護和管理這些快速遷移的應用程序方面發揮關鍵作用。然而，微服務的敏捷性和快速變化的要求挑戰了傳統網絡的能力。應用程序的分解意味著手動網絡的移動部件太多 - 因此網絡自動化至關重要。使用DevOps預先測試網絡資源的能力對于減少應用程序部署時間非常重要(例如，返回修復網絡問題)。基本理想：開發人員不必擔心網絡資源，包括IP地址或防火墻規則。

3. SDN，DevOps和自動化相遇的地方

軟件定義的網絡優化了開發和自動化的網絡，使部署復雜應用程序的IT組織能夠快速提供網絡資源和服務(包括安全策略)。SDN支持對網絡進行集中管理，并將(手動)配置的挑戰從人員轉移到技術上，降低運營成本。

基于SDN的網絡可以自動檢測流量變化，并根據應用類型，服務質量和安全規則等參數選擇通過網絡獲取的路徑數據。軟件控制平面管理和隱藏網絡復雜性，能夠使10,000個交換機看起來像一個。SDN可以指示網絡提供與其相關應用程序一致的服務，并支持快速部署大量新應用程序和微服務(例如，容器)。

SDN提供自動化網絡流程的能力，以快速為DevOps應用程序提供網絡/安全資源。它可以通過將(手動)配置的挑戰從人員轉移到技術來降低運營成本。許多超大規模的云提供商 - 包括谷歌，蘋果，Facebook和微軟 - 已經部署了SDN技術，以幫助自動化其網絡的配置和管理。IT領導者應考慮部署SDN以滿足其DevOps團隊和相關應用程序不斷變化的需求。

再談SDN 運維工作，SDN有那么多優點，那么運維工作會不會很輕松呢?SDN運維工作主要包含兩個方面，一個是日常運維、二是工程項目。日常運維工作和傳統的網絡運維類似，值班監控，一二線故障解決，以及和各部門溝通。

重點是跨部門溝通，傳統的網絡運維因為很多設備和功能都是相互捆綁的，相關的功能函數并不對外開放，只有設備供應商自己清楚，所以運維常常是一個封閉的部門，和開發并不會有太多的交集。但是進入SDN的時代以后，運維會涉及到很多部門，例如測試、研發等。這時運維已不再是封閉的，需要從一個新的角度去看待這個崗位，需要提前與開發部門、測試部門的網絡工程師做互動，這一點和DevOps的要求也是很符合的，即為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。

SDN運維用到的工具和傳統網絡運維類似，主要有 Cacti、Smokeping、Nagios、Zabbix。但是現在更加講究開源，開源更能促進SDN和網絡技術的發展，運維工程師可以從中學到更多關于網絡的知識，對于網絡會擁有更多的自主管理權，工程師還可以在開源的軟件上根據自己需求做二次開發，較傳統的封閉式運維大大減少網絡運維成本和提高運維效率。

SDN自動化運維

運維包括告警監控、變更、排障三個階段。在介紹告警之前談一下運維人員需要關心的SLO和SLI,其次會簡要分析監控，分析，變更和排障。

1. 運維服務質量設計

在傳統的網絡運維中，網絡工程師們都關注SLA,但作為運維的人都會關注SLO和SLI。我們需要找到服務質量的指標是什么，根據指標制定目標。SLI是經過仔細定義的測量指標，它根據不同系統特點確定要測量什么，SLI的確定是一個非常復雜的過程。SLI要回答要測量的指標是什么，測量時系統狀態怎么樣，如何匯總處理測量的指標，測量指標能否描述服務質量，測量指標的可信度。主要關注性能、可用性、質量、內部指標和因素人這幾個方面。SLO(服務等級目標)指定了服務所提供功能的一種期望狀態。SLO里面應該包含所有能夠描述服務應該提供什么樣功能的信息。服務提供者用它來指定系統的預期狀態;開發人員編寫代碼來實現;客戶依賴于SLO進行商業判斷。SLO里沒有提到，如果目標達不到會怎么樣。網絡時延、丟包率以及端到端都可以作為衡量的指標，我們根據這個指標制定SLO。

SLA是一個涉及雙方的合約，雙方必須都要同意并遵守這個合約。當需要對外提供服務時，SLA是非常重要的一個服務質量信號，需要產品和法務部門的同時介入。

2. 監控告警

SDN能更多的進行白盒監控，即通過對系統內部的性能指標進行監控了解系統的運行狀態。從南向接口看，SDN只需要監控少數幾種協議，監控相對簡單，而面對業務變更時更是可以隨著API變更而變更。主要復雜度集中在控制平面和業務編排，監控業主要集中在控制平面健壯性，用戶業務狀況以及控制轉發的一致性等方面。在大型網絡里因底層鏈路故障導致的大量路徑計算和重新優化需要控制及時，反應要快。面向最終用戶的web接口又會需要對各種請求和配置變更做出實時響應和分析。

運維系統中監控告警設計，通常從最底層的采集開始，自上而下設計，其次是存儲、功能模塊開發、上層告警通道、用戶側。從采集的方式上來說要根據網絡架構來選擇是采用集中式的，還是分散式的。如果網絡中的轉發節點較多，那么在這種情況下就無法采用集中式。需要根據自己的業務分布點，制定不同區域性的分布采集，包括存儲。部署中央存儲和分布式存儲，分布采集后實時同步到中央存儲，同時需要在本地存儲后做備份。

功能模塊方面通過在底層采集原始數據，根據原有系統的規則，從監控告警到告警通道，做一個中間層，這網絡管理人員可以根據自己網絡情況做的自定義的規則。

拿到原始數據后，如何將數據更好的展現出來，將有用的信息實時同步。SDN中實時告警不像傳統網絡只在底層轉發，現在它可以對業務系統和網元進行實時監控(操作系統的穩定性)。有了告警信息以后，對它進行分類，然后才能做接下來的告警分析。

3. 日志統計分析

日志統計分析，現在大多是公司都使用ELK來分析。該軟件可以根據自己的業務做不同的開發。

日志包括整個SDN系統。從上層的控制系統，中層操作系統、存儲、業務編排，底層轉發網元，最后底層傳輸。這些在傳統的網絡中，運維人員是不會關心的，只會關心網絡設備。

4. 流量統計分析

流量統計分析，現在網管系統和運維人員關注設備流量、端口流量，SDN 需要關注整條鏈路端口，更重要的是業務流量，SDN 最大的特點是能夠跟業務系統做到關聯，能夠通過運維系統查看所有業務相關的流量信息。

5. 變更

在傳統的網絡中，由于時間還有業務對網絡不同的需求后，很難有統一的配置模板。各種臨時的配置在不同的設備上安家。現在的網絡維護人員不敢刪除上一個運維人員的設定。天長日久，人，設備、需求的變換會導致配置和實際狀況脫節。SDN則基本擺脫了設備配置問題。基礎架構數據通過自發現和初始定義可以在GUI上實現。業務數據通過GUI和API實現，軟件升級時，控制平面的前端、后端、業務編排、底層控制器各組件既可以分開升級也可以統一升級，對轉發也沒有明顯的影響。

6. 自動化排障

SDN排障更多的是與Devops結合，通過軟件化手段解決。一個好的故障處理系統能夠自愈和關聯分析。當出現多個警告時，如何讓這些警告自動關聯，然后生成一個真正一個有用的。故障自愈就是在關聯以后，故障不需要人為的干預就可以自愈。

未來傳統的運維人員將何去何從

基于SDN技術的未來電信網絡架構的演進對運維流程產生了深刻的影響，電信技術與IT技術的融合對參與系統的運維團隊也提出了技能方面的新要求。

對于SDN的運維人員除了要知道傳統的運維技能和運維工具以外，還要了解SDN運維體系目前從SDN系統來講從最底層的資源，網絡設備、轉發網元、設備、服務器。采集部分主要涵蓋 SNMP 的采集，對傳統設備Netconf命令下發，對新設備 Openflow 的協議，對CLI的管理。

SDN運維體系架構

中間的存儲是獨立分開的，中間有日志、配置庫、知識庫，在存儲部分獨立分開。功能方面包括監控告警和數據采集，數據分析和統計，流程管理和項目管理，有很大一部分是資源管理，資源管理包括文檔配置，這部分主要基于CMDB，功能非常強大，如何結合SDN系統用起來，要根據自己網絡底層和控制器開發做制定。

SDN現在越被大多數公司采用，那對于企業來說如何培養出一個合適的SDN運維小能手呢?一般公司會選擇培訓現有的員工，因為他們覺得培訓現有員工比尋找和招聘新員工更具經濟效益。投資現有員工需要積極主動的自上而下戰略，提供大量培訓機會。其次從個人的角度來說網絡專業人士應該把握好自己的未來和職業生涯。并不是每個網工都需要成為程序員。相反，SDN需要更廣泛的網絡概念和基礎知識。要理解軟件系統是如何工作的，但并不意味著你必須編寫代碼，可需要了解整個生態系統是如何運作的，以及事情是在哪里完成的。除了這些基礎知識，網絡專業人員還應利用任何學習的機會，建議網絡專業人士在制定計劃后需要堅持下去。仔細規劃并專注于自己的軌跡，不要被外界情況所影響。