致運維——運維軍團告訴你如何走過七年之癢

七年多的成長，從最初2～3人小分隊到日益壯大的運維軍團，發展至今已是一個集系統、開發等運維崗位的綜合職能中心。我們也創造了多個專案自研技術包括開源專案以及核心運維應用等。例如自建CDN系統、網路分析預警平臺、運維自動化平臺等。這一切果實的背後少不了風雨洗刷和烈日暴曬，每一次痛癢都是通往成熟的養分。

發展至今，我們團隊業務現狀大體概況如下所示。

七年，一個據說會癢的數字，愛情有七年之癢，團隊也有七年之癢，其實，“癢”一直都在，挺過去就是新生。

遙想7年前， 那是一個 “赤膊上陣、鑽木取火”的時期：大量的手動、人工作業；整體運維複雜度也不高，可替代性強。沒有海量、高併發的運維場景，自然也沒有應對高併發的概念。

公司正值創業初期，技術的職能分工還不明確，運維還沒有專職，一些碎片式的運維工作例如機器配置、擴容、維護更新，都是開發兼職。

如果要問運維是幹嘛的？當時大家的回答應該是修電腦的。。。

公司主站當時已經有一定使用者積累，需要大量的伺服器和頻寬來支撐網站運營。於是運維場景開始誕生：大概有100臺伺服器，由2-3人專職。

由於cdn技術在當時發展還不夠成熟，還沒有邊緣節點cache、中間層、源站的概念。我們的頁面、資源伺服器是作為單個節點存放靜態資源直接面向用戶訪問。 由於整體頻寬量大，單機最高頻寬峰值500M（可能現在大家覺得500M不算什麼，可在當時那會兒一家中小型做ISP接入的idc公司總出口頻寬實際也才500M不到），於是我們開始採用dns輪詢作為最原始的負載均衡技術來承載海量頻寬請求帶來的壓力。原始架構場景就在這時候基本定型下來，既簡單又實用，也和boss的理念相得益彰。

但隨著業務發展，這個原始架構也帶來了一些問題：

1）dns輪詢不均；

2）零自動化；

3）磁碟故障率高；

4）監控不成熟；

5）內部協同靠“喊”，檔案傳承意識薄弱。

那時候100多臺的伺服器節點，當時還沒有在Windows下形成比較好的業務層監控系統，只能一個個資源去下載撥測。更讓人吃驚的是我們的領導之一，時常也會深入一線業務，孜孜不倦地對100多臺伺服器、數十萬個資源下載點進行人肉撥測，而且總能發現一些故障點以及問題改進方法，作為一個擁有運維背景的leader，這一份深入業務的鑽研精神令所有運維人都甘拜下風。 

領導者的行為比語言更重要，正是leader這份以身作則、堅持修煉運維領域的精神，在我們軍團內部得以流傳，一直被視為新進人員的傳教模範。

這個時期的整體大環境，技術資源確實比較匱乏、運維相關資料也寥寥無幾、甚至連熟悉linux系統的人都不多。加上整個團隊正處在野蠻生長的幼年時期，運維理念、經驗都比較零散，沒有形成成熟的知識體系。

縱使存在種種問題種種難關，踩過無數的坑，也總有那麼幾次會懷疑運維的人生是否灰暗：沒有自動化的實現，沒有完善的技術體系，難道運維的宿命就是敲著鍵盤的IT民工？但合則同謀，所幸的是，團隊還是聚集了志同道合的一批人，始終堅守運維理想。處於原始時代的我們一起堅守著，在團隊成員分佈於各個工作室的情形下，依然把戰鬥力提升上去了。

2010年開始，Linux開源工具開始嶄露頭角。 監控、自動化、批次管理等等在行業內都逐步開始有了成熟的解決方案。

我們開始擁抱Linux開源，把開源工具逐步應用到生產環境。 lnmp基礎環境、shell自動化、nagios、cacti、puppet、salt、ossec等等這些工具都開始慢慢成了標配。

