運維技術乾貨 — 不只是 Linux 運維最佳實踐

咱們面對的是一個不斷變化的世界，業務需求在變，技術架構在變，開源工具與商業系統異構部署，新工具和技術概念層出不窮，惟有一套科學的技術方法論才能應對這些變化。不少時候，咱們在面對新的問題時，會束手無措。所以，在 OSC 第 132 期高手問答中，咱們策劃了「Linux 運維最佳實踐」的主題，並邀請了@xufengnju（胥峯）做爲高手嘉賓。

@xufengnju（胥峯），資深運維專家，有 10 年運維經驗，在業界頗具威望和影響力。也是盛大遊戲高級研究員，2006 年畢業於南京大學，2011 年加入盛大遊戲，工做至今，曾參與盛大遊戲多款大型端遊和手遊的上線運維，主導運維自動化平臺的功能設計和實施。擁有工信部認證高級信息系統項目管理師資格。

自動化運維在近幾年一直都是很火熱的話題，技術也一直在進步，所以對於技術人員來講，最重要的思惟上、思想上的適應與轉變。畢竟技術不是運維的終極追求，思想纔是運維人員應該畢生修煉的目標！本次高手問答的高手嘉賓對運維服務體系有着深度的思考，所以問答中產生的內容也是十分有質量。

本文從多個角度整理了與運維相關的內容，包括工具的選擇、運維中遇到的問題、自動化運維相關等等。

1、工欲善其事必先利其器，如何選擇工具？

1. 對服務器安全和監控，能夠推薦一些開源工具嗎？監控好像也就 nagios, cacti, zabbix，還有其餘能夠推薦的嗎？安全方面如何監控？

監控工具各有側重點，zabbix 同時支持 snmp 和本身的 agent，也支持自定義模板，在大部分場景下都是不錯的選擇。

另外，不要把 zabbix 視爲只能監控服務器信息，經過自定義模板，也能夠監控業務層面的指標。安全監控分爲主動檢測，如 Tenable Nessus，以及 IDS、IPS。

2. Linux 運維中，服務器版本都用什麼版本？CentOS 5 仍是 CentOS 六、Ubuntu？爲何選擇這個版本？有作哪些測試？

目前咱們以 CentOS6.X 爲主。不一樣 Linux 分支各有特色，好比 Ubuntu 新版本發佈較快，若是追求內核版本升級速度的話，能夠考慮。CentOS 一直是咱們的主要 Linux 發行版，主要是考慮到它的穩定性以及熟悉程度最高。

3. 對於使用緩存有什麼推薦嗎？通常就 Redis, Codis。還有那些比較好用的開源軟件？

對於相似 session-id 這樣的能夠非持久存儲的數據，能夠考慮 memcached，使用一致性哈希算法分佈式存儲。

4. 作自動化發佈，除了 Jenkins 持續集成工具，還有那些好用的工具呢？

目前我所知道的，通常都是 Hudson 或者 Jenkins，後者是前者分支出來的。這些工具都有豐富的插件，靈活使用這些插件是關鍵所在。

5. 問個 MySQL 問題，三個版本（MySQL（官方版本）、Percona Server 、MariaDB）您建議使用哪一個版本，緣由是？

咱們團隊通常使用的是官方版本。主要是考慮到支持和生態。

6. 服務器日誌收集和分析有什麼好工具推薦嗎？ELK 貌似有點複雜，不太會用，有其餘的推薦麼？

ELK 確實是目前使用比較普遍的日誌收集和分析的工具。雖然有些學習成本，但仍是值得去研究和嘗試的。

7. 書裏有開源出一些工具和腳本嗎，哪裏能夠下載到？

書上的腳本我正在整理，其中一部分經過 git 能夠下載 https://github.com/xufengnju/books.git。

8. 請問大家如今運維都是基於 Ansible 嗎？咱們以前都是用 chef puppt 來管理。最近感受 Ansible 很火，還沒實踐用過，請問這個用起來差異大嗎？

請問你運維有實踐過 IaaS 平臺的嗎，有沒有一些經驗交流？

1. 各類不一樣的批量管理工具各具特色，根據本身的熟悉程度和實際業務須要選擇一個徹底掌握便可
2. 目前 IaaS 平臺是自研的，基於 KVM

