百度網絡運維這些年經歷的變革和方法論
作者介紹：宋磊畢業于武漢大學，09年加入百度，現任百度網絡與服務器運維團隊技術經理。
精彩看點
- 網絡工程師在業務需求不斷變化和網絡規模急劇增長下都會遇到哪些挑戰?技能短板、各方的認可度、成就感和成長空間，這些是否能與你產生共鳴。
- 百度網絡運維這些年的變革和方法論轉換，從應急搶險、到局部優化，數據測量，再到能力建設，你的網絡目前處于哪個階段?能否從這里得到一些經驗和幫助
- NetDevOps是網絡工程師職業發展的新方向，企業內部如何培養網工DevOps的能力，除了技能學習，還應該有管理方法和團隊協作模式的變化。
網絡工程師的價值
伴隨近些年互聯網的蓬勃發展，百度的產品線日益豐富。業務上從搜索變現一枝獨秀到現在 O2O、互聯網金融、公有云服務崛起。但是所有業務對基礎設施的穩定運行、隨需而變的要求沒有變化。這也是網絡運維團隊工作的核心目標，提供穩定優質的網絡基礎設施，同時高效的滿足業務需求，保持業務的正常運行。
任何一個團隊的成長都是從平凡一步步鮮血淋漓的走向卓越，百度網絡運維團隊也不例外。在追求穩定和高效的過程中不斷遇到挑戰。技術方面的挑戰主要來自于業務需求的不斷變化和規模的增長：
業務需求的不斷變化推動技術發展和規模發展，百度的業務形態很長時間以來都是類似搜索、貼吧等頁面展現類服務。隨著百度云、百度錢包這些新形態服務的發展，連帶推動了一大波網絡技術的迭代，這是一個各種技術不斷出現又消失，逐漸趨于穩定的收斂過程，在這個過程里工程師需要投入大量精力去了解新技術并進一步判斷技術的發展方向。
隨著網絡規模不斷增長，變更和監控也變得更加困難。特別是架構和策略復雜的情況下，人工決策風險難以控制，考慮不周的變更會對整個網絡造成影響。規模增長的同時，網絡監控也在逐步失效。傳統基于SNMP、SYSLOG的監控可以測量到一部分網絡特征比如流量和協議狀態，但是對于全網時延、丟包這些重要的網絡特征無法監控，從而忽略了這些業務有感問題的監控。
與此同時，網絡工程師的個人發展也遇到了的挑戰：
- 技能存在短板，好想法落地困難。經常能遇到網絡工程師有好想法，但是在項目落地的過程中只能依賴外部開發團隊，排期和項目完成度較難控制，甚至因自己不具備 coding 能力，在前期的數據分析階段項目就夭折。網絡工程師coding能力的不足成了項目落地中的一個困難。
- 認可與理解，每天報警不斷，家人不滿意。故障處理速度慢，業務不滿意。網絡故障業務先感知，自己不滿意。必須跳出救火式運維的套路，提高網絡運維的能力和效率，讓大家都滿意，從而得到更多的認可和理解。
- 成就感和成長空間，項目無法快速落地，工作成績不被認可，每天疲于奔命沒有成就感，成長空間有限。如何突破個人的瓶頸?
改變的最重要一步是根據實際情況建立合適的方法論，調整工作重心。下面給大家介紹百度網絡運維這些年的變革和方法論轉換。
應急搶險
和絕大部分公司一樣，百度網絡運維團隊早期最主要的工作是應急搶險。當年的網絡是一個用商用設備組成的STP+VLAN大二層，除了有一些商用負載均衡設備外，同時還有一些服務器直接接入到公網。
大二層帶來的最明顯的問題是廣播風暴，08年某數據中心有4000多臺服務器，在這個網絡里面常態有1Gbps的單播泛洪流量，時不時還會有廣播風暴。網絡監控用MRTG做流量圖、用正則表達式匹配SYSLOG做告警，工程師則拿著手機隨時等著收報警短信。
局部優化
第二個階段開始做一些局部優化。此時網絡架構由大二層改為三層，網關終結在TOR上，網絡設備仍然是商用黑盒設備，開始自研負載均衡器等網絡組件。網絡運維團隊在這個階段的主要工作是聯合開發團隊做監控和自動化定制，同時在網絡架構上做一些深度優化。
告警根因定位系統是當時的標志性項目。百度線上每天有幾百萬條原始日志告警，通過決策樹推理聚合同一事件的日志，可以將告警收斂到幾百個事件，今年的目標是告警量控制在每天100條以內。
另外一個例子是做OSPF路由優化。當時全網運行OSPF，在優化之前核心交換機上維護了6萬條LSA，路由震蕩頻發，一次收斂需要1到2分鐘。當時做了大量分析，花了幾個月時間對全網OSPF整體進行了優化，包括協議定時器的調整、各種路由匯總等，做完之后核心交換機LSA減少80%以上，接入層交換機路由條目減少90%，路由收斂時間降低一半且故障不再頻發。這里可以跟大家分享一下我們的經驗，如果用OSPF來做組網，服務器規模沒超過15萬臺前可以通過各種優化手段維持網絡穩定運行。超過15萬臺后就需要從架構和路由上進一步優化了。
數據測量
第三個階段我們在做數據測量，也是最近這一兩年我們的核心工作，此時的網絡里運行有大量的自研交換機和NFV，DCI網絡也有了一定的規模。右下角這張圖簡單描述了數據中心網絡的結構，包括數據中心核心、集群核心等。大家可以看到整個網絡里面，鏈路的數量非常多，如何知道每一條鏈路質量是什么樣的，幾乎是不可能的任務。再看上面那張圖，黑色的大點可以認為是三個核心節點，其他小的是分布在不同城市的數據中心。每個節點到數據中心之間實際有幾十條物理鏈路互聯，兩個數據中心間路徑有上萬種組合。在這種規模的網絡中人工快速定位某條鏈路丟包幾乎不可能，但這又是必須要做的事情。
面對了很多因規模問題造成的困難后，我們提出一個解決問題的思路，測量-優化-評價。
首先想辦法測量你需要的數據，比如網絡丟包率、時延抖動。拿到數據以后去做網絡架構或測量方法的優化，同時建立評價體系去看是否已經優化的足夠好。不斷的重復測量、優化、評價這個過程，直到數據滿足業務要求。
舉一個具體的例子，某數據中心出口有兩條鏈路，主用的一條是時延較低，另外一條平時備份。從圖里可以看到網絡正常時延大概是在23毫秒左右，在故障的瞬間時延飆升，綠色曲線是網絡中默認QoS等級的服務，故障更早影響到了這個隊列。恢復期間也發生過幾次鏈路切換，時延有抖動。當每一次抖動都是可以具體量化的時候，就可以輕松判斷出來故障對業務有什么樣的影響，乃至不同服務等級的業務能感知到什么現象。
網絡質量監控的例子是我們內部協作的一種方法，即運維團隊不直接開發，和開發團隊一起協作達成目標。在網絡質量監控項目中，網絡工程師翻閱大量業界和學界的論文進行調研，向開發團隊提出需求、給出測量方法、指導網絡部署方案。開發工程師則聚焦在怎樣去實現這種高并發的測量，如何用合適的算法計算具體哪些物理鏈路有影響，以及如何將最終結果呈現出來。***這套監控系統除了能呈現整體丟包率和時延外，還可以通過端到端的測量，從數十萬種鏈路組合中直接定位到發生丟包的是哪一條鏈路后節點。
能力建設
2016年我們關注的方向叫網絡能力建設，為了進一步提高運維能力，縮短網絡能力落地周期，運維團隊開始轉向DevOps。網絡最基本的能力是路由轉發，除此以外DIFFSERV、流量調度、快速故障恢復是等能力。這些能力之前或者缺失或者分散在不同系統里，現在我們來填補空白同時整合能力。網絡工程師要做的是去開發與業務邏輯強相關的內容，比如怎樣做流量調度，怎么去做故障切換等。像ODL框架在線上應用的性能問題、容災能力等問題則由開發團隊去解決。
談到NetDevOps就有必要提下SDN。我們所理解的SDN是指在數據基礎上根據策略執行動作，從而干預網絡。
首先先看左邊的圖，兩個數據中心間通信，常態下路由協議會幫你計算出來他們之間的訪問路徑，但當帶寬突然少了四分之三，網絡嚴重擁塞時應該怎么辦?
我們的解決方案是網絡工程師自己開發BGP控制器， 通過干預BGP屬性和路由，在整個核心網的范圍內疏導流量。開發控制器本身并不算非常復雜，更有挑戰的是落地過程中遇到的大量需要網絡工程師處理的細節，比如如何發現流量擁塞出現，如何選取調度路徑，網絡架構在非穩態下是否會造成調度失效，各個核心節點下發路由的順序應該如何，哪些流量可以做調度，調度引入的時延增長是否會影響業務等等。這些細節需要網絡工程師一點一點的去分析琢磨。
另一個是即將落地的項目，網絡集群自動故障隔離。右圖是一個CLOS網絡，spine-leaf中間的連線可以多達上萬條。這個項目的目標是當監控發現一組spine出現異常時，可以自動隔離故障區域。技術實現方面基于ODL整合監控和策略執行動作。這里有個特別的地方，是把現場操作工程師作為SDN的一個組件插入到流程里面，包括自動下發工單，提供清晰的操作指引和自動驗證能力，反饋操作結論到流程等。這樣爭取在網絡工程師不介入的情況下，做到故障自動隔離和恢復。
DevOps知易行難，轉型從鋪墊到落地，花了大概1年半時間。
以前百度網絡工程師主要來自銀行、運營商和互聯網企業，這些工程師有豐富的網絡設計運維經驗;校招的學生很多還沒畢業就拿到了CCIE證書，了解網絡協議和設備。但是這個團隊里沒有人是非常擅長coding的。為了進一步提高運維能力，縮短網絡能力落地周期，在這種背景下我們開始了DevOps轉型。配合轉型，從管理策略到團隊協作模式都需要做出相應調整。
- 首先管理策略上要發生變化，明確告訴大家除了深度了解路由協議和網絡架構設計外，轉向DevOps是職業發展的一個好的方向。
- 第二個是成員轉型意愿非常強烈。尤其是入職一年兩年左右的同學，因為招到的人本身素質非常好，都是來自于重點高校計算機或通信專業，本身有一定 coding 基礎，進一步提升 coding能力并不是非常困難的事情。這樣經過一年的培養和鍛煉，我們終于有了一些能coding 的CCIE!
- 第三個難點是理清和其他團隊的關系。特別是運維平臺研發團隊，要分清哪些是網絡工程師應該做的，哪些是適合研發團隊做的。網絡工程師擅長的領域在設備、協議和業務邏輯，但涉及到平臺級開發、算法優化等方面時，需要研發團隊來一起實現。以前的合作模式是網絡運維工程師提需求，現在的合作模式是網絡運維和開發團隊是一個聯合開發團隊。
- 第四個是教練式輔導。讓網絡工程師寫程序在起步階段最難，我們聘請了資深的研發工程師對網絡工程師從設計思想、實現方案到開發規范全方位輔導，大幅降低學習成本。
總結
這些年百度網絡運維思路和方法論上不斷進行著變革，應急搶險、局部優化、數據測量、能力建設，這四個階段也是方法論的不斷轉變的過程。在這個過程中，我們看到網絡工程師的工作重心在不斷調整，工作成績和個人價值在也在不斷提高。期待通過DevOps和自動化釋放更多網絡工程師的能量，在技術和個人成長方面取得突破，對業務發展提供更多幫助。希望百度的經驗對大家有所幫助，期待與各位更多的交流。