“黑貓、白貓，能抓到老鼠就是好貓”。雖是草莽出身、沒有華麗的理論包裝，也不糾纏於每一個技術的底層原理，但我們必須要把技術轉換成生產力。滿足業務需求、解決業務場景中的實際問題才是最核心的結果導向。

這個時期，整個頁遊市場如雨後春筍般迅速崛起，從研發到運營形成了一個自產自銷的頁遊產業鏈。 一直到2012年，迎來了到迄今為止頁遊最巔峰的時代。

這是一個全新的行業領地，業務場景和需求都在不斷變化。對運維來說，也是在探索期，沒有前人的經驗可以借鑒，也沒有一成不變的樣式。只有摸著石頭過河，在工作中慢慢琢磨，朝著結果導向步步為營，逐步進攻。

當時公司頁遊主要分成開服型遊戲、大世界遊戲。兩種遊戲型別特點不一，隨著巔峰時代業務爆髮式的增長，都給運維帶來了巨大的衝擊和挑戰。

群集開服力輓狂瀾

這些問題如果用今天雲時代的思路來審視， 可能大家會覺得是很小兒科的問題，用虛擬化之類的方案就可以解決。我們當時也考慮過用虛擬化如Xen，但由於方案不夠完善在實踐過程中也暴露了不少缺點。一方面是物理機虛擬化帶來的硬體效能損耗，例如虛擬網絡卡丟包、虛擬機器磁碟iops搶佔互斥等等。另一方面虛擬化帶來的資源復用還不足夠高，基於開服的自動化支援也不夠完善。

“能否用更高的硬體配置來換取單伺服器部署更多的區服，以最大化提高物理機器的資源復用？”這是群集開服架構最開始的念頭。隨著在業務場景中的檢驗和論證，群集開服架構這個時候逐步完善併成型。

群集開服架構裡是以單個遊戲服邏輯行程作為叢集的子單元，多個子單元集中在一個物理伺服器裡；這樣可以充分利用單臺物理伺服器的處理能力。同時搭載我們自研的遊戲運維統一管理後臺做群集開服的統一智慧排程，提高伺服器叢集架構的高可擴充套件能力，打破了以往一個服一組機器的樣式。

群集開服架構圖

開服樣式效能比對圖

啟用群集開服架構後，單群集組機開服最少比例為：1:15（百分比越低效能越高）；開服效率大大提升，成本降低也超過一半以上，這得益於群集開服架構對資源的充分利分。

大世界遊戲和傳統的端遊有點類似。 開發跟據需求設計了遊戲的內部架構。

不同的遊戲行程模組化區分：如gateway（閘道器）、gameserver (主遊戲邏輯)、login（登入）、聊天、DB儲存等等提供遊戲內不同的功能服務。

不同的服務模組設計初期要求叢集化的思路：即分散式擴充套件、負載均衡、故障轉移這些都是標配。

運維需根據不同的服務模組，做伺服器相應的硬體配置選型。如gameserver 一般為cpu密集、 gateway主要網絡卡密集（軟中斷壓力）、DB一般是IO密集。

跟端遊錶面區別是 ，使用者入口由以前的客戶端變成了web網頁端。

大世界架構圖

隨著使用者的爆髮式增長、系統訪問量的增加，高併發的使用者請求、海量的資料儲存，變成了最大的技術挑戰。

資料庫壓力：儲存量到T級，DB伺服器IOPS吞吐高到萬級。資料庫儲存和壓力是當時最大的難題。

使用者量級到了10W級，遊戲玩家分佈全國各地，加上國內網路錯綜複雜。會存在因為種種網路問題導致部分玩家連不上游戲gateway的的埠。

為此與客戶端程式員一起討論研究瞭解決方案，並測試了方案的可行性。

bgp轉發邏輯圖