2、絕知此事要躬行，運維中遇到問題？

1. LVS 和 HAPROXY 後端服務器規模能夠到什麼程度，好比有多少個應用，多少臺後端服務器？

這個取決於應用的類型，在實際的業務場景下，須要關注 LVS 等負載均衡器自己的鏈接數、PPS 數據以及延遲。若是後端吞吐量比較大，能夠考慮 LVS 的 DR 模式。通常狀況下，負載均衡器不太會成爲瓶頸。

負載均衡器自己的鏈接數、PPS 數據以及延遲如何進行計算和統計？

經過開源的 Zabbix 模板或者自定義模板，這些都不難實現。

有沒有相關的命令集進行統計，或者詳細的統計實例？

針對 HAProxy 建議參考我們書中 P76 頁最佳實踐 29 HAProxy 監控的內容。Zabbix 模板技術，建議參考下我們書中第 12 章的內容。可使用的命令包括 ipvsadm，netstat 等。

2. 對於涉及多個平臺（Unix, Linux, Windows）的統一管理（認證，配置，服務）有什麼好的解決方案或者思路麼？

先說下認證這一塊吧。Unix、Linux 都支持 OpenLDAP 認證，能夠考慮，這個和 Windows 下的 AD 是兼容的。配置和服務能夠考慮下開源的通用產品，好比 Ansible 或者 Salt。目前咱們用的自研系統，思路和 Ansible 相似。

3. 如何監控服務，業務運行狀態監控你是怎麼作的？

咱們的監控系統是自研的，對遊戲來講，很重要的一個業務指標是在線人數，它是經過監控系統週期性輪詢遊戲服務器來進行收集和繪製圖表的。

4. 大家是如何批量管理各個業務模塊的機器系統及配置的。咱們目錄使用 Ansible 使用批量命令和腳本，業務上使用上線平臺 SVN 管理業務程序及配置。是否開發了 CMDB 平臺？

咱們批量管理服務器的方式是 ssh，思路和 Ansible 相似。CMDB 提供基礎數據的管理，是自研的。

5. 請問有使用過流量鏡像嗎？就是把線上的流量鏡像一份，引到測試環境，用真實的用戶數據測試，想了解下從 0 開始實施的過程。

關於流量鏡像的原理，能夠參考《Linux 運維最佳實踐》第 15 章中網卡混雜模式和 RawSocket 技術。看了這一部分後，你應該能夠本身寫一套。我沒有親自實踐過，你能夠本身關注下 tcpcopy 這個項目。

6. CentOS 6 要如何作系統和網絡優化？/etc/sysctl.conf 中的這個參數

net.ipv4.tcp_max_tw_buckets = 6000

要如何設置，是越多越好嗎？設置成 16000？

net.ipv4.tcp_max_tw_buckets = 16000

對於系統優化來講，要有針對性。tcp_max_tw_buckets 針對的是 time wait bucket，如系統中 timewait 狀態較多，能夠考慮 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 這 2 個值調整。另外，若是使用長鏈接對於減小該狀態的鏈接數有效。

7. 若是有 100 多臺服務器，大部分都是在提供業務的服務器，如何升級呢？除了停機維護，如今有什麼比較好的解決方案嗎？

若是自己業務切分比較好，例如採用無狀態的微服務等架構，能夠經過前端負載均衡器進行灰度升級。若是應用作的很差，只有單臺的這種，或者集中數據庫，就比較麻煩了。

8. LVS 和 HAPROXY 分別能支持多少相似 FARM 的概念？

你說的 FARM 應該是某硬件負載均衡設備的專有名詞，應該是負載均衡組的概念。在 LVS 和 HAProxy 裏面，負載均衡組的數量上沒有硬限制，但實踐中通常不會配置太多，由於這涉及到維護成本以及 HA 環境下主備切換時的開銷。

9. 系統是 CentOS release 6.5 (Final)， 系統沒有自動回收內存，16G，我本身寫了個 Shell 腳本，每次執行判斷小於 1G 的時候回收內存

能夠關注下 sysctl 中 swap 以及 swappiness 的一些配置

