作者介紹：宋磊畢業(yè)于武漢大學，09年加入百度，現(xiàn)任百度網(wǎng)絡(luò)與服務(wù)器運維團隊技術(shù)經(jīng)理。

精彩看點

1. 網(wǎng)絡(luò)工程師在業(yè)務(wù)需求不斷變化和網(wǎng)絡(luò)規(guī)模急劇增長下都會遇到哪些挑戰(zhàn)?技能短板、各方的認可度、成就感和成長空間，這些是否能與你產(chǎn)生共鳴。
2. 百度網(wǎng)絡(luò)運維這些年的變革和方法論轉(zhuǎn)換，從應急搶險、到局部優(yōu)化，數(shù)據(jù)測量，再到能力建設(shè)，你的網(wǎng)絡(luò)目前處于哪個階段?能否從這里得到一些經(jīng)驗和幫助
3. NetDevOps是網(wǎng)絡(luò)工程師職業(yè)發(fā)展的新方向，企業(yè)內(nèi)部如何培養(yǎng)網(wǎng)工DevOps的能力，除了技能學習，還應該有管理方法和團隊協(xié)作模式的變化。

網(wǎng)絡(luò)工程師的價值

伴隨近些年互聯(lián)網(wǎng)的蓬勃發(fā)展，百度的產(chǎn)品線日益豐富。業(yè)務(wù)上從搜索變現(xiàn)一枝獨秀到現(xiàn)在 O2O、互聯(lián)網(wǎng)金融、公有云服務(wù)崛起。但是所有業(yè)務(wù)對基礎(chǔ)設(shè)施的穩(wěn)定運行、隨需而變的要求沒有變化。這也是網(wǎng)絡(luò)運維團隊工作的核心目標，提供穩(wěn)定優(yōu)質(zhì)的網(wǎng)絡(luò)基礎(chǔ)設(shè)施，同時高效的滿足業(yè)務(wù)需求，保持業(yè)務(wù)的正常運行。

任何一個團隊的成長都是從平凡一步步鮮血淋漓的走向卓越，百度網(wǎng)絡(luò)運維團隊也不例外。在追求穩(wěn)定和高效的過程中不斷遇到挑戰(zhàn)。技術(shù)方面的挑戰(zhàn)主要來自于業(yè)務(wù)需求的不斷變化和規(guī)模的增長：

業(yè)務(wù)需求的不斷變化推動技術(shù)發(fā)展和規(guī)模發(fā)展，百度的業(yè)務(wù)形態(tài)很長時間以來都是類似搜索、貼吧等頁面展現(xiàn)類服務(wù)。隨著百度云、百度錢包這些新形態(tài)服務(wù)的發(fā)展，連帶推動了一大波網(wǎng)絡(luò)技術(shù)的迭代，這是一個各種技術(shù)不斷出現(xiàn)又消失，逐漸趨于穩(wěn)定的收斂過程，在這個過程里工程師需要投入大量精力去了解新技術(shù)并進一步判斷技術(shù)的發(fā)展方向。

隨著網(wǎng)絡(luò)規(guī)模不斷增長，變更和監(jiān)控也變得更加困難。特別是架構(gòu)和策略復雜的情況下，人工決策風險難以控制，考慮不周的變更會對整個網(wǎng)絡(luò)造成影響。規(guī)模增長的同時，網(wǎng)絡(luò)監(jiān)控也在逐步失效。傳統(tǒng)基于SNMP、SYSLOG的監(jiān)控可以測量到一部分網(wǎng)絡(luò)特征比如流量和協(xié)議狀態(tài)，但是對于全網(wǎng)時延、丟包這些重要的網(wǎng)絡(luò)特征無法監(jiān)控，從而忽略了這些業(yè)務(wù)有感問題的監(jiān)控。

與此同時，網(wǎng)絡(luò)工程師的個人發(fā)展也遇到了的挑戰(zhàn)：

1. 技能存在短板，好想法落地困難。經(jīng)常能遇到網(wǎng)絡(luò)工程師有好想法，但是在項目落地的過程中只能依賴外部開發(fā)團隊，排期和項目完成度較難控制，甚至因自己不具備 coding 能力，在前期的數(shù)據(jù)分析階段項目就夭折。網(wǎng)絡(luò)工程師coding能力的不足成了項目落地中的一個困難。
2. 認可與理解，每天報警不斷，家人不滿意。故障處理速度慢，業(yè)務(wù)不滿意。網(wǎng)絡(luò)故障業(yè)務(wù)先感知，自己不滿意。必須跳出救火式運維的套路，提高網(wǎng)絡(luò)運維的能力和效率，讓大家都滿意，從而得到更多的認可和理解。
3. 成就感和成長空間，項目無法快速落地，工作成績不被認可，每天疲于奔命沒有成就感，成長空間有限。如何突破個人的瓶頸?