找一臺優質網路的BGP機房的中轉伺服器，做tcp轉發。結合客戶端的邏輯判斷處理 如果玩家連線不上游戲服gateway的埠則嘗試重連。 即嘗試重連bgp中轉，以增大遊戲聯通率。

那個時候還沒有apm的概念，但是由於玩家量級大，大世界遊戲模組結構相對複雜。 

玩家到遊戲的整個邏輯互動過程 都發生了什麼？ 每個邏輯互動的步驟 能否把過程資料化、透視化？

於是後臺統計的做法：跟客戶端研發協商，把遊戲內部的邏輯互動埋點打日誌，透過介面統一上報至APM後臺，APM後臺主要做web視覺化呈現。

由於業務在這兩年裡飛速增長，經營樣式從原始時代的簡單粗放調整最佳化成系統化的架構管理。這一切看起來可以恣意調整、修改，改變架構的成本似乎相當低；現實卻不是這樣，在實際攻剋架構轉變的過程中有些問題會在你想象不到的地方冒出來，死死拖住你。這是一個開始半自動化的工具年代，頁遊巔峰時期攻剋的不僅僅是以上架構調整的難關，還有一些運維管理後臺系統也開始逐步建立起來。

2013年是遊戲行業風雲變幻的一年，源於手機功能和移動網際網路的發展，手遊行業從“屌絲”瞬間華麗升級為“土豪”，這一顛覆的轉變只用了一年的時間，這也是遊戲行業未來的一個藍海，但無數同行卻撐不過“黎明前最黑暗最黑暗的那一刻”。如此的轉變將無疑改變了運維開服的架構規劃，手遊與頁遊在系統設計架構上本就有著明顯的區別。

2013年無疑是一個值得紀唸的時期，也是我們團隊歷經變革的一個轉折點。如果說一個人的改變是憑著毅力和努力，那麼一個部門的轉變，則是憑著團隊所有人的凝聚力和執行力。

同年6月正式成立了運維中心職能部門，首當其衝的是要整合原本分散的、各自一套的、不統一不規範的運維工作流程，SOP體系因此應運而生；其次是開發與運維關係的轉變，要實現D/O分離與協作；再者，為了“精益求精”，實現運維大資料、運維自動化的戰略，以便解決業務快速迭代導致人力、成本提升帶來的困擾，我們成立了《運維開發部》，兩年時間裡，開發了藍海系統（運維開服自動化）、CDN統一管理平臺、公有雲平臺等一系列運維自動化後臺。

我們把日常工作的經驗和技術碎片彙整合規範、流程，形成能夠快速迭代、實現統一管理的方法論。

“D/O分離與協作”是指開發與運維分離，相互之間不幹擾，各自負責各自的業務需求，主要是能做到許可權管理上的獨立管理。然而在一個共同維護的業務環境下，運維與開發之間依然是要相互配合以實現業務需求導向，共同完成任務。協作既不與分離原則相抵觸，又可增進運維與開發之間的默契。最大的好處在於能提升生產效益，這也是未來運維服務化的一個標的理念。

眾所周知，運維是公司產品線上運營的核心技術部門，在滿足產品快速迭代規模迅速擴張的要求下，從早期的人肉執行原始時代，發展到今天的運維自動化、平臺化的時代，經歷了無數的苦逼與辛酸，在這個過程中運維也積累了很多專案管理經驗以及自動化運維技術，隨著技術的更新和業務的發展，我們重新定位了需求，以自助化、自動化、定製化為核心思想打造了一個全新的平臺——《藍海系統》。另外我們建立了完善的運作體制，在業務當中開發技術與運維技術需要做到很好的銜接，從而明確上線的操作規範，相互配合協同。到未來我們希望提供的不再只是基礎的運維交付能力，而是更契合業務的運維服務化、高度自助化。

