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

隨著信息時代突飛猛進般的持續(xù)發(fā)展惭蹂，IT運維已經(jīng)成為IT服務(wù)中最重要的組成部分槽地。近年來烧栋，云計算斟珊、大數(shù)據(jù)等技術(shù)日趨成熟苇倡，生產(chǎn)應(yīng)用自動化運維也被推到了風(fēng)口浪尖。通過傳統(tǒng)手段對大型計算機集群進行運維即使是簡單的日常備份囤踩、服務(wù)器狀態(tài)監(jiān)控和報警旨椒，效率也十分低下，因此對自動化運維的需求已經(jīng)迫在眉睫堵漱。
傳統(tǒng)運維的弊端：
1.由人來發(fā)起運維事件综慎，運維人員被動、效率低勤庐。
2.系統(tǒng)異構(gòu)性大示惊，缺乏高效的運維流程。
3.隨著云計算大數(shù)據(jù)的爆發(fā)帶來更大的困難埃元，極度缺乏一套高效的運維工具涝涤。
由于這些問題的存在，自動化應(yīng)該遵循四化原則：管理體系化岛杀、工作流程化阔拳、人員專業(yè)化、任務(wù)自動化类嗤。
以監(jiān)控作為自動化運維的核心概念
運維工作效率不高糊肠，主要原因是響應(yīng)速度。由于大量的人員長期盯著報警頁面遗锣，等待故障货裹，然后通知相應(yīng)人員。所以在生產(chǎn)系統(tǒng)中精偿，需將服務(wù)器的狀態(tài)監(jiān)控作為自動化運維的核心問題弧圆。下圖為自動化運維平臺處理流程圖赋兵，由監(jiān)控來驅(qū)動運維事件的發(fā)起、處理和結(jié)束搔预，由ElkStack 霹期、Zabbix 和 Zabbix-Agent來獲取到服務(wù)器的日常工作狀態(tài)和服務(wù)信息，并生成時序統(tǒng)計圖等用于成果分析拯田。

image.png

