從知乎上看到有一篇針對應(yīng)用運(yùn)維建設(shè)講解的幾個(gè)必備的方面，個(gè)人覺得對運(yùn)維的整體建設(shè)寫的不錯(cuò)，特轉(zhuǎn)載到此收藏參考。方便自己以后從下面幾個(gè)方面參考建設(shè)運(yùn)維體系。

結(jié)合現(xiàn)在云計(jì)算和DevOps的發(fā)展趨勢，我覺得一個(gè)成熟的自動化運(yùn)維平臺應(yīng)該包括以下的特性：一、支持混合云的CMDB現(xiàn)在越來越多的服務(wù)器都轉(zhuǎn)到了云上，而主流的公有云、私有云平臺都擁有比較完備的資源管理的API，這些API也就是構(gòu)建一個(gè)自動化CMDB的基礎(chǔ)。新一代的自動化運(yùn)維平臺應(yīng)該是可以基于這些API來自動維護(hù)和管理相關(guān)的服務(wù)器、存儲、網(wǎng)絡(luò)、負(fù)載均衡的資源的。通過API對資源的操作都應(yīng)該被作為操作日志記錄下來，以備作為后續(xù)操作審計(jì)的基礎(chǔ)數(shù)據(jù)。CMDB這個(gè)東西聽上去是老生常談，但這個(gè)確實(shí)是所有運(yùn)維工具的基礎(chǔ)設(shè)施。而基于開源工具做運(yùn)維平臺最大的麻煩，就是如何在各個(gè)工具之間把CMDB統(tǒng)一起來。CMDB不統(tǒng)一起來，就意味著一旦要增加一臺服務(wù)器，可能要在各個(gè)運(yùn)維工具里面都要同步一下，這個(gè)還是非常折騰滴。。。二、比較完備的監(jiān)控+應(yīng)用性能分析（APM）能支持對平臺的可用性、服務(wù)器的性能、各種服務(wù)（web服務(wù)、應(yīng)用服務(wù)、數(shù)據(jù)庫服務(wù)）的性能進(jìn)行監(jiān)控。做的好一些應(yīng)該能進(jìn)行更深入、或者關(guān)聯(lián)性的性能分析。現(xiàn)在市面上一般都會將資源性能監(jiān)控和應(yīng)用性能監(jiān)控（APM）混合著講，這里面的產(chǎn)品確實(shí)也有很多都是重疊的，兩方面都會涉及到。開源的性能監(jiān)控系統(tǒng)主流有的Zabbix、Nagios，國產(chǎn)的開源監(jiān)控平臺有小米OpenFalcon，但這些基本都只是做基本的資源監(jiān)控（服務(wù)器，磁盤、網(wǎng)絡(luò)等）和簡單的服務(wù)軟件的性能監(jiān)控（中間件，數(shù)據(jù)庫等）。而市面上的APM系統(tǒng)更主打的功能是應(yīng)用性能分析，比如能精確定位到某個(gè)應(yīng)用的URL的訪問速度快慢，某些SQL執(zhí)行速度的快慢，這些對于開發(fā)人員和運(yùn)維人員快速定位問題還是很有幫助的。APM這方面的商業(yè)工具，國外比較主流的有New Reclic、Dynatrace，國內(nèi)的也就是透視寶、Oneapm、聽云等，他們也提供了API進(jìn)行集成。APM這方面的開源工具有pinpoint（一個(gè)韓國團(tuán)隊(duì)開源的），zipkin（twitter開源），cat（大眾點(diǎn)評開源）。三、有一個(gè)還不錯(cuò)UI的批量運(yùn)維工具在業(yè)務(wù)發(fā)展比較快的情況下，從幾臺服務(wù)器，到幾十臺服務(wù)器，再到幾百臺服務(wù)器，批量運(yùn)維的需求很自然就產(chǎn)生了，老板也希望越少的人干越多的活。現(xiàn)在也有不少開源的批量運(yùn)維工具，也都比較成熟了，比如puppet、chef、ansible、saltstack。puppet和chef都是ruby做的，實(shí)話實(shí)說，ruby的熟手市面上很少，比python不是難招一點(diǎn)。我個(gè)人比較推薦使用ansible或者saltstack，這兩個(gè)系統(tǒng)都是python寫的，代碼質(zhì)量和社區(qū)活躍度都挺不錯(cuò)的。ansible有官方的web ui——Tower，但實(shí)話實(shí)說不好用，所以我們也在重新做一套自己用起來更順手的WEBUI。四、日志集中分析工具線上系統(tǒng)最常規(guī)的問題定位方式，就是日志分析了。隨著服務(wù)器的增多，日志的分析定位也成為一個(gè)難點(diǎn)和痛點(diǎn)（想象一下，系統(tǒng)出故障之后，要去幾十甚至數(shù)百個(gè)節(jié)點(diǎn)去上去查日志，是有多折騰）。國內(nèi)有一家叫日志易的公司，是專門做日志分析方面的運(yùn)維工具的。另外還有一家log insight，也是做這個(gè)領(lǐng)域，但產(chǎn)品好像還處于beta階段。日志分析這個(gè)領(lǐng)域現(xiàn)在是一個(gè)熱點(diǎn)，現(xiàn)在的開源方案也比較多了，比如著名的ELKStack，還有Flume+Kafka+Storm的體系。上面這兩個(gè)方案相對重一些，部署比較復(fù)雜，網(wǎng)上介紹的文章也不少。比較輕量級的開源日志集中采集方案有python做的Sentry，他是通過改造各種語言的日志采集框架來實(shí)現(xiàn)日志的集中采集，各種主流的開發(fā)語言的日志框架都支持得很完整了，比如java的log4j和logpack。Sentry的官網(wǎng)在此：Sentry - Track exceptions with modern error logging for Javascript,Python, Ruby, Java, and Node.js五、持續(xù)集成和發(fā)布工具這方面其實(shí)比較難有統(tǒng)一的需求，很多公司集成發(fā)布的做法都差異挺大的。持續(xù)集成方面，一般用jekins的比較多，這方面網(wǎng)上介紹的文章也很多。而如何把打好的包發(fā)布至各臺服務(wù)器，則可以通過批量運(yùn)維工具或者腳本來完成了。版本發(fā)布的過程涉及到很多細(xì)節(jié)，包括了版本文件的上傳、分發(fā)、版本管理、回滾等各種操作。對于一般不太復(fù)雜的項(xiàng)目，我比較推薦的做法是把打包好的文件上傳到svn上，然后通過腳本在各臺服務(wù)器上進(jìn)行發(fā)布操作就行了，這樣其實(shí)是利用了SVN來完成文件的上傳、分發(fā)、版本管理、回滾等各種操作。六、安全漏洞掃描工具現(xiàn)在一個(gè)稍微有點(diǎn)知名度的系統(tǒng)，都會遭受各種各樣的安全攻擊的折磨。一般的公司不太可能請得起專職的安全工程師，所以運(yùn)維工程師最好能自己借助一些安全掃描工具來發(fā)現(xiàn)自己系統(tǒng)的漏洞。安全工具方面我了解不多，不太熟這個(gè)領(lǐng)域的開源工具。之前烏云網(wǎng)推出過一個(gè)SaaS化的漏掃平臺——唐朝巡航，有對外提供漏洞掃描的API，不過最近烏云網(wǎng)一直在升級，所以也就暫時(shí)無法調(diào)用了。個(gè)人覺得，如果上述功能都有了，基本上大部分中小規(guī)模企業(yè)的日常運(yùn)維工作的高頻操作都覆蓋到了。如果是比較大的互聯(lián)網(wǎng)企業(yè)，或者還有一些特殊的業(yè)務(wù)需求，那就具體問題具體分析了。