應用系統運維建設必備的幾個方面
從知乎上看到有一篇針對應用運維建設講解的幾個必備的方面，個人覺得對運維的整體建設寫的不錯，特轉載到此收藏參考。方便自己以後從下面幾個方面參考建設運維體系。
結合現在雲端計算和DevOps的發展趨勢，我覺得一個成熟的自動化運維平臺應該包括以下的特性：一、支援混合雲的CMDB現在越來越多的伺服器都轉到了雲上，而主流的公有云、私有云平臺都擁有比較完備的資源管理的API，這些API也就是構建一個自動化CMDB的基礎。新一代的自動化運維平臺應該是可以基於這些API來自動維護和管理相關的伺服器、儲存、網路、負載均衡的資源的。通過API對資源的操作都應該被作為操作日誌記錄下來，以備作為後續操作審計的基礎資料。
CMDB這個東西聽上去是老生常談，但這個確實是所有運維工具的基礎設施。而基於開源工具做運維平臺最大的麻煩，就是如何在各個工具之間把CMDB統一起來。
CMDB不統一起來，就意味著一旦要增加一臺伺服器，可能要在各個運維工具裡面都要同步一下，這個還是非常折騰滴。。。二、比較完備的監控+應用效能分析（APM）能支援對平臺的可用性、伺服器的效能、各種服務（web服務、應用服務、資料庫服務）的效能進行監控。做的好一些應該能進行更深入、或者關聯性的效能分析。現在市面上一般都會將資源效能監控和應用效能監控（APM）混合著講，這裡面的產品確實也有很多都是重疊的，兩方面都會涉及到。開源的效能監控系統主流有的Zabbix
APM這方面的商業工具，國外比較主流的有New Reclic、Dynatrace，國內的也就是透視寶、Oneapm、聽雲等，他們也提供了API進行整合。
APM這方面的開源工具有pinpoint（一個韓國團隊開源的），zipkin（twitter開源），cat
puppet和chef都是ruby做的，實話實說，ruby的熟手市面上很少，比python不是難招一點。我個人比較推薦使用ansible或者saltstack，這兩個系統都是python寫的，程式碼質量和社群活躍度都挺不錯的。
ansible有官方的web ui——Tower，但實話實說不好用，所以我們也在重新做一套自己用起來更順手的WEBUI。四、日誌集中分析工具線上系統最常規的問題定位方式，就是日誌分析了。隨著伺服器的增多，日誌的分析定位也成為一個難點和痛點（想象一下，系統出故障之後，要去幾十甚至數百個節點去上去查日誌，是有多折騰）。國內有一家叫日誌易的公司，是專門做日誌分析方面的運維工具的。另外還有一家log insight，也是做這個領域，但產品好像還處於beta階段。日誌分析這個領域現在是一個熱點，現在的開源方案也比較多了，比如著名的ELKStack，還有Flume+Kafka+Storm的體系。上面這兩個方案相對重一些，部署比較複雜，網上介紹的文章也不少。比較輕量級的開源日誌集中採集方案有python做的Sentry，他是通過改造各種語言的日誌採集框架來實現日誌的集中採集，各種主流的開發語言的日誌框架都支援得很完整了，比如java的log4j和logpack。
Sentry的官網在此：五、持續整合和釋出工具這方面其實比較難有統一的需求，很多公司整合釋出的做法都差異挺大的。持續整合方面，一般用jekins的比較多，這方面網上介紹的文章也很多。而如何把打好的包釋出至各臺伺服器，則可以通過批量運維工具或者指令碼來完成了。版本釋出的過程涉及到很多細節，包括了版本檔案的上傳、分發、版本管理、回滾等各種操作。對於一般不太複雜的專案，我比較推薦的做法是把打包好的檔案上傳到svn上，然後通過指令碼在各臺伺服器上進行釋出操作就行了，這樣其實是利用了SVN來完成檔案的上傳、分發、版本管理、回滾等各種操作。六、安全漏洞掃描工具現在一個稍微有點知名度的系統，都會遭受各種各樣的安全攻擊的折磨。一般的公司不太可能請得起專職的安全工程師，所以運維工程師最好能自己藉助一些安全掃描工具來發現自己系統的漏洞。安全工具方面我瞭解不多，不太熟這個領域的開源工具。之前烏雲網推出過一個SaaS化的漏掃平臺——唐朝巡航，有對外提供漏洞掃描的API，不過最近烏雲網一直在升級，所以也就暫時無法呼叫了。個人覺得，如果上述功能都有了，基本上大部分中小規模企業的日常運維工作的高頻操作都覆蓋到了。如果是比較大的網際網路企業，或者還有一些特殊的業務需求，那就具體問題具體分析了。