CDN專案成立之初，我們遵循的是簡單高效的管理方式，寫了大批次的指令碼來實現各個域的頻寬檢測、呼叫檢測、排程最佳化、批次更新和內容推送掃清管理等功能，後來業務場景需要慢慢對外，就開始了初步的cdn後臺開發，提供簡單的內容管理功能。隨著我們業務規模的擴大以及視野的開拓，我們需要讓後臺功能更加的透明化，視覺化，分析可以更加的細膩(顆粒度)，把它當成一個對外產品，可以持續地進行交付。這個產品分為前後端，後端由運維進行日常維護，前端交由使用者使用，到現在系統運維申請CDN已經實現完全自助化。

後端管理介面

前端介面

CDN後臺要做到更小的顆粒度，就離不開原始日誌，而對於一個龐大的CDN系統來說，這個日誌量是海量的，我們在日誌管理方面採取了ELK（ElasticSearch、Logstash、Kiabana）+redis的架構，目前日誌插入量高峰達到70K/s，每天20-40億條的資料已經成為了我們CDN後臺從簡單的日誌統計到現在的大資料分析轉換的基石。

當然在搭建整套系統的過程當中也遇到不少的坑：

大資料日誌架構參考圖

公有雲平臺立項之初，其實是一臉懵逼的，部門在前期並沒有做過一些技術儲備，而網上一波流的雲技術，但是實際上很少公司會自建雲應用在大規模生產環境。大部份還是所謂技術牛人的“實驗室環境”。但是說做就做，我們從部門中抽調了8名精英利用了不到一年的時間完成了這個專案—— 藍雲BlueCloud。在建立之初我們針對了各大雲架構進行了對比，最後選用的方案是OpenStack，因為OpenStack擁有優秀強大的社群，而且最重要的是它以python語言為主的開源框架，我們可以很方便地實現二次開發。

一開始搭建基礎系統時，遇到了很多技術問題，尤其是作為雲底層的儲存系統。我們先給它設一個小標的：實現150個實體，執行1500個遊戲服。在有限的條件下保證最基本的IO讀寫能力。我們的儲存架構簡單粗暴，沒有什麼萬兆網絡卡，萬兆光纖交換機，全系列SSD硬碟啥的！領導的指示是“你只能使用原始的SAS萬轉硬碟，千兆網路……”，對於要支撐150個實體來說，這“家產”簡直屬於貧困戶。沒辦法，領導的指示下來，只能使出渾身解數搞技術突破了。我們雲團隊花了大量的時間在研究和測試儲存的最合理方案，終究還是憑著堅持的毅力創造出了我們的孩子。

儲存方面，我們使用openstack的好伴侶，大ceph分散式儲存系統。ceph的出現就是衝著openstack來的，他能夠與openstack實現無縫的對接。效能嘛！那得見仁見智了。

我們最終的測試結果（單節點）:

或許有同學會發表疑問：“對於一個計算節點來說，這資料也並沒有什麼大不了的，甚至比單機Raid10的效能還差。” 對的，但是不要忘記這是分散式儲存，它有著高可用性和高擴充套件能力，還可實現線上無縫熱遷移。

如果只是搞一批Raid10的本地儲存伺服器作為計算節點，那玩的只能算是虛擬化，並不是“雲”。

細心的同學還會發現，由於我們使用的只有千兆網路，理論最大的吞吐能力只有128M/s（無損極限）。但是測試結果”寫入“卻有220M/s，這是為什麼？

這是因為使用了雙網絡卡系結（Bounding）技術，利用多個網絡卡做流量合併，但這僅僅只有寫入（即接收資料）的情況才能實現，讀取（即傳送資料）時只能保持千兆不變。這也是Bounding技術的一個特性，目前還沒有找到解決辦法。另外要實現以上結果我們還做了一件事，就是把雙SAS萬轉硬碟做成Raid0作為ceph的一個OSD節點，提升其寫入能力。這裡我們並不擔心Raid0本身的風險，因為ceph本身就是一個含有多副本的高可用儲存（至少設定了3份副本），即使某個OSD節點的Raid0出現故障，並不影響到全域性執行。

