解讀ChatOps:開源聊天機器人怎樣協助運維?

轉載本文需註明出處:EAII企業架構創新研究院,違者必究。如需加入微信羣參與微課堂、架構設計與討論直播請直接回復此公衆號:「加羣 姓名 公司 職位 微信號」。前端


ChatOps一般是指依靠羣組聊天室進行管理運維工做的一種。在ChatOps領域,我是一個新人,經過學習與運用,再回過頭來看,對GitHub、Apple這樣的一些先行者更是崇拜。node

 

在如今這個概念爲王的時代,ChatOps更像是一個「弱建築」定義,低調不失優雅。但願經過個人分享,和你們一塊兒來發現其生態建設(以我熟悉的Hubot爲例)、基本設計,爲後續更好的實踐提供一個參考。redis

  

背景,何爲ChatOps?npm


先看看實驗室截圖,我在聊天室中經過與某機器人溝通,獲取容器雲的測試環境的top5資源以及主機健康信息表。微信


 
 

直觀的感覺就是ChatOps給了一個全新的工做環境,讓咱們能夠在聊天室中,經過聊天的方式,獲取想要的反饋。閉包

 

說到ChatOps,天然會想到DevOps。市場上這兩年在「瘋狂」的傳遞着DevOps的理念,那咱們有沒有考慮過DevOps的核心是什麼?有哪些實現分支?又存在一些什麼問題?不少人都像我同樣,會習慣的去說,DevOps有四大核心,包括技術、組織、流程、文化;實現DevOps能夠從CI/CD着手,以自助自動爲指導思想;DevOps要落地很難,由於有太多歷史債務,有太多規章制度......架構

 

那該怎麼正確看待ChatOps呢?機器人?聊天室?機器人聊天運營?先看看SneakyCode上的總結:「At the heart of DevOps is CAMS …… ChatOps isan extension of DevOps and enhances it with and extreme focus on CAMS」。這裏,CAMS是指a culture of automation, measurementand sharing,認爲ChatOps是對DevOps的一個實現與增強。框架

 

一直以來,運維的工做方式給你們的感受就是腳本,部署要執行腳本、變動要執行腳本;或者進階一層來看,運維會用各類小工具,好比Puppet、SaltStack等,對腳本造成統一管理、下發、執行。不少人都在講:要把繁重且重複的勞動交給機器人,讓人作更有趣更創新的事情。好比運維同窗所作的平常巡檢、故障處理,則能夠由這些機器人夥伴來協助處理。而做爲運維同窗的夥伴機器人,一個很好的參與工做方式是加入到咱們的平常聊天組,一塊兒共事、一塊兒學習。-----這就是ChatOps,但不侷限於Ops。運維

  

低調,互聯網時代的另類dom


如今市場上ChatOps的開源實現,呈三足鼎立之勢:


1.Hubot:CoffeeScript實現,GitHub提供且自用

2.Lita:Ruby實現,支持容器部署,依賴redis

3.Err:Python實現,我目前尚未用過

 

以Hubot爲例,這是GitHub在5年多前開發的一套用於管理GitHub本身的軟硬件的機器人,中間歷經了自用、開源、重寫再開源三個階段,如今儼然成爲GitHub上最火熱的項目之一:



在過去的5年多時間中,其宣傳相比DevOps、微服務、容器這些概念來講,少的可憐;可是最近ChatOps更像是被推出到了風口,被愈來愈多的說起到了。

 

開源生態講究的是合縱連橫,單向集成是生態建設的最大阻力。在第一次使用Hubot時,其生態建設的完備性至關讓我出乎意料,在出向上,Hubot自己已適配不少:




而在入向上,我使用的Slack、HipChat都默認地作了對Hubot的集成。以Slack爲例,進入應用管理後,直接就能夠集成Hubot、Lita,而不須要本身經過API作集成了。

 