10. 請問若是是有不少 ECS/VPS，系統通常是 CentOS。目前不少堡壘機也有相似的 SSH 同步密鑰下發命令等功能，可是若是還有 Win的堡壘機支持不多。有別的開源工具或者辦法來混合管理全部的 Linux, Windows 機器嗎？ 

在個人這個演講裏面講到了異構系統的批量管理方法，你能夠參考下。

http://www.build.net/greatops/453250.html。另外，你能夠參考下 Ansible 或者 salt。

3、自動化運維相關，工程師思惟？

1. 能夠說下什麼是自動化運維，如何纔算服務器作了自動化運維？包括哪些？自動化發佈，有問題能夠回滾？

運維自動化是一個仁者見仁智者見智的概念。個人理解是，運維自動化要打通從代碼開發完到正式上線的全部環節，包括版本構建、打通自動測試、自動化上線以及自動化監控。

在這個大命題下，能夠根據本身工做環境和自動化水平的不一樣，選擇一兩個痛點開始進行自動化實踐。最後造成完總體系。

2. 想請問一下自動化運維怎麼作的？須要從那些方面考慮？我所考慮到的有實施運維，平常巡檢維護，以及故障自動化處理，和提醒。除了這些請問還要注意那些方面？另外，隨着 IT 技術的突飛猛進，涌現了不少新的應用，請問該若是有一個基本的路子來作運維，或者規律，流程來達到運維需求？例如如今比較火的OpenStack Docker 大數據。這些技術實現功能只是很小的一步，更多的是上線後的運維。更可能是想要一種思路，能列舉你們遇到過的問題，以及問題如何處理？ 

你的問題很好，但這個話題比較大。我先說下個人理解吧。傳統的運維服務流程 ITIL 還有必定的價值，但須要結合一些 DevOps 思想來進行適當的改造，融合二者的長處。從擁抱變化開始，以一種開放的態度來進行運維。但不變的一點是，覺得業務創造價值爲最終目標，這就是運維的目標。

3. 實現運維自動化，最主要就是配置管理、狀態管理和變動管理，其中配置管理要如何來作，有什麼好的方法分享下嗎？

對配置管理，我認爲應該分爲「基礎架構資源配置管理」和「軟件/應用配置管理」。

前者是通常意義上的 CMDB 的範疇，這個能夠根據本身業務特色在開源 CMDB 方案的基礎上作必定的適配；

對於後者，一方面是系統（例如版本控制系統的結合），一方面是流程（例如和變動管理掛鉤）。在咱們的實踐中，這 2 個方面都有涉及。

4. 請問你主導運維自動化平臺的功能設計和實施，是經過 Python 開發管理工具嗎？另外，大家是從新開發，仍是根據 Saltstack 之類的進行二次開發。

底層使用 SSH 協議創建服務器管理通道，上層使用 PHP 開發管理界面以及封裝一些經常使用操做，好比密碼修改、腳本下發和執行等。徹底自主開發。

4、作好安全措施很重要，安全相關的問題

1. 運維離不開安全，服務器的安全也很重要，書中有講運維安全這塊嗎，如何把控安全這塊？

書中有安全主題。安全是一個龐大的體系，書中主要講了保障 Linux 系統安全的一些措施。其餘安全主題，好比社會工程和入侵檢測，可能須要看更專業的書。你能夠先看看我們《Linux 運維最佳實踐》是否能知足你的基本安全需求。謝謝支持。

2. Web 安全監控有開源解決方案嗎，可否作到在接入層就把一些可能的漏洞攔掉？Suricata？

Suricata 沒有研究和實踐過。《Linux 運維最佳實踐》中第 11 章 Web 服務器安所有分提到了幾個工具，你能夠參考下。但 ModSecurity 規則在上線前要進行嚴格詳細測試，不要出現誤判。另外，建議對生產環境進行按期的安全掃描，例如使用 Tenable Nessus 工具等。安全專家的人工滲透測試也是必須的。

5、Docker 很火熱，在運維中結合使用？

1. 在網易遊戲運維中是否用到了最近很火的 Docker 技術以及應用在哪，存在什麼問題，如何解決？