改變的最重要一步是根據(jù)實際情況建立合適的方法論，調(diào)整工作重心。下面給大家介紹百度網(wǎng)絡(luò)運維這些年的變革和方法論轉(zhuǎn)換。

應急搶險

和絕大部分公司一樣，百度網(wǎng)絡(luò)運維團隊早期最主要的工作是應急搶險。當年的網(wǎng)絡(luò)是一個用商用設(shè)備組成的STP+VLAN大二層，除了有一些商用負載均衡設(shè)備外，同時還有一些服務(wù)器直接接入到公網(wǎng)。

大二層帶來的最明顯的問題是廣播風暴，08年某數(shù)據(jù)中心有4000多臺服務(wù)器，在這個網(wǎng)絡(luò)里面常態(tài)有1Gbps的單播泛洪流量，時不時還會有廣播風暴。網(wǎng)絡(luò)監(jiān)控用MRTG做流量圖、用正則表達式匹配SYSLOG做告警，工程師則拿著手機隨時等著收報警短信。

局部優(yōu)化

第二個階段開始做一些局部優(yōu)化。此時網(wǎng)絡(luò)架構(gòu)由大二層改為三層，網(wǎng)關(guān)終結(jié)在TOR上，網(wǎng)絡(luò)設(shè)備仍然是商用黑盒設(shè)備，開始自研負載均衡器等網(wǎng)絡(luò)組件。網(wǎng)絡(luò)運維團隊在這個階段的主要工作是聯(lián)合開發(fā)團隊做監(jiān)控和自動化定制，同時在網(wǎng)絡(luò)架構(gòu)上做一些深度優(yōu)化。

告警根因定位系統(tǒng)是當時的標志性項目。百度線上每天有幾百萬條原始日志告警，通過決策樹推理聚合同一事件的日志，可以將告警收斂到幾百個事件，今年的目標是告警量控制在每天100條以內(nèi)。

另外一個例子是做OSPF路由優(yōu)化。當時全網(wǎng)運行OSPF，在優(yōu)化之前核心交換機上維護了6萬條LSA，路由震蕩頻發(fā)，一次收斂需要1到2分鐘。當時做了大量分析，花了幾個月時間對全網(wǎng)OSPF整體進行了優(yōu)化，包括協(xié)議定時器的調(diào)整、各種路由匯總等，做完之后核心交換機LSA減少80%以上，接入層交換機路由條目減少90%，路由收斂時間降低一半且故障不再頻發(fā)。這里可以跟大家分享一下我們的經(jīng)驗，如果用OSPF來做組網(wǎng)，服務(wù)器規(guī)模沒超過15萬臺前可以通過各種優(yōu)化手段維持網(wǎng)絡(luò)穩(wěn)定運行。超過15萬臺后就需要從架構(gòu)和路由上進一步優(yōu)化了。

數(shù)據(jù)測量

第三個階段我們在做數(shù)據(jù)測量，也是最近這一兩年我們的核心工作，此時的網(wǎng)絡(luò)里運行有大量的自研交換機和NFV，DCI網(wǎng)絡(luò)也有了一定的規(guī)模。右下角這張圖簡單描述了數(shù)據(jù)中心網(wǎng)絡(luò)的結(jié)構(gòu)，包括數(shù)據(jù)中心核心、集群核心等。大家可以看到整個網(wǎng)絡(luò)里面，鏈路的數(shù)量非常多，如何知道每一條鏈路質(zhì)量是什么樣的，幾乎是不可能的任務(wù)。再看上面那張圖，黑色的大點可以認為是三個核心節(jié)點，其他小的是分布在不同城市的數(shù)據(jù)中心。每個節(jié)點到數(shù)據(jù)中心之間實際有幾十條物理鏈路互聯(lián)，兩個數(shù)據(jù)中心間路徑有上萬種組合。在這種規(guī)模的網(wǎng)絡(luò)中人工快速定位某條鏈路丟包幾乎不可能，但這又是必須要做的事情。

