本篇文章為大家展示了怎么進行Linux 運維最佳實踐，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
我們面對的是一個不斷變化的世界，業務需求在變，技術架構在變，開源工具與商業系統異構部署，新工具和技術概念層出不窮，唯有一套科學的技術方法論才能應對這些變化。很多時候，我們在面對新的問題時，會束手無措。
自動化運維在近幾年一直都是很火熱的話題，技術也一直在進步，因此對于技術人員來說，最重要的思維上、思想上的適應與轉變。畢竟技術不是運維的終極追求，思想才是運維人員應該畢生修煉的目標！
1. 對服務器安全和監控，可以推薦一些開源工具嗎？監控好像也就 nagios, cacti, zabbix，還有其他可以推薦的嗎？安全方面如何監控？
監控工具各有側重點，zabbix 同時支持 snmp 和自己的 agent，也支持自定義模板，在大部分場景下都是不錯的選擇。
另外，不要把 zabbix 視為只能監控服務器信息，通過自定義模板，也可以監控業務層面的指標。安全監控分為主動檢測，如 Tenable Nessus，以及 IDS、IPS。
2. Linux 運維中，服務器版本都用什么版本？CentOS 5 還是 CentOS 6、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 平臺的嗎，有沒有一些經驗交流？
各種不同的批量管理工具各具特點，根據自己的熟悉程度和實際業務需要選擇一個完全掌握即可
目前 IaaS 平臺是自研的，基于 KVM
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。
1. 可以說下什么是自動化運維，如何才算服務器做了自動化運維？包括哪些？自動化發布，有問題可以回滾？
運維自動化是一個仁者見仁智者見智的概念。我的理解是，運維自動化要打通從代碼開發完到正式上線的所有環節，包括版本構建、打通自動測試、自動化上線以及自動化監控。
在這個大命題下，可以根據自己工作環境和自動化水平的不同，選擇一兩個痛點開始進行自動化實踐。最后形成完整體系。
2. 想請問一下自動化運維怎么做的？需要從那些方面考慮？我所考慮到的有實施運維，日常巡檢維護，以及故障自動化處理，和提醒。除了這些請問還要注意那些方面？另外，隨著 IT 技術的日新月異，涌現了很多新的應用，請問該如果有一個基本的路子來做運維，或者規律，流程來達到運維需求？例如現在比較火的OpenStack Docker 大數據。這些技術實現功能只是很小的一步，更多的是上線后的運維。更多是想要一種思路，能列舉大家遇到過的問題，以及問題如何處理？
你的問題很好，但這個話題比較大。我先說下我的理解吧。傳統的運維服務流程 ITIL 還有一定的價值，但需要結合一些 DevOps 思想來進行適當的改造，融合兩者的長處。從擁抱變化開始，以一種開放的態度來進行運維。但不變的一點是，以為業務創造價值為最終目標，這就是運維的目標。
3. 實現運維自動化，最主要就是配置管理、狀態管理和變更管理，其中配置管理要如何來做，有什么好的方法分享下嗎？
對配置管理，我認為應該分為“基礎架構資源配置管理”和“軟件/應用配置管理”。
前者是一般意義上的 CMDB 的范疇，這個可以根據自己業務特點在開源 CMDB 方案的基礎上做一定的適配；
對于后者，一方面是系統（例如版本控制系統的結合），一方面是流程（例如和變更管理掛鉤）。在我們的實踐中，這 2 個方面都有涉及。
4. 請問你主導運維自動化平臺的功能設計和實施，是通過 Python 開發管理工具嗎？另外，你們是重新開發，還是根據 Saltstack 之類的進行二次開發。
底層使用 SSH 協議建立服務器管理通道，上層使用 PHP 開發管理界面以及封裝一些常用操作，比如密碼修改、腳本下發和執行等。完全自主開發。
1. 運維離不開安全，服務器的安全也很重要，書中有講運維安全這塊嗎，如何把控安全這塊？
書中有安全主題。安全是一個龐大的體系，書中主要講了保障 Linux 系統安全的一些措施。其他安全主題，比如社會工程和入侵檢測，可能需要看更專業的書。你可以先看看咱們《Linux 運維最佳實踐》是否能滿足你的基本安全需求。謝謝支持。
2. Web 安全監控有開源解決方案嗎，能否做到在接入層就把一些可能的漏洞攔掉？Suricata？
Suricata 沒有研究和實踐過?！禠inux 運維最佳實踐》中第 11 章 Web 服務器安全部分提到了幾個工具，你可以參考下。但 ModSecurity 規則在上線前要進行嚴格詳細測試，不要出現誤判。另外，建議對生產環境進行定期的安全掃描，例如使用 Tenable Nessus 工具等。安全專家的人工滲透測試也是必須的。
1. 在網易游戲運維中是否用到了最近很火的 Docker 技術以及應用在哪，存在什么問題，如何解決？
目前我們在調研 Docker 技術，只有少量游戲測試使用。需要根據不同的業務模型選擇對應的網絡模型和存儲方案。Docker 技術會改變傳統的運維方式，要考慮和原有運維系統整合以及運維習慣的調整所帶來的挑戰。另外，我不是網易公司的，我目前在盛大游戲工作。
2. Docker 化對運維影響深遠嗎？
Docker 化對運維有影響，它帶來的影響包括：持續交付、微服務以及 DevOps 理念的沖擊。作為運維，我們要擁抱這個變化，通過不斷學習和實踐來迎接這些挑戰。
3. 為何國內沒有一家成熟的 Docker 方案公布細節呢？
Docker 還是一個新生事物，各家使用的場景和模式有所不同，而且會有一些二次開發的管理系統和調度系統。
1. 游戲服務器運維和網站服務器運維以及 APP 服務器運維，有哪些不同點和相同點？
這個問題很有代表性。不同點是，網站和 APP 運維接觸的通用開源軟件比較多，游戲運維接觸的大部分都是自研的程序。
共同點是，都需要掌握操作系統知識、軟件硬件以及網絡知識，還有排查問題的思路和容量規劃等。兩者都需要引入運維自動化的思維和體系?！禠inux 運維最佳實踐》最后 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 模式。
1. 1000 臺機器規模，備份系統應該要做到什么程度？
1000 臺服務器，要區分業務類型，如果類型單一，備份就比較好做。如果類型多，那么要考慮的地方包括：數據庫更新的頻率（全備+增量備份？還是只使用全備）、數據備份的大小、數據集中歸檔的要求。
2. 備份是怎么做的？上百 T 的圖片、附件有什么高雅的備份方案？
在線備份這一塊，可以考慮使用 erasure coding 算法，在增加一定可靠性的能力下，不至于導致備份存儲的成本過高。同時要考慮離線備份，比如磁帶。
1. 你覺得在未來，運維的核心會是什么，自動化，預判或是其他？
我覺得，未來的運維應該是智能化的。把現在需要人做的容量規劃、擴縮容、排障全部實現智能化。運維的任務就是編程，把自己的能力灌輸到機器上。當然，理想很豐滿，現實很骨感。這需要我們的不懈努力。
2. 作為工作 4 年多的測試工作者，在運維方面也是有一定的涉獵，在公司維護自己的測試環境，有時候也需要一定運維功底，從 Windows Server 到 Linux，學習很多，也總結了很多。上家公司著手 Docker 部署的時候剛好離開公司了。真是有點遺憾，后續工作也沒時間去實踐，目前使用的是 ng 負載，采用 Tomcat 部署方案，工作實在比較忙，很想在運維方面也有一定的提升！不知道從何入手好，求大神指教。
從你的描述來看，目前是兼職運維。我建議是否可以考慮，在搭建環境之外，多多研究下其中的原理，同時用自動化腳本維護這些環境呢。相信你也有一些編程經驗，這些對于你后續實踐運維也是有幫助的。另外，就是可以多看看別人總結的運維案例，少走一些彎路。
3. 運維技術挺雜的，如何看待這種雜？給人感覺好像什么都會點，對于工作 5-6 年的運維來說，有什么好的學習建議？
如你所說，運維技術要求范圍確實蠻廣的。我覺得，對于工作了一定時間的運維同學來說，可以考慮的方向有以下幾個：
DevOps 實踐（加強自己的編程能力，系統學習一門高級編程語言，運維自動化）
對自己的技術薄弱點重點學習，比如系統學習網絡知識
看一些比較好的運維技術書籍，學習別人的干貨
4. 由于運維系統有全面的數據收集、自動處理、報警和自動恢復的機制，我們這里將運維和 BI 結合在一起。擴展運維工具和架構，將已成熟的 BI 接入運維體系，解放業務專員的工作，常規的業務分析、報表、數據監控都可依賴這套運維系統。在我們這里，運維從一層平臺逐漸變成一種框架，有需要的場景都可以套用。技術一直在變，但最重要的不是技術，而是用技術提供服務的思想。
除了和 BI 結合，運維思維還可以和哪些相關業務場景結合，可以在新的方向上產生價值呢？
我很贊同你的想法和實踐，“用技術提供服務的思想”。我個人認為，運維的終極目標可能是“沒有運維工程師的”自運維，或者叫智能運維，是 AI 在運維領域的深度融合和實踐。容量規劃算法的不斷優化、基于公有云的資源自動調度都應該是智能化的。當然，實現這個目標還有很長的路要走。
5. Devops 對運維有那些改變，能簡單說下嘛？
Devops 從概念提出到現在已經有一段比較長的時間了，總體來說，我認為它帶來的變化是：持續交付能力需要打通研發、測試和部署運維的整個鏈路，它對運維自動化的能力要求更高了。我們必須通過掌握一些運維自動化框架加上一定的編程能力才能根據業務場景來應對這種變化。另外，對運維來說，就是要擁抱變化，以開放的態度進行協作。
6. 現在哪個版本的 Linux 使用最廣泛，還有 Linux 運維，我們需要學習一些語言嗎，比如 Python 之類，這樣才能算是一個真正的好運維？
不要猶豫了，立即開始學習編程吧，不管 Perl 還是 Python，熟悉哪一種都行。在這里，我不對比 Perl 和 Python 的優缺點。堅持用自己的代碼（加上別人的框架和庫）來解決重復的運維問題，你會成長的更快。CentOS 用的比較多。
《Linux 運維最佳實踐》第 18 章是使用 Perl 進行系統自動化編程的內容，你可以先看看。如果感興趣的話，立即開始吧。
7. 請問寫書，是怎么堅持寫下來的？是把平時工作重點的問題，記錄下來，每天寫一點，再總結嗎？寫書有什么工具軟件嗎，還是只是用 Word 來寫？能分享下寫運維書籍的方法嗎？
這個問題非常好，也是我想分享的。寫書的素材依賴于平時的積累，建議大家平時多寫寫標準的文檔，word 格式可以參考咱們這本書的編排。比較重要的 3 點是：
visio 圖要保留下來，不能只存圖片，因為可能還要調整排版
有些故障現場，盡量記錄詳細，現象和分析過程、輔助的日志和抓包文件等，建議都保留下來
腳本按照分類保存下來，以便查找
上述內容就是怎么進行Linux 運維最佳實踐，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