結(jié)合現(xiàn)在云計算和DevOps的發(fā)展趨勢历造，我覺得一個成熟的自動化運維平臺應(yīng)該包括以下的特性：一、支持混合云的CMDB現(xiàn)在越來越多的服務(wù)器都轉(zhuǎn)到了云上船庇，而主流的公有云吭产、私有云平臺都擁有比較完備的資源管理的API，這些API也就是構(gòu)建一個自動化CMDB的基礎(chǔ)鸭轮。新一代的自動化運維平臺應(yīng)該是可以基于這些API來自動維護和管理相關(guān)的服務(wù)器臣淤、存儲、網(wǎng)絡(luò)张弛、負(fù)載均衡的資源的荒典。通過API對資源的操作都應(yīng)該被作為操作日志記錄下來，以備作為后續(xù)操作審計的基礎(chǔ)數(shù)據(jù)吞鸭。
CMDB這個東西聽上去是老生常談寺董，但這個確實是所有運維工具的基礎(chǔ)設(shè)施。而基于開源工具做運維平臺最大的麻煩刻剥，就是如何在各個工具之間把CMDB統(tǒng)一起來遮咖。CMDB不統(tǒng)一起來，就意味著一旦要增加一臺服務(wù)器造虏，可能要在各個運維工具里面都要同步一下御吞，這個還是非常折騰滴。漓藕。陶珠。
二、比較完備的監(jiān)控+應(yīng)用性能分析（APM）能支持對平臺的可用性享钞、服務(wù)器的性能揍诽、各種服務(wù)（web服務(wù)、應(yīng)用服務(wù)栗竖、數(shù)據(jù)庫服務(wù)）的性能進行監(jiān)控暑脆。做的好一些應(yīng)該能進行更深入、或者關(guān)聯(lián)性的性能分析狐肢。
現(xiàn)在市面上一般都會將資源性能監(jiān)控和應(yīng)用性能監(jiān)控（APM）混合著講添吗，這里面的產(chǎn)品確實也有很多都是重疊的，兩方面都會涉及到份名。
開源的性能監(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)用性能分析，比如能精確定位到某個應(yīng)用的URL的訪問速度快慢丧没，某些SQL執(zhí)行速度的快慢鹰椒，這些對于開發(fā)人員和運維人員快速定位問題還是很有幫助的。APM這方面的商業(yè)工具呕童，國外比較主流的有New Reclic漆际、Dynatrace，國內(nèi)的也就是透視寶夺饲、Oneapm奸汇、聽云等，他們也提供了API進行集成往声。APM這方面的開源工具有pinpoint（一個韓國團隊開源的）擂找，zipkin（twitter開源），cat（大眾點評開源）浩销。
三贯涎、有一個還不錯UI的批量運維工具在業(yè)務(wù)發(fā)展比較快的情況下，從幾臺服務(wù)器慢洋，到幾十臺服務(wù)器塘雳，再到幾百臺服務(wù)器，批量運維的需求很自然就產(chǎn)生了普筹，老板也希望越少的人干越多的活败明。
現(xiàn)在也有不少開源的批量運維工具，也都比較成熟了太防，比如puppet妻顶、chef、ansible杏头、saltstack盈包。puppet和chef都是ruby做的，實話實說醇王，ruby的熟手市面上很少呢燥，比python不是難招一點。
我個人比較推薦使用ansible或者saltstack寓娩，這兩個系統(tǒng)都是python寫的叛氨，代碼質(zhì)量和社區(qū)活躍度都挺不錯的呼渣。ansible有官方的web ui——Tower，但實話實說不好用寞埠，所以我們也在重新做一套自己用起來更順手的WEB UI屁置。
四、日志集中分析工具線上系統(tǒng)最常規(guī)的問題定位方式仁连，就是日志分析了蓝角。隨著服務(wù)器的增多，日志的分析定位也成為一個難點和痛點（想象一下饭冬，系統(tǒng)出故障之后使鹅，要去幾十甚至數(shù)百個節(jié)點去上去查日志，是有多折騰）昌抠。
國內(nèi)有一家叫日志易的公司患朱，是專門做日志分析方面的運維工具的。另外還有一家log insight炊苫，也是做這個領(lǐng)域裁厅，但產(chǎn)品好像還處于beta階段。
日志分析這個領(lǐng)域現(xiàn)在是一個熱點侨艾，現(xiàn)在的開源方案也比較多了执虹，比如著名的ELKStack，還有Flume+Kafka+Storm的體系蒋畜。上面這兩個方案相對重一些声畏，部署比較復(fù)雜，網(wǎng)上介紹的文章也不少姻成。
比較輕量級的開源日志集中采集方案有python做的Sentry插龄，他是通過改造各種語言的日志采集框架來實現(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ā)布工具這方面其實比較難有統(tǒng)一的需求才睹，很多公司集成發(fā)布的做法都差異挺大的徘跪。持續(xù)集成方面，一般用jekins的比較多琅攘，這方面網(wǎng)上介紹的文章也很多垮庐。
而如何把打好的包發(fā)布至各臺服務(wù)器，則可以通過批量運維工具或者腳本來完成了坞琴。版本發(fā)布的過程涉及到很多細(xì)節(jié)哨查，包括了版本文件的上傳、分發(fā)剧辐、版本管理寒亥、回滾等各種操作邮府。對于一般不太復(fù)雜的項目，我比較推薦的做法是把打包好的文件上傳到svn上溉奕，然后通過腳本在各臺服務(wù)器上進行發(fā)布操作就行了褂傀，這樣其實是利用了SVN來完成文件的上傳、分發(fā)加勤、版本管理仙辟、回滾等各種操作。
六胸竞、安全漏洞掃描工具現(xiàn)在一個稍微有點知名度的系統(tǒng)欺嗤，都會遭受各種各樣的安全攻擊的折磨。一般的公司不太可能請得起專職的安全工程師卫枝，所以運維工程師最好能自己借助一些安全掃描工具來發(fā)現(xiàn)自己系統(tǒng)的漏洞。安全工具方面我了解不多讹挎，不太熟這個領(lǐng)域的開源工具校赤。
Git Web Portal URL address --->
GOGS http://www.reibang.com/p/424627516ef6 https://gogs.io/

image.png

image.png

image.png

image.png

image.png

image.png