面對了很多因規(guī)模問題造成的困難后，我們提出一個解決問題的思路，測量-優(yōu)化-評價。

首先想辦法測量你需要的數(shù)據(jù)，比如網(wǎng)絡(luò)丟包率、時延抖動。拿到數(shù)據(jù)以后去做網(wǎng)絡(luò)架構(gòu)或測量方法的優(yōu)化，同時建立評價體系去看是否已經(jīng)優(yōu)化的足夠好。不斷的重復測量、優(yōu)化、評價這個過程，直到數(shù)據(jù)滿足業(yè)務(wù)要求。

舉一個具體的例子，某數(shù)據(jù)中心出口有兩條鏈路，主用的一條是時延較低，另外一條平時備份。從圖里可以看到網(wǎng)絡(luò)正常時延大概是在23毫秒左右，在故障的瞬間時延飆升，綠色曲線是網(wǎng)絡(luò)中默認QoS等級的服務(wù)，故障更早影響到了這個隊列。恢復期間也發(fā)生過幾次鏈路切換，時延有抖動。當每一次抖動都是可以具體量化的時候，就可以輕松判斷出來故障對業(yè)務(wù)有什么樣的影響，乃至不同服務(wù)等級的業(yè)務(wù)能感知到什么現(xiàn)象。

網(wǎng)絡(luò)質(zhì)量監(jiān)控的例子是我們內(nèi)部協(xié)作的一種方法，即運維團隊不直接開發(fā)，和開發(fā)團隊一起協(xié)作達成目標。在網(wǎng)絡(luò)質(zhì)量監(jiān)控項目中，網(wǎng)絡(luò)工程師翻閱大量業(yè)界和學界的論文進行調(diào)研，向開發(fā)團隊提出需求、給出測量方法、指導網(wǎng)絡(luò)部署方案。開發(fā)工程師則聚焦在怎樣去實現(xiàn)這種高并發(fā)的測量，如何用合適的算法計算具體哪些物理鏈路有影響，以及如何將最終結(jié)果呈現(xiàn)出來。***這套監(jiān)控系統(tǒng)除了能呈現(xiàn)整體丟包率和時延外，還可以通過端到端的測量，從數(shù)十萬種鏈路組合中直接定位到發(fā)生丟包的是哪一條鏈路后節(jié)點。

能力建設(shè)

2016年我們關(guān)注的方向叫網(wǎng)絡(luò)能力建設(shè)，為了進一步提高運維能力，縮短網(wǎng)絡(luò)能力落地周期，運維團隊開始轉(zhuǎn)向DevOps。網(wǎng)絡(luò)最基本的能力是路由轉(zhuǎn)發(fā)，除此以外DIFFSERV、流量調(diào)度、快速故障恢復是等能力。這些能力之前或者缺失或者分散在不同系統(tǒng)里，現(xiàn)在我們來填補空白同時整合能力。網(wǎng)絡(luò)工程師要做的是去開發(fā)與業(yè)務(wù)邏輯強相關(guān)的內(nèi)容，比如怎樣做流量調(diào)度，怎么去做故障切換等。像ODL框架在線上應用的性能問題、容災能力等問題則由開發(fā)團隊去解決。

談到NetDevOps就有必要提下SDN。我們所理解的SDN是指在數(shù)據(jù)基礎(chǔ)上根據(jù)策略執(zhí)行動作，從而干預網(wǎng)絡(luò)。

首先先看左邊的圖，兩個數(shù)據(jù)中心間通信，常態(tài)下路由協(xié)議會幫你計算出來他們之間的訪問路徑，但當帶寬突然少了四分之三，網(wǎng)絡(luò)嚴重擁塞時應該怎么辦?

我們的解決方案是網(wǎng)絡(luò)工程師自己開發(fā)BGP控制器， 通過干預BGP屬性和路由，在整個核心網(wǎng)的范圍內(nèi)疏導流量。開發(fā)控制器本身并不算非常復雜，更有挑戰(zhàn)的是落地過程中遇到的大量需要網(wǎng)絡(luò)工程師處理的細節(jié)，比如如何發(fā)現(xiàn)流量擁塞出現(xiàn)，如何選取調(diào)度路徑，網(wǎng)絡(luò)架構(gòu)在非穩(wěn)態(tài)下是否會造成調(diào)度失效，各個核心節(jié)點下發(fā)路由的順序應該如何，哪些流量可以做調(diào)度，調(diào)度引入的時延增長是否會影響業(yè)務(wù)等等。這些細節(jié)需要網(wǎng)絡(luò)工程師一點一點的去分析琢磨。