目前咱們在調研 Docker 技術，只有少許遊戲測試使用。須要根據不一樣的業務模型選擇對應的網絡模型和存儲方案。Docker 技術會改變傳統的運維方式，要考慮和原有運維繫統整合以及運維習慣的調整所帶來的挑戰。另外，我不是網易公司的，我目前在盛大遊戲工做。 

2. Docker 化對運維影響深遠嗎？

Docker 化對運維有影響，它帶來的影響包括：持續交付、微服務以及 DevOps 理念的衝擊。做爲運維，咱們要擁抱這個變化，經過不斷學習和實踐來迎接這些挑戰。

3. 爲什麼國內沒有一家成熟的 Docker 方案公佈細節呢？

Docker 仍是一個新生事物，各家使用的場景和模式有所不一樣，並且會有一些二次開發的管理系統和調度系統。

6、不是全部對比都會產生傷害，工程師想的只是最優方案

1. 遊戲服務器運維和網站服務器運維以及 APP 服務器運維，有哪些不一樣點和相同點？

這個問題頗有表明性。不一樣點是，網站和 APP 運維接觸的通用開源軟件比較多，遊戲運維接觸的大部分都是自研的程序。

共同點是，都須要掌握操做系統知識、軟件硬件以及網絡知識，還有排查問題的思路和容量規劃等。二者都須要引入運維自動化的思惟和體系。《Linux 運維最佳實踐》最後 2 章描述了遊戲運維的相關體系和技術。

2. 做爲運維人員，Python 這樣的腳本在進行系統管理和監控的時候相比 Shell 有怎樣的優點呢？

做爲高級編程語言，Python 有很是豐富的庫，包括核心庫和第三方庫，不少時候不須要本身造輪子；

相比 Shell，它有更好的控制力、重試機制，好比對 Socket 設置超時等等。

3. CentOS 比起 Ubuntu 來講有啥優點？爲何服務器大多用 CentOS？

不一樣 Linux 分支各有特色，好比 Ubuntu 新版本發佈較快，若是追求內核版本升級速度的話，能夠考慮。CentOS 一直是咱們的主要 Linux 發行版，穩定性以及熟悉程度最高。

選擇某個發行版時，要考慮它的生態，好比上下游的支持，還有一點，就是運維人員招聘的方便程度，國內熟悉 CentOS 的稍多一些。

4. 想問下只有一臺服務器，有多個應用，是用 LVS 作負載好仍是 Nginx？差異大嗎？

你說的後端應用是基於 HTTP 或者 HTTPS 的嗎？若是是的話，而且吞吐量不大的狀況下，使用 Nginx 便可；若是非 HTTP 或者 HTTPS 的 TCP 應用，建議使用 LVS；若是 HTTP 或者 HTTPS 吞吐量特別大的狀況下，使用 LVS DR 模式。

7、You Need Backup，與備份相關的一些問題

1. 1000 臺機器規模，備份系統應該要作到什麼程度？

1000 臺服務器，要區分業務類型，若是類型單一，備份就比較好作。若是類型多，那麼要考慮的地方包括：數據庫更新的頻率（全備+增量備份？仍是隻使用全備）、數據備份的大小、數據集中歸檔的要求。

2. 備份是怎麼作的？上百 T 的圖片、附件有什麼高雅的備份方案？

在線備份這一塊，能夠考慮使用 erasure coding 算法，在增長必定可靠性的能力下，不至於致使備份存儲的成本太高。同時要考慮離線備份，好比磁帶。

8、路漫漫其修遠兮，運維工程師的職業生涯

1. 你以爲在將來，運維的核心會是什麼，自動化，預判或是其餘？

我以爲，將來的運維應該是智能化的。把如今須要人作的容量規劃、擴縮容、排障所有實現智能化。運維的任務就是編程，把本身的能力灌輸到機器上。固然，理想很豐滿，現實很骨感。這須要咱們的不懈努力。

2. 做爲工做 4 年多的測試工做者，在運維方面也是有必定的涉獵，在公司維護本身的測試環境，有時候也須要必定運維功底，從 Windows Server 到 Linux，學習不少，也總結了不少。上家公司着手 Docker 部署的時候恰好離開公司了。真是有點遺憾，後續工做也沒時間去實踐，目前使用的是 ng 負載，採用 Tomcat 部署方案，工做實在比較忙，很想在運維方面也有必定的提高！不知道從何入手好，求大神指教。

