一個成熟的自動化運維繫統具備什麼功能?
一個成熟的自動化運維繫統都具備哪些功能,能實現什麼需求?
2016年了再來回答這個問題。。。
結合現在雲計算和DevOps的發展趨勢,我覺得一個成熟的自動化運維平台應該包括以下的特性:
一、支持混合雲的CMDB現在越來越多的伺服器都轉到了雲上,而主流的公有雲、私有雲平台都擁有比較完備的資源管理的API,這些API也就是構建一個自動化CMDB的基礎。新一代的自動化運維平台應該是可以基於這些API來自動維護和管理相關的伺服器、存儲、網路、負載均衡的資源的。
通過API對資源的操作都應該被作為操作日誌記錄下來,以備作為後續操作審計的基礎數據。CMDB這個東西聽上去是老生常談,但這個確實是所有運維工具的基礎設施。
而基於開源工具做運維平台最大的麻煩,就是如何在各個工具之間把CMDB統一起來。CMDB不統一起來,就意味著一旦要增加一台伺服器,可能要在各個運維工具裡面都要同步一下,這個還是非常折騰滴。。。二、比較完備的監控+應用性能分析(APM)
能支持對平台的可用性、伺服器的性能、各種服務(web服務、應用服務、資料庫服務)的性能進行監控。做的好一些應該能進行更深入、或者關聯性的性能分析。現在市面上一般都會將資源性能監控和應用性能監控(APM)混合著講,這裡面的產品確實也有很多都是重疊的,兩方面都會涉及到。
開源的性能監控系統主流有的Zabbix、Nagios,國產的開源監控平台有小米OpenFalcon,但這些基本都只是做基本的資源監控(伺服器,磁碟、網路等)和簡單的服務軟體的性能監控(中間件,資料庫等)。
而市面上的APM系統更主打的功能是應用性能分析,比如能精確定位到某個應用的URL的訪問速度快慢,某些SQL執行速度的快慢,這些對於開發人員和運維人員快速定位問題還是很有幫助的。
APM這方面的商業工具,國外比較主流的有New Reclic、Dynatrace,國內的也就是透視寶、Oneapm、聽雲等,他們也提供了API進行集成。
APM這方面的開源工具有pinpoint(一個韓國團隊開源的),zipkin(twitter開源),cat(大眾點評開源)。三、有一個還不錯UI的批量運維工具
在業務發展比較快的情況下,從幾台伺服器,到幾十台伺服器,再到幾百台伺服器,批量運維的需求很自然就產生了,老闆也希望越少的人干越多的活。現在也有不少開源的批量運維工具,也都比較成熟了,比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的,實話實說,ruby的熟手市面上很少,比python不是難招一點。我個人比較推薦使用ansible或者saltstack,這兩個系統都是python寫的,代碼質量和社區活躍度都挺不錯的。
ansible有官方的web ui——Tower,但實話實說不好用,所以我們也在重新做一套自己用起來更順手的WEB UI。四、日誌集中分析工具
線上系統最常規的問題定位方式,就是日誌分析了。隨著伺服器的增多,日誌的分析定位也成為一個難點和痛點(想像一下,系統出故障之後,要去幾十甚至數百個節點去上去查日誌,是有多折騰)。
國內有一家叫日誌易的公司,是專門做日誌分析方面的運維工具的。
另外還有一家log insight,也是做這個領域,但產品好像還處於beta階段。日誌分析這個領域現在是一個熱點,現在的開源方案也比較多了,比如著名的ELKStack,還有Flume+Kafka+Storm的體系。
上面這兩個方案相對重一些,部署比較複雜,網上介紹的文章也不少。比較輕量級的開源日誌集中採集方案有python做的Sentry,他是通過改造各種語言的日誌採集框架來實現日誌的集中採集,各種主流的開發語言的日誌框架都支持得很完整了,比如java的log4j和logpack。
Sentry的官網在此:Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js五、持續集成和發布工具
這方面其實比較難有統一的需求,很多公司集成發布的做法都差異挺大的。持續集成方面,一般用jekins的比較多,這方面網上介紹的文章也很多。而如何把打好的包發布至各台伺服器,則可以通過批量運維工具或者腳本來完成了。
版本發布的過程涉及到很多細節,包括了版本文件的上傳、分發、版本管理、回滾等各種操作。對於一般不太複雜的項目,我比較推薦的做法是把打包好的文件上傳到svn上,然後通過腳本在各台伺服器上進行發布操作就行了,這樣其實是利用了SVN來完成文件的上傳、分發、版本管理、回滾等各種操作。六、安全漏洞掃描工具
現在一個稍微有點知名度的系統,都會遭受各種各樣的安全攻擊的折磨。一般的公司不太可能請得起專職的安全工程師,所以運維工程師最好能自己藉助一些安全掃描工具來發現自己系統的漏洞。安全工具方面我了解不多,不太熟這個領域的開源工具。之前烏雲網推出過一個SaaS化的漏掃平台——唐朝巡航,有對外提供漏洞掃描的API,不過最近烏雲網一直在升級,所以也就暫時無法調用了。個人覺得,如果上述功能都有了,基本上大部分中小規模企業的日常運維工作的高頻操作都覆蓋到了。如果是比較大的互聯網企業,或者還有一些特殊的業務需求,那就具體問題具體分析了。一個成熟的自動化運維繫統至少應該包括三個子系統:
- 機房設備數據系統 (EMDB)
- 錄入機房伺服器和網路設備的各種信息,比如機器型號,硬碟大小,OS類型,所屬應用,運行狀態,機房名稱,所在房間,機架,位置等等各種信息,這是一個最基礎的資料庫,最主要的目的是給每個機器從多個維度統一打上各種標籤,方便其他系統的使用。
- 提供各種查詢API介面,並做好許可權控制。目的是能夠被上層的各種系統調用,一般是rest介面,xml介面。然後基於各種語言做相應的封裝庫。
- 應用監控系統(Appmonitor)
- 一個統一的數據採集模塊,用於採集設備運行信息,包括磁碟IO,網路流量,CPU利用率,網路設備的Session數,PPS。這個採集模塊在網路設備上一般可以通過snmp來實現,在伺服器上一般通過一個定製化的Agent來實現,這個Agent最基礎的能力是採集伺服器運行數據,最重要的是能執行各種腳本語言並通過腳本語言實現對伺服器的各種操作(如更改配置,分析應用日誌並輸出結果)。
- 監控數據存儲與可視化,數據採集模塊採集到各種數據會很多,但對事務性沒啥要求,可以用各種NoSQL資料庫如Hbase,Cassandra等來實現。數據的可視化是一個可以做的很深且偏應用層面的東西,一般在監控系統上只實現最基本的曲線圖展示,提供按時段選擇和對比的功能,其他複雜的可視化操作通過各種API來實現。
- 監控項添加和報警通知,監控項是一種層次結構,而不是列表結構。上層節點的配置能夠被下層節點的配置覆蓋掉。對網路設備來說監控項就是一些不同的oid。藉助於底層的數據採集模塊,對伺服器來說監控項基本上就是一個腳本。可以分為標準監控項和自定義監控項,標準監控項最大化的通用,實現cpu,內存,磁碟,網路等信息的監控。自定義監控項可以用多種系統管理腳本語言(shell,python,perl)等實現,腳本的輸出符合一定規範即可,一般採用行結構或json串。每個監控項設定warn,crit報警閾值和若干報警聯繫人,閾值一般是數值型,特殊的可以是字元串。超過閾值的監控項會發送報警給聯繫人,報警可以通過簡訊,郵件,IM軟體發出。報警發送要支持合併報警,頻率控制,關閉報警。要不然可能一次小故障就能發出成千上萬條報警,報警就失去效果了。
- 監控Api介面,並做好許可權控制。做法和目的與EMDB一樣。開放監控數據獲取,報警消息發送,配置推送的介面。主要目的是讓監控系統裡面的數據能夠被外界利用,可以在這些數據基礎上做更加絢麗複雜的數據可視化工作,或者做一些更加個性化的監控和報警。次要目的是支持對伺服器的統一操作,比如公司所有機器統一升級系統軟體的版本。建議統一操作的API介面僅對少數幾個人開放,並且許可權嚴格控制。
- 發布和線上配置管理系統(ReleaseManager)
- 應用發布和依賴庫版本管理,應用發布是運維與開發對接的重要環節,一般發布系統會和svn系統緊密結合,svn系統裡面會有線上應用的列表,EMDB裡面會有各個機器所屬的應用。發布系統會用到這些數據,將svn系統裡面生成的應用包及其依賴包發布到線上,並且自身對這些應用包和依賴包進行版本管理和控制,在應用發布出現問題時可以回滾到上一個版本。
- 線上配置管理,類似於linux下puppet的功能,主要用於應用伺服器上關鍵配置文件的版本控制,分發,一致性維護工作。大應用一般是若干台伺服器組成集群提供服務,要求這若干台伺服器的應用配置是一致的,但有時候又存在應用的灰度發布操作,或者某人誤更改配置。線上配置管理系統要求提供統一的配置修改入口,對灰度發布提供支持,同時對於誤更改配置情況進行糾正。執行操作可以藉助於Appmonitor的介面。
以這三個系統為基礎可以做更多的自動化工作,比如說財務人員可以用EMDB裡面的數據準確的計算CapexOpex,機房管理人員可以用EMDB通過OOB遠程執行各種關機,重裝系統,網路設備維護等工作,不在現場也能管理機器,現場工作可以外包完成。應用開發人員可以通過svn系統調用Releasemanager自主打包,發布,回滾應用。應用維護人員可以調用監控系統獲取數據和報警信息,通過編寫相關腳本,實現一些簡單報警的自動化處理工作,提升效率。
1、批量安裝IT改造過的Windows Server的iso。
2、可以把機器自動入域,然後分到指定的類下面。
3、可以根據配置文件(基本上還是基於pattern matching)來確定一類機器到底要裝什麼樣的軟體和服務。
4、監控每一個服務。如果服務掛了重啟服務,重啟了幾次還不行重啟系統,重啟了系統還不行重裝系統,重裝了系統還不行,就把機器從集群里斷開,然後自動撥打電話叫自己的人來看,如果哪個傻逼敢不接電話還可以自動群發郵件給別人告訴大家他沒接電話(嗯,我們就是這麼乾的,效果特別好)。
5、收集每一個服務和對應的監控服務的信息,讓有許可權的人可以在界面上查看有沒有什麼機器上的什麼服務出了問題,監控到嚴重問題(基本是監控服務要做的,這個框架顯然不能自己確定什麼問題是嚴重問題)的話打電話(見4)。
6、安裝服務的時候,可以自動從source control裡面抓下來編譯,這樣可以記錄每一台機器上的服務到底是什麼版本。
7、不管是更新Windows還是更新服務,都要在update domain裡面挨個完成,有助於在迅速更新集群的情況下不暫停任何服務的工作。根據你的配置文件的具體情況,這可能是一個動態規劃問題。
上面基本上是可以想到的主要功能。總之,只要程序員提供服務軟體和監控服務軟體,然後給你配置,剩下的事情都應該在無人監控的情況下自動完成。這樣所有的程序員同時都是網管,不需要任何專門的網管來幫你管理軟體方面的問題。
當然,類似於機房漏了水什麼的,還得讓IT來干。
當然是做到自動化運維了。分享一下 @張虎 在2014 ECUG 大會上講到的 基於Ansible的自動化運維實踐 講稿在此 Sina Visitor System
裡面提到了基礎設施分配過程很廉價,彈性擴容、灰度十分便利,兩者結合形成了彈性預算的必要條件。如何通過監控系統在各個模塊、各個組件達到一定的基準線之後,不選擇人工干預,而是啟動自動運維過程。演講里關於 Ansible 的實例演示很詳細,列舉了實戰產品每天 playbook 執行的命令,值得題主參考。運維分兩塊,一塊是技術方面,另一塊則是管理。 技術是發現、處理,保障運行;管理則時如何分配資源和人力,優化流程,儘快恢復以及未雨綢繆。 技術樓上已經說的很全了,在管理上比較流行的是ITIL 和ITSM 。
ITIL_百度百科ITSM_百度百科
而ITIL思想需要落地,至於落地工具我推薦:
http://www.chinae8.net
這有幾個運維自動化的項目,有興趣的話可以看看Devops Pro
直接抄襲opsware 和bladelogic就是了,本就不是多先進的東西。
- Asset management (where"s server with serial number XXXXX?)
- OS provision
- PXE installation
- disk partition
- monitoring
- hardware status monitoring (harddisk, RAID card battery etc.)
- system level monitoring (load, disk IO, disk ops/s, memory usage, packet loss/error)
- application status monitoring (depend on your application)
- configuration management
- system level configuration (hostname, DNS servers, domain name)
- software deployment (JDK for JVM based applications, Apache installation etc.)
- Automatic application deployment (allow for auto release and easy rollback)
自動化運維主要是讓簡單的工作程序化,讓重複的工作自動化。是一組將靜態的設備結構轉化為根據IT服務需求動態彈性響應的策略,目的就是實現IT運維的質量,降低成本。可以說自動化一定是IT運維最高層面的重要屬性之一,但不是全部。
行雲管家自動化運維工具有以下幾大功能,但不是全部:
1、豐富的預設腳本庫,輕鬆搞定運維腳本:預設業界知名的SaltStack腳本庫,兼容各大平台,功能強大,擴展性高,這些腳本庫足以滿足您日常運維的需求,您也可以發揮自己的智慧,編寫適合自己業務場景的新腳本
2、腳本/命令批量執行,降低海量主機運維複雜度:同時對海量主機批量執行腳本/命令,提高運維工作效率,再多主機也不怕
3、文件批量分發,系統更新升級更簡單:在對大量主機進行系統升級,更新補丁等業務場景中,利用行雲管家文件分發功能,將所需文件批量發送到所有主機,一鍵完成更新升級過程
4、文件批量收集,一鍵提取不同主機的同類文件:文件收集功能可將分散在大量主機上的某類文件收集到指定位置,適合分散式系統日誌分析等業務場景
5:任務編排,運維過程徹底自動化:將複雜的作業節點編排成任務,設定觸發條件和時間,滿足您更為靈活的應用場景。例如定期的巡檢任務,只需設置好執行的時間和業務節點,自動執行,無需人工干預
還有更多的自動化運維功能,這個頁面有更詳細的介紹:傳送門---&>行雲管家自動化運維
怒答一發,今年上線的EASYOPS竟然沒人提。一個成熟的自動化運維繫統應該具備的功能,你喜歡的樣子它都有,哈哈。進入正題。
EasyOps 是優維科技研發的具有自主知識產權且行業領先的智能化運維管理平台。能夠幫助各個企業快速的去構建內部的技術管理流程、建立技術服務標準、並形成可靠的IT支撐能力,並最終通過我們的平台來實現IT服務技術的核心競爭力的打造。 實現了運維的能力從基礎設施到業務的閉環,也實現了多運維角色的能力集中管理。
從產品的核心能力角度來說,優維科技EasyOps由四大部分組成:
1) IT資源管理,即CMDB。優維的CMDB主要有以下三大特色:
2) 自動化一切即持續交付(DevOps理念的實踐運用),主要包括以下三大功能特色:
3) 立體化的智能監控平台:提供從採集、發現、分析、定位、解決和預防的監控能力環。具體包括端到端監控、應用健康度監控、全局數據的監控。除此之外EasyOps的智能告警功能,形成從告警發現到告警解決再到告警優化的能力閉環。
4) IT運營分析平台,數據化一切。
EasyOps 是一個面向運維的大數據採集和分析支撐平台,它通過可視化的平台能力,簡化了數據處理過程中的各種複雜編程需求,使每個運維人員都能夠有效的收集和處理運營數據,並積累業務分析能力。目前平台的版本主要提供了容量管理和可用性管理兩個功能。提供基於數據的優化決策能力;使數據場景化、可視化、產品化。
一個成熟的運維體系的沉澱必然經歷了多年複雜運維場景的錘鍊,從:人肉運維 -&> 腳本運維 -&> 自動化運維(web自動化和調度自動化) -&> 智能化運維...
身處當下雲時代,自動化運維應該具備以下基礎能力:
海量管控:萬台雲主機輕鬆管理
跨雲管理:可以同時管理私有雲、公有雲、混合雲的雲主機
大文件傳輸:還在用傳統的TCP傳輸?no!BT more better
萬級並發:萬台雲主機同時執行命令,秒級返回
符合運維習慣的操作界面:功能不僅要強大!操作上手門檻一定要低!低!低!
。。。
如果還可以更好,那就是調度自動化,可以把企業的工單系統、審批系統、發布系統、通知系統等其他業務發布流程的系統串接起來,然後一鍵發布完成。
如果還可以再好,那就是故障自愈,每天重複處理的問題:磁碟告警、ping不可達、磁碟只讀、基礎性能閾值告警,都可以交給故障自愈來處理,提高運維工作效率,將時間花在更有價值的工作上。
。。。
詳情可以了解下藍鯨自動化運維項目,一款支撐騰訊內部幾百款業務的運營支撐體系,源於運維,豈止於運維!
官網: bk.tencent.com
QQ技術交流群:495299374
運維管理監控系統 像 PIGOSS BSM 具備各種運維監控功能 像 伺服器監控 ,存儲監控,資料庫監控,中間件監控,虛擬化監控等
關鍵是在於好用,以及有著做產品的思路去開發自動化運維產品,否則會導致後面的路很難走。。。。。。
CMDBIAAS文件傳輸工作流執行業務關係管理
推薦閱讀:
※作為一個計算機工程師大牛,你做過的最好的個人項目是什麼,有什麼用處,難度,影響力多大?
※編程里的玄學能有科學解釋嗎?
※國內的軟開從業者的主流水平已經和美國大部分水平一樣了?
※有哪些用代碼寫的冷笑話?
※初學c語言,做題是總是有錯,是什麼問題?