另一個是即將落地的項目，網(wǎng)絡(luò)集群自動故障隔離。右圖是一個CLOS網(wǎng)絡(luò)，spine-leaf中間的連線可以多達上萬條。這個項目的目標是當監(jiān)控發(fā)現(xiàn)一組spine出現(xiàn)異常時，可以自動隔離故障區(qū)域。技術(shù)實現(xiàn)方面基于ODL整合監(jiān)控和策略執(zhí)行動作。這里有個特別的地方，是把現(xiàn)場操作工程師作為SDN的一個組件插入到流程里面，包括自動下發(fā)工單，提供清晰的操作指引和自動驗證能力，反饋操作結(jié)論到流程等。這樣爭取在網(wǎng)絡(luò)工程師不介入的情況下，做到故障自動隔離和恢復。

DevOps知易行難，轉(zhuǎn)型從鋪墊到落地，花了大概1年半時間。

以前百度網(wǎng)絡(luò)工程師主要來自銀行、運營商和互聯(lián)網(wǎng)企業(yè)，這些工程師有豐富的網(wǎng)絡(luò)設(shè)計運維經(jīng)驗;校招的學生很多還沒畢業(yè)就拿到了CCIE證書，了解網(wǎng)絡(luò)協(xié)議和設(shè)備。但是這個團隊里沒有人是非常擅長coding的。為了進一步提高運維能力，縮短網(wǎng)絡(luò)能力落地周期，在這種背景下我們開始了DevOps轉(zhuǎn)型。配合轉(zhuǎn)型，從管理策略到團隊協(xié)作模式都需要做出相應調(diào)整。

• 首先管理策略上要發(fā)生變化，明確告訴大家除了深度了解路由協(xié)議和網(wǎng)絡(luò)架構(gòu)設(shè)計外，轉(zhuǎn)向DevOps是職業(yè)發(fā)展的一個好的方向。
• 第二個是成員轉(zhuǎn)型意愿非常強烈。尤其是入職一年兩年左右的同學，因為招到的人本身素質(zhì)非常好，都是來自于重點高校計算機或通信專業(yè)，本身有一定 coding 基礎(chǔ)，進一步提升 coding能力并不是非常困難的事情。這樣經(jīng)過一年的培養(yǎng)和鍛煉，我們終于有了一些能coding 的CCIE!
• 第三個難點是理清和其他團隊的關(guān)系。特別是運維平臺研發(fā)團隊，要分清哪些是網(wǎng)絡(luò)工程師應該做的，哪些是適合研發(fā)團隊做的。網(wǎng)絡(luò)工程師擅長的領(lǐng)域在設(shè)備、協(xié)議和業(yè)務(wù)邏輯，但涉及到平臺級開發(fā)、算法優(yōu)化等方面時，需要研發(fā)團隊來一起實現(xiàn)。以前的合作模式是網(wǎng)絡(luò)運維工程師提需求，現(xiàn)在的合作模式是網(wǎng)絡(luò)運維和開發(fā)團隊是一個聯(lián)合開發(fā)團隊。
• 第四個是教練式輔導。讓網(wǎng)絡(luò)工程師寫程序在起步階段最難，我們聘請了資深的研發(fā)工程師對網(wǎng)絡(luò)工程師從設(shè)計思想、實現(xiàn)方案到開發(fā)規(guī)范全方位輔導，大幅降低學習成本。

總結(jié)

這些年百度網(wǎng)絡(luò)運維思路和方法論上不斷進行著變革，應急搶險、局部優(yōu)化、數(shù)據(jù)測量、能力建設(shè)，這四個階段也是方法論的不斷轉(zhuǎn)變的過程。在這個過程中，我們看到網(wǎng)絡(luò)工程師的工作重心在不斷調(diào)整，工作成績和個人價值在也在不斷提高。期待通過DevOps和自動化釋放更多網(wǎng)絡(luò)工程師的能量，在技術(shù)和個人成長方面取得突破，對業(yè)務(wù)發(fā)展提供更多幫助。希望百度的經(jīng)驗對大家有所幫助，期待與各位更多的交流。