除了上面提到的與chat軟件的集成,在部署環境上,Unix、Windows均可支持,並且Hubot支持了Azure、Bluemix、Heroku等雲環境的快速部署(雖然還沒全自動化)。這裏難免又一次吐槽,我們國內的一朵朵公有云,每天在談生態,爲何沒有一家去作作這些事情呢……

 

機器人,說的少作的不少


現階段,機器人像是你團隊裏剛來的新人,更多的是在有序的安排下一步步作事(這裏固然不包括AlphaGo這些高端的東東 )。最常規的工做方式以下:

 

 

經過給予command,由機器人夥伴去實際雲中操做,人和機器人夥伴的通訊走私有通道,機器人夥伴會將信息回覆到聊天室中。


機器人夥伴一樣分公共與私人的,最簡單的方式就是用不一樣聊天室來隔離(不一樣的圈子嘛)。

 

機器人夥伴做爲聊天室的一個成員,表象上它和全部人是同樣的。




但機器人就像是不少團隊裏都存在的那種個性員工,說的少作的多:

 

說的少——一個聊天室裏,大部分時間機器人夥伴是沉默的,或者默默在後面作事的;說話的都是咱們這些喜歡「閒扯」的人,真有事情來了,纔想起機器人夥伴能不能幫忙給作了,這時候他纔會被逼着跟你「說」兩句。


作的不少——若是你願意,機器人夥伴能夠幫你作全部事。固然這裏有一個度的問題,不是全部的事情都應該讓機器人夥伴去作。機器人夥伴本質上是一種有規律下的封裝,只有事情是穩定的、可持續的,才考慮招聘機器人來作。可是,千萬不要無限的去招聘機器人,即便是私人的。由於和你招聘其餘團隊成員同樣,想象一下你的團隊無限擴展,有些方面天然有好處,但帶來的問題也不言而喻。

 

那通常咱們怎麼招聘機器人呢?再以Hubot舉例,前面提到這是基於CoffeeScript的,須要必定的腳本基礎,不過從個人使用狀況來看(我腳本基礎也很通常),關係也不大(具有node,npm相關的知識就能夠),由於真正和CoffeeScript相關的工做不多,通常就兩步(固然,這個是Slack適配後作了易用性,默承認不是這麼簡單的,後面會提到如何適配):


 


定義robot每一個機器人的定義方式基本上是如出一轍的;


匹配command:發送返回信息,上面只是截取的示例,通常會在匹配後,發送http rest請求實際去工做(這個就有很大的可操做空間了),將結果format後再發到聊天室中。


若是你的公司用的是沒有與Hubot集成的chat軟件,還須要作一次client的封裝,這個稍有點複雜,須要必定的腳本基礎,可參考hubot-slack項目:https://www.npmjs.com/package/@slack/client,我用一張圖來講明Hubot的擴展架構,其集成時的插件點很明確(注:下圖只標識了最重要的幾個方法):

 



經過實現Adapter的必要方法,完成機器人的生命週期管理。在與Slack集成時,稍有特殊性在於:run方法中,註冊了Slack的message事件(當Slack有消息時觸發),在message方法裏,經過消息類型、發送人、channel等上下文信息,將具體消息封裝後dispatch給機器人。

 

避免誤區


我認爲在接納ChatOps這個理念的過程當中,容易存在三種思想誤區,會在必定程度上阻礙ChatOps的落地。

 

誤區1:ChatOps純粹是爲了好玩。你們體驗過人工智能,或者指揮過機器人作事,當時是持着什麼樣的心態去作的呢?我在一開始用Hubot的時候,興沖沖的拉着部門同窗分享,很直觀的反饋就是:你們以爲很新穎,卻真心不以爲有實際做用,感受就是在咱們聊天室裏發發指令,用來看看數據圖表等,運維門戶上一樣能夠作。

 

誤區2:聊天室裏作事很不規範。企業用IM,好比釘釘、Slack、HipChat,也有用微信、QQ的,但不多有企業會把IM工具及內容歸入到標準管理體系中,不少時候就是純粹的聊天工具。在這類工具中作事,你們會以爲沒法保障規範性、可審計性等。

 

