<<互聯(lián)網(wǎng)敏捷DevOps和自動(dòng)化之4.運(yùn)維自動(dòng)化>>

<<互聯(lián)網(wǎng)敏捷DevOps和自動(dòng)化之4.運(yùn)維自動(dòng)化>>

隨著信息時(shí)代突飛猛進(jìn)般的持續(xù)發(fā)展,IT運(yùn)維已經(jīng)成為IT服務(wù)中最重要的組成部分。近年來(lái),云計(jì)算、大數(shù)據(jù)等技術(shù)日趨成熟,生產(chǎn)應(yīng)用自動(dòng)化運(yùn)維也被推到了風(fēng)口浪尖。通過(guò)傳統(tǒng)手段對(duì)大型計(jì)算機(jī)集群進(jìn)行運(yùn)維即使是簡(jiǎn)單的日常備份、服務(wù)器狀態(tài)監(jiān)控和報(bào)警,效率也十分低下,因此對(duì)自動(dòng)化運(yùn)維的需求已經(jīng)迫在眉睫。
傳統(tǒng)運(yùn)維的弊端:
1.由人來(lái)發(fā)起運(yùn)維事件,運(yùn)維人員被動(dòng)、效率低。
2.系統(tǒng)異構(gòu)性大,缺乏高效的運(yùn)維流程。
3.隨著云計(jì)算大數(shù)據(jù)的爆發(fā)帶來(lái)更大的困難,極度缺乏一套高效的運(yùn)維工具。
由于這些問(wèn)題的存在,自動(dòng)化應(yīng)該遵循四化原則:管理體系化、工作流程化、人員專業(yè)化、任務(wù)自動(dòng)化。
以監(jiān)控作為自動(dòng)化運(yùn)維的核心概念
運(yùn)維工作效率不高,主要原因是響應(yīng)速度。由于大量的人員長(zhǎng)期盯著報(bào)警頁(yè)面,等待故障,然后通知相應(yīng)人員。所以在生產(chǎn)系統(tǒng)中,需將服務(wù)器的狀態(tài)監(jiān)控作為自動(dòng)化運(yùn)維的核心問(wèn)題。下圖為自動(dòng)化運(yùn)維平臺(tái)處理流程圖,由監(jiān)控來(lái)驅(qū)動(dòng)運(yùn)維事件的發(fā)起、處理和結(jié)束,由ElkStack 、Zabbix 和 Zabbix-Agent來(lái)獲取到服務(wù)器的日常工作狀態(tài)和服務(wù)信息,并生成時(shí)序統(tǒng)計(jì)圖等用于成果分析。


互聯(lián)網(wǎng)公司的運(yùn)維部署架構(gòu) 基本都是以下模式
image.png

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

image.png

image.png

image.png

image.png

image.png

GITLAB https://about.gitlab.com/gitlab-com/
image.png

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容