當咱們在談論 DevOps，咱們在談論什麼？

Cloud Insight 攜手 BearyChat：打造適合運維人員的團隊協做工具

走過 C 輪的 OneAPM，旗下的產品已經日漸豐滿，從應用性能監控的 Application Insight 到系統監控工具 Cloud Insight，再到安全產品 OneRASP，以及日誌分析工具 .LogInsight。而今，咱們一直困頓於一個問題：監控幫助人們更快地發現了問題，而解決問題的落點在哪？

機器尚未智能到能夠幫助咱們修復代碼中的問題，沒有辦法解決一個頁面的 SQL 時長長達 5000 ms 的問題，也沒有辦法權衡計算資源的流向。

當咱們深刻 DevOps 這個方法論，以及思考 Slack 的流行，咱們發現「協做」和「溝通」，也許是幫助咱們更高效地解決問題的解決之道。

DevOps 和 ChatOps

DevOps 這個一再被人們說起的概念，在實際操做中，這個方法論其背後的實際操做方法，和項目管理的手段是什麼樣的，甚少有人能夠給出一個完美的答案。

DevOps 在最初，是讓開發、運維、QA 之間增強溝通，經過不一樣的工具來消除隔閡。而隔閡的造成有兩個緣由，一是信息不對稱，研發沒法獲取到運維的數據，運維也沒法解讀代碼的錯誤信息；二是所秉持的價值觀、方法論的不一樣，不一樣部門之間的目標也所以有差別。說得實際一點，就是由於 KPI 這座大山形成了不一樣部門之間的對責任的逃避，而 DevOps 是倡導你們一塊兒來面對問題、解決問題。

開發環境和部署環境的快速遷移，幫助產品快速上線；愈來愈多的監控工具，明確負載問題是計算資源不足的問題，仍是代碼質量的問題。

咱們來看 stackshare 排名前 10 名的 DevOps 工具：

現在的 DevOps 工具大體能夠分爲兩類:

• 更快的 Build Test Deploy
• 更好的 Monitoring

可是你們彷佛忽略了一個方向，就是上文提到的：「協做」和「溝通」。如何打破信息不對稱？如何打破隔閡？當「協做」和「溝通」的效率達到最高，團隊將望風披靡。

Slack 的流行讓這個方向又重獲生機：ChatOps。

ChatOps 是誕生於 GitHub 的一種基於會話驅動的協做開發方法，過去團隊之間的通信和開發操做是兩層皮，致使各類不透明和低效率。ChatOps 將開發工具帶入開發者聊天室，經過定製的插件和腳本，一個聊天機器人可以執行聊天中輸入的各類命令，實如今聊天平臺上的團隊協做開發自動化，把團隊溝通和執行統一整合到一個可視化更高的聊天環境中，「聊着天就把事情辦了」。

咱們來看下 WIRED 雜誌對 GitHub 系統主管 Sam Lambert 的採訪：

當你走進 GitHub 的大廳，在前臺的 iPad 上登陸後，全部計劃與你會面的人都會收到一份通知。GitHub 的系統主管 Sam Lambert 對 Wired 網站說，Hubot 是公司工做最努力的員工。這是公司內部的一個玩笑。其實，Hubot 是嵌入到 Github 聊天系統裏的軟件，或者說，它是個聊天機器人。

經過向 Hubot 發送信息，工程師們能夠升級服務器上的系統，刪除數據庫中的數據，甚至讓所有的服務器下線。在公司外部，Hubot 被稱做是 ChatOps 工具。就是說，它可以處理運營任務，好比設置新服務器和數據庫，或者升級 GitHub 網站背後的代碼。ChatOps 是 Github 自造的單詞，不過，這種想法來源於軟件界的 DevOps 運動。經過一些新型的軟件，工程師們可讓公司內部的大量硬件和軟件實現自動化設置和升級。ChatOps 添加了對話元素。「GitHub 網站天天的升級都是經過聊天機器人完成的。」 Lambert 說。

ChatOps 這項 GitHub 自創的運動，的的確確爲 DevOps 中「增強溝通」帶來了實質性的進展。

而硅谷的 Slack 這塊團隊協做的明星產品的流行，說明 ChatOps 正在往產品化的方向上行進。

BearyChat

