致運維——運維軍團告訴你如何走過七年之癢
前言
七年多的成長，從最初2～3人小分隊到日益壯大的運維軍團，發展至今已是一個集系統、開發等運維崗位的綜合職能中心。我們也創造了多個項目自研技術包括開源項目以及核心運維應用等。例如自建CDN系統、網路分析預警平台、運維自動化平台等。這一切果實的背後少不了風雨洗刷和烈日暴晒，每一次痛癢都是通往成熟的養分。
發展至今，我們團隊業務現狀大體概況如下所示。
1. 管理 萬級 伺服器。
2. 管理 百 + 遊戲項目。
3. 自建CDN平台承載能力達 T級。
在自建自用領域是業界領先水平，響應能力甚至可以媲美商用CDN
4. 遊戲業務單服在線 萬級。
這樣的量級並不能與單純的web業務來比，遊戲app的運行比web複雜的多。考驗運維的重點在資料庫架構和高可用性能方面的優化管理能力。
七年，一個據說會癢的數字，愛情有七年之癢，團隊也有七年之癢，其實，「癢」一直都在，挺過去就是新生。
運維時代
時勢造英雄，感恩環境、感恩和團隊成長的所有成員。我們從鑽木取火到石器時代，再到自動化和服務化。
一、原始時代 —「守」
（2008-2009）
遙想7年前， 那是一個 「赤膊上陣、鑽木取火」的時期：大量的手動、人工作業；整體運維複雜度也不高，可替代性強。沒有海量、高並發的運維場景，自然也沒有應對高並發的概念。
公司正值創業初期，技術的職能分工還不明確，運維還沒有專職，一些碎片式的運維工作例如機器配置、擴容、維護更新，都是開發兼職。
如果要問運維是幹嘛的？當時大家的回答應該是修電腦的。。。
1 主站資源運維——為伺服器而生
公司主站當時已經有一定用戶積累，需要大量的伺服器和帶寬來支撐網站運營。於是運維場景開始誕生：大概有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-2012）
2010年開始，Linux開源工具開始嶄露頭角。 監控、自動化、批量管理等等在行業內都逐步開始有了成熟的解決方案。
我們開始擁抱Linux開源，把開源工具逐步應用到生產環境。 lnmp基礎環境、shell自動化、nagios、cacti、puppet、salt、ossec等等這些工具都開始慢慢成了標配。
「黑貓、白貓，能抓到老鼠就是好貓」。雖是草莽出身、沒有華麗的理論包裝，也不糾纏於每一個技術的底層原理，但我們必須要把技術轉換成生產力。滿足業務需求、解決業務場景中的實際問題才是最核心的結果導向。
1. 頁游巔峰
這個時期，整個頁游市場如雨後春筍般迅速崛起，從研發到運營形成了一個自產自銷的頁游產業鏈。 一直到2012年，迎來了到迄今為止頁游最巔峰的時代。
這是一個全新的行業領地，業務場景和需求都在不斷變化。對運維來說，也是在探索期，沒有前人的經驗可以借鑒，也沒有一成不變的模式。只有摸著石頭過河，在工作中慢慢琢磨，朝著結果導向步步為營，逐步進攻。
當時公司頁游主要分成開服型遊戲、大世界遊戲。兩種遊戲類型特點不一，隨著巔峰時代業務爆髮式的增長，都給運維帶來了巨大的衝擊和挑戰。
1.1 開服型遊戲
初期是傳統運維的模式，單元開服型給團隊帶來的內耗相當大。
特點：
1）多平台聯運模式，開服頻率高。
如一爆款遊戲高峰期間，單平台單日最高開服2-3個，單日總開服數高達200個
2）此消彼長：新服開啟，老服在線和留存迅速下降，合服速度相對較慢
3）用戶分布複雜度高、攻擊頻繁
群集開服力挽狂瀾
基於開服型遊戲的特點，如果按照傳統運維，開一個服提供一組機器的思路，會導致以下問題：
複雜度高、效能低下——高頻率的開服需求
資源冗餘，嚴重浪費——新服開啟、老服在線下滑，大量的老服、死服佔用機器資源
維護久、內耗大——針對區服遷移做硬體整合的需求（俗稱硬合服）
這些問題如果用今天雲時代的思路來審視， 可能大家會覺得是很小兒科的問題，用虛擬化之類的方案就可以解決。我們當時也考慮過用虛擬化如Xen，但由於方案不夠完善在實踐過程中也暴露了不少缺點。一方面是物理機虛擬化帶來的硬體性能損耗，例如虛擬網卡丟包、虛擬機磁碟iops搶佔互斥等等。另一方面虛擬化帶來的資源復用還不足夠高，基於開服的自動化支持也不夠完善。
「能否用更高的硬體配置來換取單伺服器部署更多的區服，以最大化提高物理機器的資源復用？」這是群集開服架構最開始的念頭。隨著在業務場景中的檢驗和論證，群集開服架構這個時候逐步完善並成型。
群集開服架構里是以單個遊戲服邏輯進程作為集群的子單元，多個子單元集中在一個物理伺服器里；這樣可以充分利用單台物理伺服器的處理能力。同時搭載我們自研的遊戲運維統一管理後台做群集開服的統一智能調度，提高伺服器集群架構的高可擴展能力，打破了以往一個服一組機器的模式。
群集開服架構圖
架構優點
1 在線負載性能提升——高配伺服器同時滿足IO密集 cpu性能，足夠支持2個以上新服
2 伺服器壓力減少——合理的利用WebGame開服此消彼長的特點，新服開啟時老服在線下降
3 開服效率大大提高——無需為新服另外準備硬體配置環境，結合遊戲運維統一管理後台的一鍵開服即可高效滿足開服需求
4 節省維護時間——無需硬合服，維護內耗降低，提高線上業務的穩定性
5 可複製性高——可以大面積推廣應用、擴展性強
6 硬體及IDC支出成本降低——大大減少伺服器的採購數量
開服模式效能比對圖
啟用群集開服架構後，單群集組機開服最少比例為：1:15（百分比越低效能越高）；開服效率大大提升，成本降低也超過一半以上，這得益於群集開服架構對資源的充分利分。
1.2 大世界遊戲
大世界遊戲和傳統的端游有點類似。 開發跟據需求設計了遊戲的內部架構。
不同的遊戲進程模塊化區分：如gateway（網關）、gameserver (主遊戲邏輯)、login（登錄）、聊天、DB存儲等等提供遊戲內不同的功能服務。
不同的服務模塊設計初期要求集群化的思路：即分散式擴展、負載均衡、故障轉移這些都是標配。
運維需根據不同的服務模塊，做伺服器相應的硬體配置選型。如gameserver 一般為cpu密集、 gateway主要網卡密集（軟中斷壓力）、DB一般是IO密集。
跟端游表面區別是 ，用戶入口由以前的客戶端變成了web網頁端。
大世界架構圖
隨著用戶的爆髮式增長、系統訪問量的增加，高並發的用戶請求、海量的數據存儲，變成了最大的技術挑戰。
資料庫壓力：存儲量到T級，DB伺服器IOPS吞吐高到萬級。資料庫存儲和壓力是當時最大的難題。
1 硬體調優：升級磁碟的raid陣列、更換ssd 換取更高性能的iops吞吐
2 系統層調優： mysql配置my.cnf、內核調優、文件系統 。 這些是標配，但杯水車薪
3 業務邏輯方面：分庫 按照業務邏輯水平橫向切分 ； 分表 日期切表或遞增切表
4 中間件緩存： mysql前端加redis做緩存， redis做主從。主庫純內存儲備、不落地。 從庫用於備份，aof策略落地。
2. 網路優化-BGP中轉重連
用戶量級到了10W級，遊戲玩家分布全國各地，加上國內網路錯綜複雜。會存在因為種種網路問題導致部分玩家連不上遊戲gateway的的埠。
為此與客戶端程序員一起討論研究了解決方案，並測試了方案的可行性。
bgp轉發邏輯圖
找一台優質網路的BGP機房的中轉伺服器，做tcp轉發。結合客戶端的邏輯判斷處理 如果玩家連接不上遊戲服gateway的埠則嘗試重連。 即嘗試重連bgp中轉，以增大遊戲聯通率。
3. APM性能監控
那個時候還沒有apm的概念，但是由於玩家量級大，大世界遊戲模塊結構相對複雜。
玩家到遊戲的整個邏輯交互過程 都發生了什麼？ 每個邏輯交互的步驟 能否把過程數據化、透視化？
於是後台統計的做法：跟客戶端研發協商，把遊戲內部的邏輯交互埋點打日誌，通過介面統一上報至APM後台，APM後台主要做web可視化呈現。
由於業務在這兩年里飛速增長，經營模式從原始時代的簡單粗放調整優化成系統化的架構管理。這一切看起來可以恣意調整、修改，改變架構的成本似乎相當低；現實卻不是這樣，在實際攻克架構轉變的過程中有些問題會在你想像不到的地方冒出來，死死拖住你。這是一個開始半自動化的工具年代，頁游巔峰時期攻克的不僅僅是以上架構調整的難關，還有一些運維管理後台系統也開始逐步建立起來。
三、解凍時代 —「轉」
（2013-2015）
2013年是遊戲行業風雲變幻的一年，源於手機功能和移動互聯網的發展，手遊行業從「屌絲」瞬間華麗升級為「土豪」，這一顛覆的轉變只用了一年的時間，這也是遊戲行業未來的一個藍海，但無數同行卻撐不過「黎明前最黑暗最黑暗的那一刻」。如此的轉變將無疑改變了運維開服的架構規劃，手游與頁游在系統設計架構上本就有著明顯的區別。
2013年無疑是一個值得紀念的時期，也是我們團隊歷經變革的一個轉折點。如果說一個人的改變是憑著毅力和努力，那麼一個部門的轉變，則是憑著團隊所有人的凝聚力和執行力。
同年6月正式成立了運維中心職能部門，首當其衝的是要整合原本分散的、各自一套的、不統一不規範的運維工作流程，SOP體系因此應運而生；其次是開發與運維關係的轉變，要實現D/O分離與協作；再者，為了「精益求精」，實現運維大數據、運維自動化的戰略，以便解決業務快速迭代導致人力、成本提升帶來的困擾，我們成立了《運維開發部》，兩年時間裡，開發了藍海系統（運維開服自動化）、CDN統一管理平台、公有雲平台等一系列運維自動化後台。
1. SOP體系 標準化
我們把日常工作的經驗和技術碎片彙集成規範、流程，形成能夠快速迭代、實現統一管理的方法論。
2. D/O 分離與協作
「D/O分離與協作」是指開發與運維分離，相互之間不干擾，各自負責各自的業務需求，主要是能做到許可權管理上的獨立管理。然而在一個共同維護的業務環境下，運維與開發之間依然是要相互配合以實現業務需求導向，共同完成任務。協作既不與分離原則相抵觸，又可增進運維與開發之間的默契。最大的好處在於能提升生產效益，這也是未來運維服務化的一個目標理念。
3. 藍海系統 自助自動化時代
眾所周知，運維是公司產品線上運營的核心技術部門，在滿足產品快速迭代規模迅速擴張的要求下，從早期的人肉執行原始時代，發展到今天的運維自動化、平台化的時代，經歷了無數的苦逼與辛酸，在這個過程中運維也積累了很多項目管理經驗以及自動化運維技術，隨著技術的更新和業務的發展，我們重新定位了需求，以自助化、自動化、定製化為核心思想打造了一個全新的平台——《藍海系統》。另外我們建立了完善的運作體制，在業務當中開發技術與運維技術需要做到很好的銜接，從而明確上線的操作規範，相互配合協同。到未來我們希望提供的不再只是基礎的運維交付能力，而是更契合業務的運維服務化、高度自助化。
4. CDN統一管理平台
CDN項目成立之初，我們遵循的是簡單高效的管理方式，寫了大批量的腳本來實現各個域的帶寬檢測、調用檢測、調度優化、批量更新和內容推送刷新管理等功能，後來業務場景需要慢慢對外，就開始了初步的cdn後台開發，提供簡單的內容管理功能。隨著我們業務規模的擴大以及視野的開拓，我們需要讓後台功能更加的透明化，可視化，分析可以更加的細膩(顆粒度)，把它當成一個對外產品，可以持續地進行交付。這個產品分為前後端，後端由運維進行日常維護，前端交由用戶使用，到現在系統運維申請CDN已經實現完全自助化。
後端管理界面
前端界面
CDN後台要做到更小的顆粒度，就離不開原始日誌，而對於一個龐大的CDN系統來說，這個日誌量是海量的，我們在日誌管理方面採取了ELK（ElasticSearch、Logstash、Kiabana）+redis的架構，目前日誌插入量高峰達到70K/s，每天20-40億條的數據已經成為了我們CDN後台從簡單的日誌統計到現在的大數據分析轉換的基石。
當然在搭建整套系統的過程當中也遇到不少的坑：
1、配置rsyslog的緩存隊列時，未區分main和action隊列，導致系統日誌積累
2、logstash處理邏輯過多，導致索引性能低下
3、salt經常發生節點無響應的情況、舊的salt因為消息中間件版本過低的原因丟失數據等
4、各頻道日誌數據過於龐大, 前端搜索耗時較長等等一系列的問題。
大數據日誌架構參考圖
5. 公有雲
公有雲平台立項之初，其實是一臉懵逼的，部門在前期並沒有做過一些技術儲備，而網上一波流的雲技術，但是實際上很少公司會自建雲應用在大規模生產環境。大部份還是所謂技術牛人的「實驗室環境」。但是說做就做，我們從部門中抽調了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個
上層業務決定基礎設施需要足夠的靈活性，為了滿足數十款爆款項目的上線快速部署、遷移等，需要對基礎資源進行高效管理和容災容錯能力。雲計算可以從容應付這種「快部署快回收」的應用場景，還可以整合底層物理資源，充分發揮每個獨立單元的性能，從而能夠靈活分配和管理業務。因此搞「雲」是志在必行的事了。
雲平台（前端界面）
雲計算時代給大家帶了很多機遇，同時也帶來了很多挑戰，也讓運維從業人員開始思考很多問題。
這是一個解凍時代，怎麼突破重圍、與時俱進，怎麼在手遊行業一展身手，利用手游趨勢去改造去升級團隊。從外人的角度來看，這或許很正常，是轉型必經的陣痛。但從一個團隊創始人的角度看，從原始兩三個人沒有槍的時代一路拼殺，其中經歷了多少不為人知的崎嶇艱辛。
四、重生時代——「新」
（2016至今）
運維服務化、平台產品化，這是2015年就開始醞釀的想法，只是今年思路才慢慢地越來越清晰起來，知道要做哪些事情，如何去做。縱觀整個時間軸，我們會發現從當中的一些問題，有些是值得我們運維人員深思的地方。現在的互聯網已經不比以前了，前面提到2009年當時懂linux的是很稀缺人才，而且互聯網上的資料都很少。但是現在7年過去了，各種公有雲、各種開源軟體、各種服務集成商，幾乎你能想到的知識點和服務都能在互聯網上獲取到。一些底層的基礎技術全面自動化，這很大程度降低了對運維的依賴。
「雲的誕生把一些基礎運維的服務整合，徹底公有化，基礎運維就變得像水和電一樣無處不在。」
在平台化高度整合的今天我們遇到的困境並不是以「技術為導向」了，那麼我們的價值在哪？前路在哪？
1. 實現平台化戰略
唯一的出路就是「影響業務、創造口碑、創造價值」，而這從運維的角度來看，我們充分利用現有基礎資源和業務特性，從被動的運維服務轉向主動的運維服務。尤其是我們的很多技術思維必須轉變成服務思維，從技術運維升級到服務運維，更加強調是業務交付能力，我們要更懂業務。自身的技術修養，要轉換成生產力，要轉換成我為公司做多大的貢獻。
服務化的前提，就是能後台化的工作要盡量全部後台化，後台對外的可視化、功能自助化。對內的可配置化是核心原則、後台各項的服務閉環是基本原則。
2. 提升軟實力
我們在修鍊業務的同時，軟實力也要跟著提升上來。運維的危機感從來都不會離去，我們只有擁抱變化，不斷的做自我調整，才會有一席生存空間，才會得到更多人的認可。
3. 特立飛行的豬——重獲新生
運維新時代——智能服務化，我們只能破繭重生，尋找新的征程和領地。我們的境地就像一群在豬圈裡的豬，有一天豬圈會停止投放飼料了，飼料就只有那麼多，馬上就快吃完了，我們可能會餓死。所以我們得提前想辦法長出一雙翅膀變成一隻會飛的豬，飛出去找到新的領地找到飼料吃，或許一隻特立飛行的豬才有一席之地。而運維服務化就是我們的翅膀，我們運維人不應該是配角是附屬的，通過運維服務化建設，未來我們是主角，有一天可以站在舞台的中央享受掌聲、享受榮耀！
作者| YW原創來源| 運維軍團ID| ywjtshare
TAG:運維派 |