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

在現在這個概念為王的時代，ChatOps更像是一個“弱建築”定義，低調不失優雅。希望通過我的分享，和大家一起來發現其生態建設（以我熟悉的Hubot為例）、基本設計，為後續更好的實踐提供一個參考。

背景，何為ChatOps？

先看看實驗室截圖，我在聊天室中通過與某機器人溝通，獲取容器雲的測試環境的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。

低調，網際網路時代的另類

現在市場上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不侷限於運維，後續的一些更高階做法，會在團隊實踐後再做分享。
普元雲端計算專區：http://primeton.csdn.net/m/zone/primeton/index#

普元公眾號：