經過會話來增強溝通，從而更高效地解決問題。在國內，就要說說 BearyChat 了。

BearyChat 的出現是由於**團隊工具龐雜，天天產生大量信息，這些信息散落在各類服務裏，其中重要信息極可能會被忽略。**因此一個聚集信息、提高工做效率的工具成爲一種剛需。

固然，除了界面，產品自己的功能是最重要的，BearyChat 在團隊討論上除了基本的文字溝通，還接入了各類第三方服務，好比圖片和視頻直接顯示，網頁連接直接抓內容，以及展現 Github 代碼片斷、Trello 列表等功能，儘量將影響團隊協做流程的操做簡化（如點擊、跳轉等等）。

除了整合梳理信息的功能，BearyChat 還有一個相似於 Workflow 的機制，他們稱之爲機器人。在小編看來，Workflow 是提高效率的關鍵功能，Mac 內有自建的 Automator，網絡上有著名的 IFTTT。從 If this then that 的邏輯上延伸，BearyChat 的機器人應該是內容的搬運工，好比項目代碼一旦更新會自動發送到討論組這樣的功能。

協做工具的將來

康威定律說：設計系統的組織，最終產生的設計等同於組織以內、之間的溝通結構。

若是一款團隊協做工具，作到了通用，卻沒有根據組織內部的溝通方式、工做方式來作配合，最終溝通和協做的效率會大打折扣。

好在 BearyChat 能夠經過第三方工具來自定義機器人。那如何更深刻地與其餘產品合做呢？

若是咱們對工做中的人羣進行划向：設計師、研發人員、項目管理人員等等，而這些人所須要的工具是不同的。

設計師須要 Adobe 的 Creative Cloud 來隨時隨地訪問他們的文件，須要 Behance 和 Dribble 的推送來擴展視野。研發人員以 Cloud Insight 研發組爲例，須要 GitLab 的變動管理，須要 Docker 的管理工具，須要基於 Bara 的測試環境部署的變動管理等等。

而不一樣工種的關注點，和溝通方式也是不同的，而且圍繞的話題、和傳輸的文件的特徵也是不同的。

單就運維這個工種來講，他們須要關注的點包括：

• 每一項指標的歷史曲線圖
• 報警產生的事件
• 出現異常點時的解決方案
• 高級工程師和初級工程師之間的溝通
• 對基礎設施的控制

也就是說，若是一個團隊協做工具不可以針對某個特定工種，根據他們的關注點作適配，最終淪爲一個通用級的工具，是沒有將來的。這也是加速了像 Slack、BearyChat 這樣的團隊協做工具，和其餘第三方工具合做的緣由。

而今，Cloud Insight 和 BearyChat 的合做，就是爲了打造一個適合運維工程師進行實時溝通與協做的一體化工具。

Cloud Insight 是一款系統監控工具，可以監控操做系統、數據庫、中間件的運行狀況，並根據指標產生報警。也能夠經過 SDK 上傳任何指標，來作集中的展示和管理，包括：業務指標、應用性能監控指標等等。

所以，參與到 Cloud Insight 這個工具的人員，不止運維人員還包括研發人員、管理人員，甚至運營人員。而團隊協做也是 Cloud Insight 不可或缺的功能。Cloud Insight 事件流就是聚集報警、探針啓動和操做歷史記錄於一身的功能。

不一樣工具之間的相互整合，在 SaaS 這個環境中意味着更多的可能性，更多的使用場景，給用戶帶來更多的選擇。

結語

性能監控的意義在於讓運維變得高效、智能。團隊溝通、協做的根本目的也在於經過一切方式提升效率。DevOps 是倡導你們一塊兒來面對問題、解決問題，經過 Cloud Insight 及時發現性能問題，這時候再由於BearyChat 的快捷和易用讓解決問題的過程不那麼痛苦。有着一樣的情懷和期許，Cloud Insight 和 BearyChat 的合做勢必成爲一件 1+1 > 2 的事。

參考文章

1. The Most Important Startup's Hardest Worker Isn't a Person

2. DevOps 年中盤點：國外最受歡迎的 10 篇技術文章（下）

3. IT 人士恥於下問但又不可不知的「聊天運營」 —— ChatOps

本文系國內 ITOM 管理平臺 OneAPM 工程師編譯整理。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。 本文轉自 OneAPM 官方博客