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

精彩看點(diǎn)

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

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

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

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

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

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

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

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

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

應(yīng)急搶險(xiǎn)

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

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

局部優(yōu)化

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

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

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

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

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

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

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

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

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

能力建設(shè)

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

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

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

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

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

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

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

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

總結(jié)

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