方案總結（測試環境）：

平臺：ceph v0.89

網路：雙1G Bounding (RX=2G,TX=1G)

裝置：SAS-600G Raid0（IOPS=2~3W,W=400M/s）

副本：3份

節點：12個

上層業務決定基礎設施需要足夠的靈活性，為了滿足數十款爆款專案的上線快速部署、遷移等，需要對基礎資源進行高效管理和容災容錯能力。雲端計算可以從容應付這種“快部署快回收”的應用場景，還可以整合底層物理資源，充分發揮每個獨立單元的效能，從而能夠靈活分配和管理業務。因此搞“雲”是志在必行的事了。

雲平臺（前端介面）

雲端計算時代給大家帶了很多機遇，同時也帶來了很多挑戰，也讓運維從業人員開始思考很多問題。

這是一個解凍時代，怎麼突破重圍、與時俱進，怎麼在手遊行業一展身手，利用手遊趨勢去改造去升級團隊。從外人的角度來看，這或許很正常，是轉型必經的陣痛。但從一個團隊創始人的角度看，從原始兩三個人沒有槍的時代一路拼殺，其中經歷了多少不為人知的崎嶇艱辛。

運維服務化、平臺產品化，這是2015年就開始醞釀的想法，只是今年思路才慢慢地越來越清晰起來，知道要做哪些事情，如何去做。縱觀整個時間軸，我們會發現從當中的一些問題，有些是值得我們運維人員深思的地方。現在的網際網路已經不比以前了，前面提到2009年當時懂linux的是很稀缺人才，而且網際網路上的資料都很少。但是現在7年過去了，各種公有雲、各種開源軟體、各種服務整合商，幾乎你能想到的知識點和服務都能在網際網路上獲取到。一些底層的基礎技術全面自動化，這很大程度降低了對運維的依賴。

「雲的誕生把一些基礎運維的服務整合，徹底公有化，基礎運維就變得像水和電一樣無處不在。」

在平臺化高度整合的今天我們遇到的困境並不是以“技術為導向”了，那麼我們的價值在哪？前路在哪？ 

唯一的出路就是“影響業務、創造口碑、創造價值”，而這從運維的角度來看，我們充分利用現有基礎資源和業務特性，從被動的運維服務轉向主動的運維服務。尤其是我們的很多技術思維必須轉變成服務思維，從技術運維升級到服務運維，更加強調是業務交付能力，我們要更懂業務。自身的技術修養，要轉換成生產力，要轉換成我為公司做多大的貢獻。

服務化的前提，就是能後臺化的工作要儘量全部後臺化，後臺對外的視覺化、功能自助化。對內的可配置化是核心原則、後臺各項的服務閉環是基本原則。

我們在修煉業務的同時，軟實力也要跟著提升上來。運維的危機感從來都不會離去，我們只有擁抱變化，不斷的做自我調整，才會有一席生存空間，才會得到更多人的認可。 

運維新時代——智慧服務化，我們只能破繭重生，尋找新的徵程和領地。我們的境地就像一群在豬圈裡的豬，有一天豬圈會停止投放飼料了，飼料就只有那麼多，馬上就快吃完了，我們可能會餓死。所以我們得提前想辦法長出一雙翅膀變成一隻會飛的豬，飛出去找到新的領地找到飼料吃，或許一隻特立飛行的豬才有一席之地。而運維服務化就是我們的翅膀，我們運維人不應該是配角是附屬的，透過運維服務化建設，未來我們是主角，有一天可以站在舞臺的中央享受掌聲、享受榮耀！

作者 | YW原創   來源 | 運維軍團   ID | ywjtshare

《Linux雲端計算及運維架構師高薪實戰班》2018年03月26日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~

*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。

– END –

更多Linux好文請點選【閱讀原文】哦

↓↓↓