Devops工具

本文轉自：http://www.javashuo.com/article/p-eyzpavfk-dc.html

什麼是DevOps
DevOps是Development和Operations的組合，是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。它的出現是因爲軟件行業日益清晰地認識到：爲了按時交付軟件產品和服務，開發和運營工做必須緊密合做。

能夠把DevOps看做開發（軟件工程）、技術運營和質量保障（QA）三者的交集。

 

傳統的軟件組織將開發、IT運營和質量保障設爲各自分離的部門。在這種環境下如何採用新的開發方法（例如敏捷軟件開發），這是一個重要的課題：按照從前的工做方式，開發和部署不須要IT支持或者QA深刻的、跨部門的支持，而卻須要極其緊密的多部門協做。然而DevOps考慮的還不止是軟件部署。它是一套針對這幾個部門間溝通與協做問題的流程和方法。

DevOps工具
工欲善其事，必先利其器，如今你們在DevOps領域最關注的仍是在工具層面。

下面是我跟這麼多公司接觸下來，你們使用比較多的工具：

一、監控工具

比較老牌的就是Zabbix,Nagios，用Zabbix的感受是最多的。國內的有小米開源的OpenFalcon。這類監控工具通常是對服務器、服務（中間件，數據庫）作一些經常使用指標的監控。

二、性能分析/APM工具

APM不少時候被認爲是監控的一個細分領域。但在現代複雜分佈式系統架構下，APM工具每每更能準確、直接的幫助用戶定位到性能瓶頸，好比哪個URL訪問慢、哪個方法執行慢、哪個SQL執行慢。在以往要想拿到這些數據，每每得須要比較資深的架構師、DBA一塊兒合做才能拿到這些數據，而定位瓶頸的效率每每還不過高。如今經過APM工具能讓普通技能的運維人員，也很高效的定位到這些深層的問題。如今商用的APM工具很多，國外的有Newrelic，國內知名的就有聽雲、Oneapm、透視寶這些。開源的也有Pinpoint（naver開源）、Zipkin（twitter開源）、CAT（大衆點評開源）.

三、批量+自動化運維工具

這裏就比較多了，知名的有Puppet、Ansible、Chef、Saltstack這些。這些在網上的資料也比較多，找比較新版本的官方文檔看就好了。Puppet和chef是比較早期的工具，受衆面也很大，不過這兩個工具基於ruby實現，如今要找到熟悉ruby的人來作這塊的二次開發可不容易。而ansible和saltstack則相對新生代一些，目前用戶基數增加很快，基於python實現，要找作二次開發的人也相對容易的多。

四、集中日誌分析工具

在一個服務器比較多的環境下，如何集中的管理和分析、查詢日誌，已經變成一個比較強的需求了。想象一下，若是發生了某個錯誤，你還得一臺臺機器去翻日誌文件，是否是很蛋疼。在這個需求驅動下，就誕生了一些集中日誌分析工具。在開源領域，比較知名的就是ELK這一套工具了，涵蓋了日誌採集、上報、搜索、展示這一類基本需求，如今比較多的上規模的企業都用這個，網上資料也大把。核心實現機制都是經過一些日誌採集代理（相似Filebeat）去爬日誌文件，將最新的部分提交到採集服務端，後端再對接搜索引擎，能支持很快速、準確的搜索便可。有一個國內不怎麼知名的Sentry日誌收集服務，比較輕量級，自己是Python作的，與各類語言的日誌框架作了很是好的集成，能夠很方便的集中收集異常日誌，並分配給對應的開發人員。它在github上有10000多個star了，這在DevOps相關的軟件裏，都是排名很是靠前的了。git的地址：GitHub - getsentry/sentry: Sentry is cross-platform crash reporting built with love

五、持續集成/發佈工具

我接觸的人都是用Jenkins的，沒有用其餘的，可能跟我所在的技術圈子有關。集成打包的過程其實通常都比較簡單，配好版本庫和打包腳本就行。但發佈的過程就比較複雜，有些是全量發佈，但也有很是多的IT團隊採用增量發佈。這個方面若是想用工具，仍是得先分析清楚現有的發佈流程，手工狀況下怎麼作，哪些能經過自動化工具來完成。

六、IaaS集成

最近兩年的公有云推廣比較迅速，不少新的服務器採購都被導入到雲上去了。如今主流的公有云都提供了比較完備的API，基於這些API也能夠作一些針對基礎資源的自動化操做，好比遊戲行業的快速開服。

更多的能夠看下知乎上的一篇關於DevOps的文章：<<你所在的公司是如何實施DevOps的？>>

https://www.zhihu.com/question/24413538/answer/116474416