誤區3:Command讓工做再也不專業。就像咱們公司的產品EOS(SOA下的開發運行平臺),自出生就飽受技術人員爭議,緣由是封裝了太多底層實現。而ChatOps中的Command工做方式,一樣會讓咱們以爲專業技能受到挑戰。

 

上面這三種見解真的有道理嗎?其實否則,在我看來這種誤解的本質上來源於:

 

不一樣層面上的認知誤差。不少同窗都在廣用開源和工具,但歷來沒有以爲這些屏蔽了底層實現,爲什麼對於ChatOps中的機器人夥伴作事,就有這個感受呢?好比說你們用Eclipse開發代碼,不多有人關心Eclipse工具自己屏蔽的內容,但一旦在Eclipse加了些插件輔助,不少人就以爲不直觀了;再好比不少前端同窗使用React、Bootstrap這些框架,是否關心過它屏蔽了prototype、閉包這些基礎知識呢?這實際上是不一樣層次的對問題的認知,說的直白些,我以爲是慣性讓人變得封閉,不想跳出習慣的工做方式。

 

責任心缺失&我的主義。在ChatOps領域中,咱們都說要機器人,但有時候會發現團隊裏就你在貢獻,這固然是個很很差的體驗,讓人很受打擊;再者,聊天室裏去工做,讓新同窗看着聊天窗口就能學到你的工做方法,這個會讓一些人以爲不爽,彷彿侵犯了一些我的信息,他寧肯去寫文檔或手把手的教,就是不想在一個好像被「監視」的環境下作事。這個其實涉及到了Freedom & Responsibility的問題,如何權衡相信你們自有評判。

 

總結


雖然接觸ChatOps領域時間不長,但已深入感覺了其獨特魅力:

 

聊天室再也不是聊天,隨着夥伴角色的豐富與能力提高,聊天室會成爲一個協做、學習的基礎支撐平臺固然,不一樣於如今不少微課堂,這裏會讓你看到高手的實操方式、讓每一個成員可擁有很酷的機器人拍檔。

 

生態從小團隊作起之前一說生態就被放得很大,即便企業裏面說生態,也時常會放到基線平臺的概念裏;如今咱們真的能夠快速去創建小生態了,你只要在一些基礎上招聘一些機器人,就能夠爲你的團隊生態提供一份貢獻,相信每一個企業的可優化空間都很大吧。

 

合理處理人與機器的關係,不要再是e-e關係 ,而把他做爲團隊裏的成員,最吃苦耐勞的成員來看待,這纔是ChatOps所指望的。

 

止於至善,這是個人校訓,在IT這個領域,尤爲是如今的DevOps、ChatOps領域更爲適用,這些都是點滴積累,精益求精的建設過程,不可能有萬能鑰匙(標準產品)。

 

這裏討論的知識初步作一些基礎運維的事情,可是正如文章以前所提,ChatOps不侷限於運維,後續的一些更高階作法,會在團隊實踐後再作分享。



關於做者:
顧偉

現任普元信息主任架構師。長期致力於IT技術研究、產品設計與開發、架構諮詢等工做,擅長Web、OSGI、CI/CD、服務治理、雲計算等領域技術。對DevOps、自動化運維、微服務架構有着濃厚的興趣。


關於EAII

EAII(Enterprise Architecture Innovation Institute)企業架構創新研究院,致力於軟件架構創新與實踐,加速企業數字化轉型。


eaworld項目微信號:eaworld,長按二維碼關注

eaworld是EAII的官方微信帳號。


以「企業數字化變革中的技術與架構創新」爲主題的PWorld 2016大會即將召開!來自普元、紅領集團、藍月亮實業、星環科技的20餘位技術大咖、近30場技術分享與你共議企業數字化將來!大會已於8月26日北京9月6日上海舉行、將於9月20日廣州舉辦,感興趣的能夠掃二維碼瞭解活動報名參與,欲瞭解詳情請戳:閱讀全文



本文分享自微信公衆號 - EAWorld(eaworld)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索