第乙個是遊戲的需求。它表現為三個方面:
第二個是在硬體環境方面，主要表現為伺服器數量多、伺服器型號多。
因為公司從建立到現在有十幾年的時間了，在這個過程中分批、分期採購的伺服器幾乎橫跨各大oem廠商的各大產品線，型號多而雜。
最後是人的因素。我們在建設自動化運維體系過程中，有乙個比較重要的考慮點是人的因素。
如果大家的技術能力都很強，很多時候乙個人可以完成所有工作，可能也就不需要自動化運維體系了。
正是因為每個運維人員的能力不一樣，技術水平參差不齊，甚至是運維習慣和工具也不一樣，導致我們必須要建立一套規範的自動化運維體系，來提公升工作效率。
再看一下建設這套自動化運維體系的目標，也就是說我們的原則是什麼？
筆者將自動化運維體系的建設目標總結為四個詞。
說到自動化安裝，大家可能並不陌生，「兩多兩少」，型號多、作業系統多，但是人少，可用時間也比較少。
整個流程採用通用的框架，首先由pxe啟動，選擇需要安裝的作業系統型別（安裝windows或者linux），然後根據windows系統自動識別出需要安裝的驅動。伺服器交付使用者之前，會進行基本的安全設定，例如防火牆設定以及關閉windows共享，這在一定程度上提高了安全性，也減少了需要人工做的一些操作。如圖所示：
自動安裝流程圖
當伺服器由自動化安裝系統安裝完成以後，就會被自動化運維平台接管。自動化運維平台是運維人員的作業平台，它主要解決的問題就是因伺服器、作業系統異構而且數量特別多而帶來的管理問題。作業系統是五花八門的，我們在設計系統過程中考慮了以下幾個因素：
把整個系統的使用者介面設計成基於瀏覽器的架構。運維工程師無論何時何地都可以登入管理系統進行運維操作，這樣的話就比較方便。由octopod伺服器對被操作的機器發布指令。
統一管理異構伺服器。大家以前可能對windows深惡痛絕，其實windows也可以管得很好。我們使用開源的ssh方式管理windows，這樣就可以對系統進行批量的補丁更新，還可以做批量的密碼管理和操作。
充分利用現有協議和工具。這個平台的特點是所有的系統使用ssh管理，而不是自己開發一些agent，這也體現了自動化運維的觀點。
很多時候我們沒必要重新造輪子，即使自己造出一套客戶端的方法，大部分時候也並沒有在生產環境裡得到嚴格的驗證。
而ssh協議本身已經存在很多年了，而且已經在我司使用了很多年，該出的問題已經出了，相對於造輪子，使用ssh更加穩定，更經得起考驗，使用起來更方便。
如果這些檔案裡面出現病毒和木馬，將是一件很糟糕的事情，甚至會對業務和公司的聲譽造成惡劣影響。當這些檔案被發到玩家電腦上之前，必須經過病毒檢測系統檢測，確保它沒有被注入相應的病毒**。
再來看伺服器端，主要是通過安全掃瞄架構來保障安全。
安全並不是一蹴而就，一勞永逸的。如果不對系統持續地檢查、檢測、探測，那麼你的一些誤操作會導致系統暴露在網際網路上，或者是暴露在惡意攻擊者的眼皮之下。
通過一種主動、自發的安全掃瞄架構對所有伺服器進行安全掃瞄，就能在很大程度上規避這樣的問題。
舉乙個例子，去年我們遇到過乙個情況，某款交換機acl達到一定的數量的時候，就完全失效了。
如果沒有相關的配套機制去檢查和檢測，那麼你的伺服器、你認為保護得很好的埠或者是敏感的ip可能已經暴露。所以，通過這種主動的探測可以減少很多系統的或者是人為的安全問題。
這個特點對於我們構建這樣乙個分發系統提出了很大的挑戰。
第乙個挑戰就是在高峰時遊戲產生的頻寬可能達到數百gb。
第二是很多小運營商或者中小規模的運營商會有一些快取機制，這個快取機制如果處理得不好，會對業務造成影響，也就是非法快取的問題。
第三是關於dns排程的問題。
dns排程本身是基於玩家本身的local dns的機制解析的，會有排程不準確的問題。
第四是dns汙染，或者是dns ttl的機制導致排程不那麼靈敏和準確。針對這些問題，我們有下面兩套系統來解決。
剛才說到遊戲的週期性特點，就是平時頻寬不是很大，但是在某個節點的時候，或者是重大活動的時候，頻寬比較大。
如果自己構建一套cdn系統，可能不是很划算，所以我們引入國內多家比較大型的cdn廠商排程資源。我們通過302的方法排程，而不是把網域名稱給其中一家或幾家。
因為直接使用cname的話很難按比例排程，特別是頻寬大的時候，一家cdn廠商解決不了，或者是一家發生區域性故障，需要快速切除。
第二套是dorado系統。剛剛講到小運營商或者某些運營商的非法快取機制會對業務造成影響，那麼對於某些關鍵的檔案，如果快取的是乙個舊版本，可能會造成很大的問題。比如我們的區服列表，如果我們伺服器端增加了新的區服，在客戶端沒有顯現出來，就導致玩家沒有辦法進入到新的區服去玩。
針對這些問題，我們設計了內部代號為dorado的系統，因為這些檔案本身是比較小的，而且數量也不是特別多，但是需要用https加密，通過加密規避小運營商的快取問題。
所以我們對於這些關鍵檔案，全部有自有節點，在節點上支援https加密方法，規避小運營商快取帶來的一些問題。
我們在設計這套系統的時候，也想過用p2p去做。大家想p2p是很炫，又節省頻寬，但是用於生產環境中大檔案分發的時候會有幾個問題。
一是安全控制的問題，很難讓這些伺服器之間又能傳資料又能進行安全埠的保護。
二是在p2p裡做流量控制或者流量限定也是乙個挑戰。所以最終我們採用了乙個看起來比較簡單的架構。
說到客戶端更新，其實更新的效果如何，玩家到底有沒有安裝成功或者進入遊戲，很多時候我們也很茫然，只能看日誌。
我們第乙個版本的備份系統，它的設計和實現是比較簡單的：不同的機房會有一台ftp伺服器，本機房的資料寫入ftp伺服器，然後寫入磁帶，但是這樣就導致磁帶是分散的，沒有集中存放的地方；另外，基於ftp的上傳會有頻寬甚至有延遲的要求。
後來我們設計了乙個集中的備份系統。它主要解決了以下兩個問題。
第一是簡化配置。我們所有機房的全部配置，用乙個負載均衡器的ip就可以了，當客戶端需要上傳檔案時，通過負載均衡器獲取實際上傳的位址，然後上傳檔案，由左邊第二個框裡面的伺服器進行接收，並且根據md5值進行校驗，如果校驗沒有問題，就轉到hadoop的hdfs集群裡面去。目前這個集群有數十pb的規模，每天上傳量有幾個tb。
第二是提高傳輸效率和成功率。大家會想乙個問題，在中國，網路環境十分複雜，運營商之間存在隔閡甚至是壁壘，導致網路不穩定，丟包和延遲的問題是怎樣解決的呢？如果基於tcp傳輸大檔案，理論上存在單個連線上頻寬延時積的限制。
這裡我們創新的是，客戶端的上傳採用udp協議，udp本身沒有任何控制，說白了就是客戶端可以任意、使勁地發檔案。最終會由伺服器端檢查你收到了哪些檔案片段，然後通知客戶端補傳一些沒上傳的片段就可以了。基於這種方式能規避很多因為網路抖動或網路延遲比較大而導致的問題。當然，在客戶端做流量控制也是可以的。在遇到問題的時候多想想，或許能找到不走尋常路的解決方案。
再看一下遊戲的自動化監控報警系統（如下圖所示）。遊戲的架構中有遊戲客戶端、伺服器端、網路鏈路，所以必須要有比較完整的體系進行全方位、立體式的監控，才能保證在業務發生問題之前進行預警，或者在發生問題時報警。
對於機房鏈路，有idc（internet data center）的網路質量監控；在伺服器、網路裝置和硬體方面，我們會做伺服器的健康檢查、效能監控，以及網路裝置和流量監控；
作為運維人員，我們考慮問題或者設計架構的時候，視角不能僅侷限於乙個技術方面，或者選用多炫酷、多麼牛的技術，要想想技術在業務方面的架構，或者能否通過業務指標監控我們的運維能力與運維系統。
以上講的是乙個框架，下面我們看一下細節，怎樣做伺服器的監控。首先由運維工程師在監控策略平台配置監控策略，監控策略平台會將這些資料格式化成相關格式，然後推送給自動化運維平台。
自動化運維平台會判斷是這些資料是外部來的，還是遠端檢測到的；是網路模擬的，還是本地的監控得到的。
比如流量、本地程序的監控、本地日誌的監控，會分別推給遠端探測伺服器，或者遊戲伺服器本身，然後由它們上報資料。資料上報以後，根據運維工程師配置的閾值，會觸發相關的報警，然後通知運維工程師進行相關處理。因為雖然遊戲多種多樣，作業系統五花八門，但是總有一些大家可以公用的東西，比如監控的模板或者監控的策略，我們對伺服器的東西也進行了整合彙總。
貝聊運維自動化體系演化
馬上要進入2018年了，這裡有必要對我們的 運維自動化體系 有所回顧及展望 一 運維自動化發展通常劃分 如果把運維自動化發展按上圖作劃分，在過去一年多的時間裡，我們通過努力,逐漸從第一階段邁進到第三階段 二 回顧過去一年貝聊運維自動化體系演化 一年之前的貝聊運維的情況 一年之後的，我們通過努力成達的...
ansible 自動化運維（一）
ansible 用 python 寫的。主要是自動化運維使用。ansible 批量管理linux系統windows系統。linux 管理 linux 走的是ssh通道。普通使用者需要增加sudo的配置。管控機和收管機要完成無密碼驗證登入。1.需要設定無密碼登入。2.有密碼登入。expect 無互動密...
Python自動化運維（一）
1.系統效能資訊模組psutil cpu資訊psutil.cpu times 方法獲取cpu的完整時間資訊 psutil.cpu times percent 方法獲取cpu的完整百分比資訊 psutil.cpu count 獲取cpu數量 psutil.cpu percent 獲取cpu百分比資訊 ...