從你的描述來看，目前是兼職運維。我建議是否能夠考慮，在搭建環境以外，多多研究下其中的原理，同時用自動化腳本維護這些環境呢。相信你也有一些編程經驗，這些對於你後續實踐運維也是有幫助的。另外，就是能夠多看看別人總結的運維案例，少走一些彎路。

3. 運維技術挺雜的，如何看待這種雜？給人感受好像什麼都會點，對於工做 5-6 年的運維來講，有什麼好的學習建議？

如你所說，運維技術要求範圍確實蠻廣的。我以爲，對於工做了必定時間的運維同窗來講，能夠考慮的方向有如下幾個：

1. DevOps 實踐（增強本身的編程能力，系統學習一門高級編程語言，運維自動化）
2. 對本身的技術薄弱點重點學習，好比系統學習網絡知識
3. 看一些比較好的運維技術書籍，學習別人的乾貨

4. 因爲運維繫統有全面的數據收集、自動處理、報警和自動恢復的機制，咱們這裏將運維和 BI 結合在一塊兒。擴展運維工具和架構，將已成熟的 BI 接入運維體系，解放業務專員的工做，常規的業務分析、報表、數據監控均可依賴這套運維繫統。在咱們這裏，運維從一層平臺逐漸變成一種框架，有須要的場景均可以套用。技術一直在變，但最重要的不是技術，而是用技術提供服務的思想。

除了和 BI 結合，運維思惟還能夠和哪些相關業務場景結合，能夠在新的方向上產生價值呢？

我很贊同你的想法和實踐，「用技術提供服務的思想」。我我的認爲，運維的終極目標多是「沒有運維工程師的」自運維，或者叫智能運維，是 AI 在運維領域的深度融合和實踐。容量規劃算法的不斷優化、基於公有云的資源自動調度都應該是智能化的。固然，實現這個目標還有很長的路要走。

5. Devops 對運維有那些改變，能簡單說下嘛？

Devops 從概念提出到如今已經有一段比較長的時間了，整體來講，我認爲它帶來的變化是：持續交付能力須要打通研發、測試和部署運維的整個鏈路，它對運維自動化的能力要求更高了。咱們必須經過掌握一些運維自動化框架加上必定的編程能力才能根據業務場景來應對這種變化。另外，對運維來講，就是要擁抱變化，以開放的態度進行協做。

6. 如今哪一個版本的 Linux 使用最普遍，還有 Linux 運維，咱們須要學習一些語言嗎，好比 Python 之類，這樣才能算是一個真正的好運維？

不要猶豫了，當即開始學習編程吧，無論 Perl 仍是 Python，熟悉哪種都行。在這裏，我不對比 Perl 和 Python 的優缺點。堅持用本身的代碼（加上別人的框架和庫）來解決重複的運維問題，你會成長的更快。CentOS 用的比較多。

《Linux 運維最佳實踐》第 18 章是使用 Perl 進行系統自動化編程的內容，你能夠先看看。若是感興趣的話，當即開始吧。

7. 請問您寫書，是怎麼堅持寫下來的？是把平時工做重點的問題，記錄下來，天天寫一點，再總結嗎？寫書有什麼工具軟件嗎，仍是隻是用 Word 來寫？能分享下寫運維書籍的方法嗎？

這個問題很是好，也是我想分享的。寫書的素材依賴於平時的積累，建議你們平時多寫寫標準的文檔，word 格式能夠參考我們這本書的編排。比較重要的 3 點是：

1. visio 圖要保留下來，不能只存圖片，由於可能還要調整排版
2. 有些故障現場，儘可能記錄詳細，現象和分析過程、輔助的日誌和抓包文件等，建議都保留下來
3. 腳本按照分類保存下來，以便查找

有關 Linux 運維最佳實踐的問答內容至此結束，各位讀者能夠轉到原貼瀏覽更多內容。歡迎你們在開源中國的技術問答區踊躍提問和回答，一塊兒交流、學習和進步。