「Linux 集羣和自動化運維」高手問答精選

這些年來，不少人都在談自動化運維。但回過頭來反思一下，作了幾年的自動化運維，是否仍是不能肯定有哪些工做沒作，或是怎樣更優雅的實施運維自動化，又或者你只是是剛剛踏入自動化運維這扇大門，對不少知識還沒理清楚。所以咱們 OSC 第 126 期高手問答帶來了 Linux 集羣和自動化運維這個主題，並請來了@撫琴煮酒（餘洪春）爲你們解答關於Linux集羣和自動化運維的問題。

這篇文章挑選了部分精彩的問答內容，分享給各位交流、學習。也能夠轉到原連接繼續瀏覽。

Q:想向運維方向發展，平時在測試時寫一些自動化腳本，基本上是用Shell寫的，也想過用jenkins那些自動發佈工具，但感受速度有點慢，還有，好多東西仍是須要手動去建，好比我看如今公司的運維團隊操做跟我差很少，大部分仍是要靠手動，如今公司的項目愈來愈多，產品線愈來愈多，運維只是加人力，招的人經驗也比較豐富（有好幾我的有網易等公司的運維經驗），並無作到真正的自動化，您這本書中有好的建設方案麼？

A:平時的運維業務能夠朝自動化的方向努力，機器少的場景能夠靠人力抗，但機器的數量規模真正到了必定級別則必需要推行運維自動化了。不過要想真正的跟公司的業務結合起來，不少好的開源工具或方案，則須要進行二次開發。 

Q:做爲研發的同窗，日常也要作些網絡架構、運維評估等工做，是否有必要系統學習下linux 方方面面的知識？

A:恩，這個仍是有必要的，熟悉Linux系統方向對工做仍是頗有幫助的，之後能夠往架構師的方向轉。

Q:集羣化的雲計算運維相比傳統運維，所須要掌握的新技術點在哪？

A:關注點不同，好比拿AWS雲平臺來講，像傳統運維，面臨着安裝系統、系統上架，分配機房等問題，但這些基礎運維的活雲平臺都自動作了；若是想往雲計算運維方向發展，要努力不斷學習新的技術，好比Docker、salt、Ansible等，開發語言也要掌握一門，平時多關注Devops方向

Q:將來運維的發展方向是什麼樣的呢？，感受傳統的基礎運維，開始淘汰了，除了大型的IDC或互聯網公司，如今也看到不少運維都開始學習一些開發的知識。我的感受運維可能會靠向devops這塊發展

A:恩，確實是這樣，建議學習Python，將來的雲計算運維是會向DevOps方向轉的。

Q:那些狀況須要作自動化運維？有什麼條件嗎？超過20臺服務器？如何給領導建議作這塊呢？

A:一、機器數量比較多的狀況下，好比咱們的平臺超過了500臺，並且還存在增加趨勢； 二、業務和項目愈來愈多的狀況下，好比常常須要統一開發環境、線上測試環境和線上環境。 給領導提方案的前提是本身要很是熟悉本身提出的自動化方案的優勢和缺點，有些坑要提早提出來，記住：本身不要給本身挖坑，要不很難找人填 。 

Q:請問自動化大體包括那幾個方面？我想知道書裏是否有講，這兩部分：1.如何監控故障？2.監控到故障如何自動化或者半自動化處理？其實我以爲如今運維是很大一塊，如今各類雲平臺，各類機器設備，開源方案卻是不少，更多的是上線以後的運維！謝謝！

A:咱們的監控好比細緻：1,系統和服務監控；2，流量監控；3，業務監控。目前監控到問題之後仍是會手動處理，由於平臺很是複雜，若是作成半自動或全自動的意義不大。但像不少業務都作成了自動化的，好比自動起spark/reduce機器，還有爬蟲程序，這些能作成自動化處理的所有自動化了。

Q:不少人都不接受「自動化」運維。他們始終認爲人來作這些事情時更可靠。固然，這與他們如今維護的機器數有關的。個人問題是：

1. 自動化運維的好處和壞處分別是？

2. 若是好處多於壞處，如何說服這些人使用「自動化」運維

A:自動化運維的好處是能夠減輕運維的工做量，統一規劃和配置系統頭資源；固然了，線上的資源也有可能去現誤操做的狀況。這個時候就須要一個強大的report系統。其實若是機器到了必定規模，自動化運維就是一個水到渠成的過程，特別是在真正的互聯網公司。

Q:請問下mysql的高可用那種方案比較好？若是主從斷開，如何不影響業務的狀況下，從新作主從？

A:咱們線上用的比較多的方案是DRBD雙機，而後再是主從複製。mysql主從複製斷開也分好多狀況，通常狀況下是不須要重作主從的，除非到了萬不得已的時候。另外，阿里有很多開源方案，建議可參考。

Q:咱們如今產品開發完成後，還會出現後續新需求開發，如今咱們是用的Jenkins作的自動化，從每次代碼提交到自動打包到部署環境上跑測試用例，可是打包過程十分漫長，並且不定時會出錯，因此想問一下，與Jenkins自動化運維相比，這種新的運維方式有哪些優點呢？

A:Jenkins是持續集成，跟自動化運維是屬於兩個不一樣的方向吧。

Q：1.分佈式網站系統，如何 用集羣自動更新代碼和同步代碼（實現那種秒更新的方案？）
2.更新或者升級網站 代碼的 時候， 如何確保 代碼執行不會由於（更新代碼的時候確定有不一致的服務器代碼落後更新）落後更新而形成執行出問題呢？ 

A：咱們是引入自動化運維，好比用fabric工具同時進行git命令操做，同時是幾十臺機器一塊兒操做。 

Q;目前自動化運維，尤爲是將系統資源(CPU\MEM\IO\NETWORK)和中間件(nginx\redis\tomcat)等多方面監控的資源開發該關注哪些點？業務層面的每每是運維方面很差解決的，您怎麼看？

A:恩，好多業務需求須要開發了，並且開發人員並不能真正的設計與開發出來，這個時候就須要運維人員自行開發了，這也是如今有運維開發的緣由，同時也是Python大熱的緣由之一。 

Q：你好，我發現這本書，名稱是 Linux集羣和自動化運維。我想詢問下，大家在生產環境中，採用的是什麼自動化工具，是saltstack，puppet，仍是ansible，大家，在這些自動化工具中進行了二次開發嗎？

A；以前是Puppet，如今主要是Fabric | Ansible，目前不少自動化任務都是二次開發，像ansible也在進一些簡單的二次開發以適應業務須要。

Q:咱們一直用puppet，跟chef，ansible用起來確實比puppet方便不少嗎，我也上網查了一些資料說ansible方便不少？樓主，請問技術轉型到ansible你認爲難度大嗎？我以爲裏面應該仍是有不少坑的，呵呵。請賜教經驗！謝謝！

A:其實還好，Ansible能夠先在測試下部署，等測試得差很少的時候再慢慢的移過來，目前社區和資料挺多的。