【devops】智慧運維就是由 AI 代替運維人員?
聽了有關AI運維之後有很多人感到比較焦慮,我所從事的運維或開發將來會不會被AI給替代掉呢?
現在新技術發展的特別快,各種語言、技術、理念讓大家確實感到自顧不暇跟不上趟,但是有一點,在這裡我要特別重申一下,AI在目前這個階段還是一種輔助大家來進行判斷和學習、定位處理問題的工具,就像無人駕駛,現在可以做到完全沒有人駕駛嗎?肯定不行,未來無人駕駛是完全可以替代人的,但它還有很長一段路要走。AI運維就像無人駕駛一樣,未來前景很光明,但任重道遠。
大部分的智慧運維還沒有完全落地,我所在的企業也是處在一個探索的階段。在一個傳統的企業它的運維該如何走?從以前的指令碼到工具、自動化,再到現在的智慧運維,中間這個步驟該怎麼走?今天就從下面五個方面給大家分享下:
一、構建一個全面科學的IT運維管理體系
第一個IT部門的整體認可不足。雖然說IT在任何單位現在都是一個比較重要的部門,但是還有很多領導仍然認為它是一個成本中心,不是一個利潤中心,認為這個部門是花錢的,而不是像業務部門創造業務價值和創造利潤的。
第二個對於運維工作人員負荷比較大,工作模式不被員工認可。在沒有自動化運維和平臺之前,整個運維團隊只有八個人,如果每個人一天處理六到十個故障,基本上沒有時間去研究別的東西了。傳統運維壓力很大,疲於奔命和救火,必須要尋求改變,走向自動化、平臺化、智慧化。
第三執行的態勢相關資訊掌握不足。監控是多維度的,不同的業務會有不同的指標,所有加起來有上萬個指標,但卻沒有整體態勢變化圖、很難成體系,不能實現智慧感知和態勢預測,整個運維態勢就很難保持平穩。
第四依據業務需求調整服務和設定資源的能力不足。在業務故障處理的時候需要很長的過程,中間涉及到很多的相關技術部門,需要和業務方進行互動,僅靠較少的人力幾乎做不到。
我們希望在現有的業務體系裡面,運維部門要實現這樣的運維目標?
第一個全面的效能管理。能夠提供對現在所有的裝置和服務質量進行實時監測,並且提供動態閾值的告警。
第二個統一的資源管理。很多企業業務都上雲了,需要有統一的監控平臺,可以把所有業務相應資源檢視抓取出來,便於我們對整體資源有一個合理的預估和分配,並從整體角度評估各個業務部門對資源的使用情況。
第三個及時的故障告警管理。我們發現有很多產品還不能做到完全及時的告警,告警發生後總是延時才能知曉,需要實時的準確的告警,減少延遲和誤報。
第四集中統一展現管理。把很多不同的監控子系統整合起來,這個在現在的企業裡面需求是很大的,藉助於各種工具,採集資料之後自動合成一個報表統一展現出來,方便管理。
我們關注的核心問題有:
第一我們是一個跨地域的平臺,是多資料中心,我們希望有一個IT的綜合運維平臺,來統一管理。
第二是深入監控並進行集中統一的視覺化管理,提高效率。
第三就是有效的預防問題的產生,降低運維成本。另外就是問題出現後,能夠快速跟蹤定位,降低人力成本。
第四多維的報表為決策提供有力支撐,科學預判趨勢。
第五全域性業務服務視角和平臺化擴充套件以及大資料分析的融合,滿足企業對於業務高效和快速迭代的需求。
第六保護和優化IT資產。以前各個業務都是自己的一套系統,有自己的開發和運維人員以及監控系統,這對企業來說是重複造輪子了。現在上雲後,把原有的系統集中整合到雲上,通過統一的監控和資源管理最好的保護和優化資產。
要做好智慧化運維之前,我們經過深入的分析,提了四個要求:
第一個是規範化。規範化就是儘可能的把操作規範下來,比如模板裡是什麼基礎配置和安全基線,有一個規範化的標準。
第二個是可控性。就是能夠通過雲監控平臺發現各個業務存在的瓶頸,包括資源瓶頸和效能瓶頸,對可能產生的問題可控可分析。
第三個是資料化。基於海量資料的決策分析,才能方便作出準確的判斷和科學決策。
第四個是主動性。從被動響應變為主動服務,主動發現問題,把問題消滅在萌芽中,在業務發生問題之前及時告知,這個感覺就不一樣了。
我們希望構建現代化和智慧的運維管理模式,主要是以下5個方面,如下圖:
二、全景業務服務管理
在網際網路大爆炸時代,國家層面上也在提網際網路+、數字化轉型、智慧化等等。我們的系統能不能快速響應,為業務保駕護航?
面向業務的IT服務管理主要有這幾個特點:
1、監控的粒度要細,能通過一個曲線捕捉到異常點。
2、面向業務管理和麵向使用者管理。這塊要區分開來,在企業裡使用者許可權分的是比較細的,什麼人可以操作什麼樣的業務,管理員可以管理哪幾類業務都有清晰的定位。
3、資料的全面和擴充性。資料只有全面才能進行科學的決策,很多時候如果看到的日誌不全,或者拿到的監控資料不準,在做決策的時候肯定就會比較貿然。比如資料中心某業務鏈路出現問題,是不是要切換?資料是不是還能保持一致?這個時候在沒有確定的資料來支撐你決策之前,你做決策時都會感到比較忐忑,猶豫不前。
建立以業務為導向的綜合監控平臺,主要目的就是要統一展現、統一管理和統一排程。全鏈路監測,這個目的就是從訪問入口進來後一直到資料出去,每一個過程都要能監控到感知到。
從業務的視角進行IT基礎資源的管理與維護,一旦某個資源發生故障或問題,都可以從業務檢視中直觀地瞭解到這個資源的故障將影響什麼業務影響哪些服務,進而瞭解到影響哪些使用者。
資料庫慢了,CPU突然飆升了,這些地方這些資源突然發生變化了之後,影響到哪些業務呢?這時候就需要將監控資源檢視和業務關聯起來,這樣才能準確定位影響了哪些業務。
這個是問題的整體診斷和分析。
任何問題都需要採集相關的日誌和資料,才能科學全面的分析問題。
採集層需要把不同資料來源的資料採集過來,中間層做一些效能分析,配置管理和預警分析、告警處理。展示層將分析的結果展示出來,也就是各種圖表,建立綜合的業務指標分析,方便根因定位和解決問題。
三、基於大資料平臺的日誌分析和多維報表
基於大資料平臺,提供日誌的採集和聚合處理,通過日誌關聯分析幫助準確全面定位提升效能和滿意度,智慧預測和預警,為科學決策提供量化依據。
將採集到的網路監控資料、機房資料、伺服器和雲環境監控資料以及攝像頭報警資料集中起來,資料彙集之後生成PMDB效能管理庫,在根據業務應用的特徵,建立不同的模型進行相應的演算法分析。
根據不同的資源類來定義KPI指標,建模目的就是方便快速分析,為資源管理、告警管理、集中化展現等其他模組提供資料分析模型的支撐。
資料採集有兩種型別,一種是被動的,一種是主動的。
採集業務相關指標,可以對資料進行預處理,做一些有效性的標籤識別,比如這個資訊和指標是不是你關注的,對不友好的日誌進行格式化處理。
效能指標的計算,要跟業務進行協同,從業務的角度來定義。設定的
閾值,有些場景是固定的,也有的場景是動態的。固定閾值就相當於資源使用率,肯定有一個上限的。動態閾值像一些效能曲線,CPU的利用率、頁面響應、圖片載入等這些是可以使用動態閾值的,根據歷史資料來計算出這個動態閾值,某一時刻的歷史峰值,根據這些合理計算出在那個時刻到底需要多少資源。
根據上面的閾值會有一個報警的事件,任何事件產生都是基於時間的,故障的定位肯定也要基於時間找到相關的日誌和發生的事件。
事件診斷一直是運維領域一個很重要的工作,事件和時序的相關性不僅可以為事件診斷提供很好的啟發,而且在幫助我們進行根因分析時也能提供很好的線索。某個時間段出現的故障,都會產生一些相關的事件,對它們進行篩選和過濾是能夠詳細捕捉到故障和定位到根因的。
在事件診斷和處理中,是不是需要引入演算法,我覺得是有必要的,如果能提高效率和提高解決問題的能力,一切探索都是值得的。
也有一些運維界的朋友們花了很多時間和精力,去學習和研究演算法,我認為不必過於糾結演算法, 簡單瞭解一下開源的這些演算法,知道這些演算法的輸入和輸出是什麼,能解決運維中哪些實際問題,以及組合起來又能解決什麼問題,方便我們合理的應用它就可以了,這樣會對更快落地智慧運維起到事半功倍的效果。
資料的匯聚處理就是把採集到的資料有機的關聯起來,壓縮、過濾形成標準化的資訊。資料匯入則可以通過全量的HDFS和增量的Kafka來實現。
基於大資料平臺的多維報表,根據自己的需要,按照日、周、月來生成運維報告,傳送給管理層的領導,這些資料是他們比較關心的,比較清晰的圖示出在這些時段發生了哪些問題,造成了多大面的影響,然後決定相關的資源是否進行擴充,相應的業務部署是否需要調整。
綜合展示比較關注的則是效能分析、容量分析和自動化配置。比如今年採購了500TB儲存,我用了多少,明年還需要擴容多少,業務增長量會有多少,這個都影響到企業的採購計劃。根據業務的實際進行評估,來推算出明年大概需要買多少TB的儲存。
四、IT監控管理平臺發展
IT監控管理的發展大概有三代,從上世紀九十年代至今,第一代是以網路為中心,在這個時期我們們提供比較多的都是基於網路的監控和故障發現,頻寬管理和服務水平協議。
第二代監控就是以監控IT基礎設施為中心,看到比較多的就是主機、儲存、作業系統、中介軟體、資料庫等各類基礎資源的監控。
第三代監控以IT應用為中心,針對比較高度複雜的交易,需要實現面向使用者體驗和麵嚮應用高可用性的實時監測和故障的智慧診斷,運維人員必須高屋建瓴、全面謀劃,有能力提供一個全域性性、高效健壯、標準規範、自動化的監控解決方案並加以實現。
五、故障管理及自治自愈
這是我們每天收到的告警情況統計,在沒有自動化和智慧化之前,我和大家一樣心態是焦慮和崩潰的。
如何從錯綜複雜的運維監控資料中得出我們所需要的資訊和結果,一句話就是分辨和精煉,提取真正需要關注的資訊,從而減少每天的告警資訊量。
目標就是簡、智、深。
簡就是要確保業務和SLA服務級別,出現問題要及時響應、自動分析和優化,把處理的流程精簡和高效組合起來,讓問題匹配正確的場景,找到正確的人,在第一時間正確處理。
機器學習主要就是突出智,這個需要大量的資料來訓練,故障出現的形態是千奇百怪,對故障的歷史資料進行場景分類和標註,不斷用模式識別和資料來訓練機器識別和分析,然後讓機器自動準確判斷。
當然標註不能完全靠人,也需要通過機器來自動進行關鍵詞標註,而標註的合理性就需要人為進行判斷,然後再利用到機器學習上,這樣才能真正輔助我們做一些決策。
基於架構、工程師的經驗和概率來做到收斂告警事件,基於規範和分工產生告警事件傳送到對的人,基於資料和模型來提高事件的處理能力。很多事件有的工程師處理的特別快,反之如果對這個故障不熟悉的人可能花費的時間就很長。這就需要構建一個策略知識庫,讓其他人來參考和學習,提高同類場景事件處理的能力。
智慧運維的終極,實現的目標就是減少對人的依賴,逐步信任機器,實現機器的自判、自斷和自決。
技術都是在不斷的進步,AI技術將來會解決很多的一些需要花費大量人力和時間才能解決的事情,但是AI不是一個很純粹的技術,它也需要結合具體的企業場景和業務,通過計算驅動和資料驅動,才能產生一個真正可用的產品。
智慧運維技術在企業的落地,不是一蹴而就的,是一個漸進和價值普及的過程。
我們可以看到,智慧運維技術已經成為新運維演化的一個開端,可以預見在更高效和更多的平臺實踐之後,智慧運維還將為整個IT領域注入更多新鮮和活力,在未來發展和壯大下去,成為引領潮流的重要性力量!
相關文章
- DevOps,就是開發吃掉運維?dev運維
- IT運維人員的神兵利器運維
- Linux運維人員必會開源運維工具體系Linux運維
- 拯救運維人!智慧運維如何實現1+1>2運維
- Ansible,運維人員的好助手。運維
- 運維人員的職業升級道路運維
- 作為運維人員,如何在遠端辦公的同時保障運維效率?運維
- 雲端計算:拼的就是運維!運維
- 2017年Linux運維人員必會開源運維工具和體系Linux運維
- 2017年Linux運維人員必會開源運維工具體系薦Linux運維
- 運維人員常用的Linux命令彙總運維Linux
- 人工智慧是如何改變IT運維和DevOps的?人工智慧運維dev
- 老凡的運維筆記 | 智慧化運維知多少?運維筆記
- 智慧運維,雲資料中心運維的未來之路運維
- 高效運維_AIRIOT智慧電力運維解決方案運維AI
- 運維人員春節放假如何管理伺服器?運維伺服器
- 運維人員如何高效管理千臺伺服器運維伺服器
- 運維人員如何學習python程式設計運維Python程式設計
- Linux運維人員共用root帳戶許可權審計(轉至馬哥Linux運維)Linux運維
- GitOps 如何改善開發人員和運維人員的日常工作?Git運維
- IT運維之自動化運維運維
- 這 4 種 Redis 常用運維工具都不會?你算啥運維人Redis運維
- 從DevOps到AIOps,阿里如何實現智慧化運維?devAI阿里運維
- 運維人員為什麼需要必備IDC智慧管理工具?運維
- 回首五年運維,運維需要思考運維
- 阿里智慧運維實踐|阿里巴巴DevOps實踐指南阿里運維dev
- 人工智慧--運維應用人工智慧運維
- 《DevOps實戰:VMware管理員運維方法、工具及最佳實踐》——1.2 採用系統思維dev運維
- 運維轉型之路 —手工運維到無人值守的自動化運維,從根本實現降本增效運維
- 銳捷釋出智慧運維平臺,讓IT運維“樂享其成”運維
- 從百度運維實踐談“基於機器學習的智慧運維”運維機器學習
- 做運維的感悟(做運維需要考慮事,運維組織結構,運維學習地圖....)運維地圖
- 智慧運維基礎-運維知識庫之ETL運維
- Linux 運維人員最常用 150 個命令總結Linux運維
- 運維人員最常用150個Linux命令彙總運維Linux
- 【乾貨】Linux運維人員必備的實用工具!Linux運維
- Linux運維人員需要掌握一門程式語言嗎?Linux運維
- 警惕資料中心運維人員十大職業病運維