ChatOps=AIOps落地+DevOps升級+SRE實踐
產品迭代技術升級概念換代 @全體成員
傳統—雲端計算/大資料—人工智慧——……
虛擬機器VM—容器Doceker—微服務Microsevice—無服務Serverless—……
@全體成員 群裡可以開啟全員學習模式
AI人工智慧技術近幾年發展得如火如荼,而隨著深度學習技術的成熟,AI也正在逐步從尖端技術慢慢變得普及,AI目前已經可以實現很多功能了,如語音識別、自然語言理解、資料探勘、計算機視覺等。除此之外,現在又多了一個落地應用——這是一座尚未開採的金礦——AIOps。
2016年,Gartner定義了一個新名詞——AIOps,即基於演算法的IT運維(Algorithmic IT Operations),這可能和你的第一反應Artifical Intelligence Operations有所偏差,不過本質上意義是一樣的。Algorithmic IT Operations源自業界之前所說的ITOA(IT Operations and Analytics),演算法的效率提升了 AIOps 的價值,通過持續學習,智慧運維將把運維人員從紛繁複雜的告警和噪音中解放出來,運維插上了機器學習和演算法的虎翼,將變得更自動化、智慧化。Gartner
的報告宣稱,到 2020 年,將近 50% 的企業將會在他們的業務和 IT 運維方面採用 AIOps,遠遠高於今天的 10%。
智慧運維的必要性相信不必多言,如今的IT基礎架構相比於前五年,前十年,規模和複雜度都呈倍數增長,服務數量更是呈指數增長,早期的運維方式已經無法負荷愈加沉重的工作量,而人工智慧的發展給運維帶來了契機,AIOPS應運而生。
從起初的開發方式說起
插播一條IT 運維發展歷程的廣告
1. 人工運維時代
初期階段IT基礎設施通常處在小規模狀態。幾臺至幾十臺機器的規模,足以滿足業務需求。早期一般企業採用的都是人工運維,決策分析幾乎完全由人工完成。
2.自動化運維時代
隨著雲時代到來,IT基礎設施迅速發展成幾百上千臺伺服器,更多的業務系統上線,因此,各類孤島式的運維管理工具也開始上線,提升運維效率。
3. DevOps時代
DevOps是一組過程、方法與系統的統稱,企業希望將原本笨重的開發與運維之間的工作移交過程變得流暢無礙,便可藉助DevOps來完成,DevOps的目標是流程的自動化——讓程式碼完成過去手工的工作,從而大大節省成本。
4. AIOps時代
AIOps智慧運維,用機器學習方法做決策分析,演算法的效率提升了 AIOps 的價值,通過持續學習,智慧運維將把運維人員從紛繁複雜的告警和噪音中解放出來。
5、ChartOps ……
起初,老一輩程式設計師想要開發一個軟體,需要了解軟體開發的各個環節,從編寫需求文件、軟體開發、測試、部署到運維技術支援等,一個人的工作中可能會涉及軟體生命週期中的各個方面。
後來,隨著客戶需求的不斷增加,軟體開發需要更快的速度,實現更多功能,有更好的使用者體驗。起初的工作方法對於程式設計師們來說已經跟不上客戶的需求節奏了,因此,需要明確劃分程式設計師所負責的工作模組,以提高工作效率。於是,有了產品、開發、測試、運維等不同的角色。俗話說“術業有專攻”,每個崗位的人員在自己所屬的方向上深入研究探索,一定能更加高效地開發出使用者體驗更好的產品。
那時,各角色部門之間交流不多,只是在上一級團隊完成工作時將任務傳遞給下一級。比如,產品人員完成軟體需求設計後,拿給開發人員進行開發。這種瀑布式的開發流程理論上很和諧,除了比較單執行緒工作,其他好像沒什麼問題。但在後續的開發過程中,人們的需求不斷增加,需要隨時將新的需求加進開發中,又或者最開始定下的需求後面會隨時修改。這使得很多軟體專案很容易夭折。
為了解決瀑布式開發流程所帶來的問題,人們提出一些思想:敏捷開發、精益開發等。總的思想是加強內部溝通協作、消除浪費提高生產開發效率、持續快速交付等。這些思想促進了開發團隊成員(業務分析師、架構師、前端開發人員、後端開發人員等)之間的溝通協作,提高了產品的開發效率。
產品開發完成並測試通過之後,後續的上線部署和維護工作便交到了運維人員手中。如果說敏捷精益開發解決了開發團隊之間協作的問題,那麼運維和開發之間的資訊鴻溝又如何填平呢?DevOps 應運而生!
應運而生的 DevOps
DevOps 是來源於 Development (開發)和 Operations(運維)的一個組合詞,是一系列過程、方法與系統的統稱,旨在促進開發、測試和運維人員之間的溝通與協作。
簡單來說,它是通過引入一系列的工具,通過三種不同角色成員間的協作而實現的一種自動化的工作模式。借用喬樑老師的觀點,這裡可以概括為兩個關鍵的方面:
-
全域性觀,從軟體交付的全域性出發,加強各角色之間的合作。
-
自動化,藉助支援校本化、無需人機互動的管理工具。
這種工作方式帶來的好處顯而易見:
-
實現持續快速交付。
-
能夠降低人力成本。
在很大程度上,DevOps 更多是指開發群體之間的一種協作模式,它不是一個角色的稱呼,也不是一個部門或團隊的稱呼,而是一種思維方式、一種工作理念、一種能力!遵循這種理念,就有了這種能力,開發和運維團隊之間的障礙便被消除了,工作沒有堆積,開發的交付和運維的部署維護被放進了同一個時間盒子裡,產品開發上線和運維的效率將得到很大提升。
從自動化運維到 AIOps
“應運而生的 DevOps” 一節中曾經說到,DevOps 是需要藉助一系列的工具,通過開發和運維之間的溝通協作而實現的一種自動化的工作模式。如果說 DevOps 是一種工作模式或者是一種工作理念,那麼,自動化運維可以說是該理念在其中一個關鍵點上的落地。
自動化運維的實現包含很多方面,如資源效能監控和應用效能監控、批量運維伺服器、日誌集中分析、持續整合和釋出、安全漏洞掃描、自動部署和備份等。每個方面都有相應的自動化運維工具可以使用,比如開源的效能監控系統 Zabbix、批量運維工具 SaltStack 及開源的日誌分析工具 ELKStack 等。也可以基於這些自動化運維工具搭建適合自己整體工作環境的自動化運維平臺。
基於自動化運維平臺的 DevOps 當前已經幫助一些企業提高了生產效率,減少了流程上的失誤和人員上的疏忽。然而,自動化運維還只是停留在幫助我們發現故障、產生預警、根據人工輸入引數自動部署備份的階段,而問題的定位和處理還是需要運維人員親自來解決。隨著雲端計算、微服務的普及,業務指數級的增長,當我們遇見報警數繁多時該怎麼處理?當一類故障發生時,我們是否可以快速憑藉我們的經驗來定位問題呢?如果是那些初來乍到、腦袋裡毫無經驗的運維人員來解決的話,是不是會花費更多的時間?
隨著人工智慧的興起,以上問題是否可以通過 AI+Ops(即 AIOps,智慧運維)實現呢?Gartner Group 提出的 AIOps 中的 AI,其實是 Algorithmic IT 的縮寫,而不是很多人以為的 Artificial Intelligence 的縮寫,但不管是哪種寫法,都意味著利用機器學習演算法對線上執行的真實資料和日誌等作出故障預判,從而執行相應的運維操作。
AIOps 可以說是自動化運維的升級版,所以並非 DevOps 的取代者,而是 DevOps 更高階別的落實者。
ChatOps 簡介
ChatOps 的理念由 DevOps 延伸而來,又結合 AI(人工智慧)落地,可以說是人工智慧和新型工作理念結合的產物。它也是一種新型智慧工作方式,幫助團隊利用 ChatBot 機器人使成員和各項輔助工具連線在一起,以溝通驅動的方式完成工作。同時解決人與人、人與工具、工具與工具之間的資訊孤島問題,從而有更高的工作效率和更好的協作體驗。
2013 年,GitHub 在其內部最早開始推行 ChatOps,希望能以聊天的方式更容易更快速地去完成 DevOps 承載的工作。
ChatOps 以聊天室(溝通平臺)為中心,通過一系列的機器人去對接後臺的各種服務,工作人員只需在聊天視窗中與機器人對話,即可與後臺服務進行互動,整個工作的展開就像是使喚一個智慧助手那樣簡單自然。
GitHub 團隊內部實現的 ChatOps, 與一個叫作 Hubot 的機器人框架密切相關,Hubot 提供很多聊天機器人所需要的基礎設施,藉助 Hubot 框架能比較方便地和自己編寫的功能或自己的系統對接。目前,Hubot 已經發展出了較好的生態圈,有很多開源外掛可以借用。
ChatOps 站在巨人的肩膀上發展,也為工作帶來了顯而易見的好處:
-
移動友好。只需要在前臺與預設好的機器人對話即可完成與後臺工具、系統的互動,在移動環境下無須再與眾多複雜的工具直接對接,大大提升移動辦公的可行性。
-
DevOps 文化打造。用與機器人對話這種簡單的方式降低 DevOps 的接受門檻,讓這種自動化辦公的理念更容易地擴充套件到團隊的每一個角落。
-
公開透明。所有的工作訊息都在同一個聊天平臺中沉澱並公開給所有相關成員,可以消除溝通壁壘,工作歷史有跡可循,團隊合作更加順暢。
-
上下文共享。減少因工作臺切換等對訊息的截斷,保證訊息的完整性,讓工作承接有序,各角色,各工具都成為完成工作流中的一環,打造真正流暢的工作體驗。
ChatOps 的實踐經驗
ChatOps 主要由四個部分組成:自動化的理念、一個溝通承載平臺、一系列連線人與工具的機器人,以及一些後臺工具和服務(基礎設施)。它不僅可以應用在技術團隊中,還可以發展為適應不同種類團隊的方法模型,這也是 ChatOps 這個概念提出的背景之一。隨著全行業的發展和人力成本的攀升,ChatOps 也可以說是應用於全行業的 DevOps。
國外早期的工作溝通工具 HipChat,或新秀 Slack 都是作為 ChatOps 承載平臺的好選擇,在中文環境下,則可選擇 BearyChat(倍洽)等。除上文介紹過的 Hubot 外,還有一些比較成熟的機器人框架,如 LITA、ErrBot 等。至於機器人後面對接的具體服務則更加數不勝數,例如一個工程師文化驅動的團隊,不僅可為開發人員接入 GitHub、Jenkins 等工具,也可為產品運營接入 Trello、Email 等。
這些被接入的工具藉助機器人這個載體,完成了內部提醒訊息向同一個訊息平臺中的實時同步,並因為這種並行的同步行為的發生,而使得團隊原本散落在不同第三方服務中的訊息在同一個訊息中心——即團隊的溝通平臺——中形成了一個按照時間順序彙總的訊息流,幫助團隊各個成員隨時且全面地瞭解團結各項任務的進度或安排,真正實現了團隊訊息的透明共享。
除對接已有的產品,團隊也可使用 Hubot 等自定義機器人框架對接團隊內部開發的一些具體的功能,如直接通過命令在聊天視窗查詢待上線列表,實時瞭解 CPU 的使用狀況等。
機器人這個概念在團隊溝通環節中產生,使得團隊的協同和自動化工作進入了一個嶄新的時期,不僅帶來了新的互動方式——使得團隊成員在不離開溝通視窗的前提下即可完成大部分日常工作,不因視窗切換而導致工作時間的切割和工作精力的分散,貫徹了 DevOps 的工作理念——增強了團隊協作並讓更多的工作趨向於自動化,而且為 AIOps 逐漸普及和落地提供了良好的平臺和基礎。
AIOps智慧運維如何做好?
清華計算機系副教授,智慧運維演算法專家裴丹教授為我們提出瞭如下見解。
機器學習本身有很多成熟的演算法和系統,及其大量的優秀的開源工具。如何成功的將機器學習應用到運維之中?還需要以下三個方面的支援:
1. 資料。網際網路應用本身具有海量的日誌。需要做優化儲存。 資料不夠還需要自主生成。
2. 標註的資料。日常運維工作會產生標註的資料。 比如出了一次事件後,運維工程師會記錄下過程,
這個過程會反饋到系統之中, 反過來提升運維水平。
3. 應用。運維工程師是智慧運維繫統的使用者。使用者使用過程發現的問題可以對智慧系統的優化起正向反饋作用。
總結
DevOps 是為了解決瀑布式開發流程存在的問題而提出的一種工作理念。這種工作理念強調,通過藉助自動化工具和不同角色之間的溝通協作來實現敏捷精益開發、持續交付和高效運維,提高產品開發上線及維護的效率。而通過使用自動化工具進行的自動化運維可以看成是 DevOps 理念落地的關鍵之一。在這個網際網路業務量飛速增長、人工智慧興起的年代,我們完全可以考慮將自動化運維進一步發展為 AIOps。而 ChatOps 又恰恰是人工智慧技術和 DevOps 協作理念一個很好的結合,也勢必為 AIOps 和 DevOps 更好地融合普及加添助力!讓我們一起來期待未來開發運維新場景帶來的驚喜吧!
附錄:AIOps落地誰家?
Google | 資料中心人工智慧模型
早在2014年,人工智慧就在IT運維領域有所應用,在Google,人工智慧是提高各個大型資料中心效率的重要工具。
Google使用“類神經網路”技術分析其眾多資料中心的工作情況,並根據所得資料進行維護。這個“類神經網路”的核心部分其實是一些演算法,可以識別模型(patterns),並根據相應模型做出判斷,即Google使用這些演算法管理資料中心。它們無法超越人腦,但在某些情況下卻更快,更全面。
從具體來看,每隔幾秒,Google就會收集資料中心所有的處理資訊,從裝置耗能多少,到硬體冷卻到室溫需要多少水無一不包括。Google資料中心青年工程師Jim Gao就是使用這些資料構造人工智慧模型,在不同條件下預測資料中心效率。如果資料中心的效率低於模型預測,公司就會收到相關資訊。這個模型,同樣可以幫助Google決定何時管理資料中心的裝置,比如何時清理熱交換器,提高裝置冷卻效能。這樣一來,這個模型具有辨別功能,解放了Google的工程師們,也大大提高資料中心的運維效率。
百度 | 基於日誌 trace 的智慧故障定位系統
結合機器學習技術的進步,百度實現了一套基於日誌 trace 的智慧故障定位系統及其背後的一套技術方案,最終能夠實現 WQPS/sec 的 PV 根因定位能力,並能夠根據根因做統計上的多維度匯聚,該系統應用於百度核心搜尋系統,極大的提升了重大異常問題定位效率。
阿里 | 機器學習在大規模伺服器治理複雜場景的實踐
我們今天面臨的問題,雲、支付和交易的程式通過虛擬化打散在百萬級的伺服器上, 面對如此龐大的基礎設施, 傳統的運維方法受到了極大地挑戰。海量告警無法及時處理、髒資料影響定位、批量問題如何提煉。
在無高質量樣本的情況下,通過關聯分析和異常檢測演算法,構建演算法閉環。自動迭代,讓批量問題的預測精度不斷提高。打通故障定位和裝機系統,提供從發現 ->定位 ->跟蹤 ->修復的一站式解決方案。
各個行業的企業正在採用AIOps——銀行、娛樂、交通、零售,甚至政府。從運維的發展角度看, AIOps 是必然趨勢,將為企業帶來最直接最深遠的價值。
相關文章
- DevOps升級&AIOps落地,看看這些大廠都是怎麼做的?devAI
- DevOps升級&AIOps落地,網際網路企業和傳統企業的做法有何異同?devAI
- DevOps落地實踐,BAT系列,敏捷看板devBAT敏捷
- DevOps與傳統的融合落地實踐dev
- DevOps 和 SREdev
- 運維DevOps體系解析與落地實踐運維dev
- DevOps 在企業專案中的實踐落地dev
- DevOps, HybridOps and AIOps淺談devAI
- DevOps落地實踐點滴和踩坑記錄-(1)dev
- AIOps的落地應用AI
- DevOps在傳統企業的落地實踐及案例分享dev
- DevOps實踐dev
- 升級Webpack5實踐Web
- 嘉為&傑蛙攜手助力企業DevOps最佳實踐落地dev
- 從DevOps到AIOps,阿里如何實現智慧化運維?devAI阿里運維
- DevOps落地實施要有哪些支柱?dev
- DevOps 實踐指南dev
- 最佳實踐 | 原始碼升級gcc原始碼GC
- T4 級老專家:AIOps 在騰訊的探索和實踐AI
- 京東雲開發者|提高IT運維效率,深度解讀京東雲AIOps落地實踐運維AI
- Kubernetes 叢集無損升級實踐
- 蘑菇街SRE體系建設實踐
- promise時效架構升級方案的實施及落地Promise架構
- HDFS3.2升級在滴滴的實踐S3
- AWS RDS強制升級的應對之道——版本升級的最佳實踐
- Serverless Kubernetes 落地實踐Server
- 雲原生 DevOps 的 5 步升級路徑dev
- SRE的含義及與 DevOps 如何關聯dev
- SpringBoot2.7升級到3.0的實踐分享Spring Boot
- dubbo2升級到dubbo3實踐
- 大規模 Hadoop 升級在 Pinterest 的實踐HadoopREST
- 金融科技 DevOps 的最佳實踐dev
- 論 DevOps 實踐有幾何?dev
- DevOps 中的測試實踐dev
- DevOps中的測試實踐dev
- Daniel Bryant:平臺工程是新的DevOps或SREdev
- 都說AIOps是必然趨勢,那實踐AIOps之前需要做些什麼準備?\nAI
- SRE 實用指南:事件嚴重性級別 - rootly事件
- [Flink/FlinkCDC] 實踐總結:Flink 1.12.6 升級 Flink 1.15.4