雲計算背景下的自動化運維體系

結合如今雲計算和DevOps的發展趨勢，我以爲一個成熟的自動化運維平臺應該包括如下的特性：

1、支持混合雲的CMDB如今愈來愈多的服務器都轉到了雲上，而主流的公有云、私有云平臺都擁有比較完備的資源管理的API，這些API也就是構建一個自動化CMDB的基礎。

新一代的自動化運維平臺應該是能夠基於這些API來自動維護和管理相關的服務器、存儲、網絡、負載均衡的資源的。經過API對資源的操做都應該被做爲操做日誌記錄下來，以備做爲後續操做審計的基礎數據。CMDB這個東西聽上去是老生常談，但這個確實是全部運維工具的基礎設施。而基於開源工具作運維平臺最大的麻煩，就是如何在各個工具之間把CMDB統一塊兒來。CMDB不統一塊兒來，就意味着一旦要增長一臺服務器，可能要在各個運維工具裏面都要同步一下，這個仍是很是折騰滴。。。

2、比較完備的監控+應用性能分析（APM）能支持對平臺的可用性、服務器的性能、各類服務（web服務、應用服務、數據庫服務）的性能進行監控。
作的好一些應該能進行更深刻、或者關聯性的性能分析。

如今市面上通常都會將資源性能監控和應用性能監控（APM）混合着講，這裏面的產品確實也有不少都是重疊的，兩方面都會涉及到。開源的性能監控系統主流有的Zabbix、Nagios，國產的開源監控平臺有小米OpenFalcon，但這些基本都只是作基本的資源監控（服務器，磁盤、網絡等）和簡單的服務軟件的性能監控（中間件，數據庫等）。而市面上的APM系統更主打的功能是應用性能分析，好比能精肯定位到某個應用的URL的訪問速度快慢，某些SQL執行速度的快慢，這些對於開發人員和運維人員快速定位問題仍是頗有幫助的。APM這方面的商業工具，國外比較主流的有New Reclic、Dynatrace，國內的也就是透視寶、Oneapm、聽雲等，他們也提供了API進行集成。APM這方面的開源工具備pinpoint（一個韓國團隊開源的），zipkin（twitter開源），cat（大衆點評開源）。

3、有一個還不錯UI的批量運維工具在業務發展比較快的狀況下，從幾臺服務器，到幾十臺服務器，再到幾百臺服務器，批量運維的需求很天然就產生了，老闆也但願越少的人幹越多的活。
如今也有很多開源的批量運維工具，也都比較成熟了，好比puppet、chef、ansible、saltstack。puppet和chef都是ruby作的，實話實說，ruby的熟手市面上不多，比python不是難招一點。我我的比較推薦使用ansible或者saltstack，這兩個系統都是python寫的，代碼質量和社區活躍度都挺不錯的。ansible有官方的web ui——Tower，但實話實說很差用，因此咱們也在從新作一套本身用起來更順手的WEB UI。

 

4、日誌集中分析工具線上系統最常規的問題定位方式，就是日誌分析了。隨着服務器的增多，日誌的分析定位也成爲一個難點和痛點（想象一下，系統出故障以後，要去幾十甚至數百個節點去上去查日誌，是有多折騰）。國內有一家叫日誌易的公司，是專門作日誌分析方面的運維工具的。另外還有一家log insight，也是作這個領域，但產品好像還處於beta階段。日誌分析這個領域如今是一個熱點，如今的開源方案也比較多了，好比著名的ELKStack，還有Flume+Kafka+Storm的體系。上面這兩個方案相對重一些，部署比較複雜，網上介紹的文章也很多。比較輕量級的開源日誌集中採集方案有python作的Sentry，他是經過改造各類語言的日誌採集框架來實現日誌的集中採集，各類主流的開發語言的日誌框架都支持得很完整了，好比java的log4j和logpack。

 

5、持續集成和發佈工具這方面其實比較難有統一的需求，不少公司集成發佈的作法都差別挺大的。
持續集成方面，通常用jenkins的比較多，這方面網上介紹的文章也不少。而如何把打好的包發佈至各臺服務器，則能夠經過批量運維工具或者腳原本完成了。版本發佈的過程涉及到不少細節，包括了版本文件的上傳、分發、版本管理、回滾等各類操做。對於通常不太複雜的項目，我比較推薦的作法是把打包好的文件上傳到svn上，而後經過腳本在各臺服務器上進行發佈操做就好了，這樣實際上是利用了SVN來完成文件的上傳、分發、版本管理、回滾等各類操做。

6、安全漏洞掃描工具如今一個稍微有點知名度的系統，都會遭受各類各樣的安全攻擊的折磨。通常的公司不太可能請得起專職的安全工程師，因此運維工程師最好能本身藉助一些安全掃描工具來發現本身系統的漏洞。安全工具方面我瞭解很少，不太熟這個領域的開源工具。以前烏雲網推出過一個SaaS化的漏掃平臺——唐朝巡航，有對外提供漏洞掃描的API，不過最近烏雲網一直在升級，因此也就暫時沒法調用了。