關注嘉爲科技,獲取運維新知數據庫
寫這篇文章的時候,時間是2018年10月31日,還有兩個月就將步入2019年,想想,都很激動呢。服務器
這個時間點跟咱們今天要談論的主題有啥關係嗎?網絡
並無。架構
只是單純感慨下時間真的過得快鴨。(嚴肅臉)運維
言歸正傳,進入2018年以來,IT運維領域最熱門的話題可能就是運維自動化,而且這種熱門的趨勢按照目前的發展態勢,應該會繼續擴展到2019年、2020年……工具
各行各業的中大型企業的IT部門,幾乎都在考慮着手進行IT運維管理的變革和向自動化運維的轉型。測試
鑑於此,做爲一家在IT服務領域深耕18年、在傳統IT運維管理層面有着深厚沉澱和積累、並與騰訊藍鯨聯合開拓自動化運維市場已達2年的企業,嘉爲科技以「研運一體,數據驅動,讓運維走向運營」爲主題,在北上廣深進行了四場關於「自動化運維及運營」的分享活動,來介紹接下來的自動化運維時代對於企業的IT管理究竟意味着什麼,以及在這場大潮中,企業的IT應該如何作,才能確保可以緊跟企業業務發展的步伐,不落伍,不掉隊,並持續給出最有力的支撐。大數據
毫無心外,場場爆滿:spa
廣州分享活動現場操作系統
深圳分享活動現場
上海分享活動現場
北京分享活動現場
活動經常爆滿的背後,是你們對於自動化運維的共同需求,以及在推進IT運維自動化過程當中有着相同的困惑,好比:
企業落地自動化以前是否必定要先實施標準化?
咱們的CMDB配置數據不許確,如何實施自動化?
據說騰訊藍鯨很強大,用藍鯨和Ansible實現自動化到底有何區別?
咱們也想用騰訊藍鯨來落地本身公司的運維自動化,可是以往踩過太多坑了,會不會用了藍鯨以後,又上了另一條使用門檻高昂,難如下去的「賊船」?
若是你也有着相同的疑惑,同時沒可以親臨現場,傾聽嘉賓的講解,也不要緊,咱們在這篇文章中一塊兒來解答上述的困惑,並最終回到一個出發點:自動化運維時代,咱們該如何作纔好。
首先,咱們須要回答一個問題:你們一直在提自動化運維,自動化運維到底包括哪些方面呢?
全球最具權威的IT研究與顧問諮詢公司Gartner對此的定義以下:
自動化運維是經過工具或者平臺,實現IT基礎設施和應用的平常任務和運維流程自動化,從而提升效率,下降風險,促進組織業務能力提高。
主要包括:平常任務處理自動化、運維流程自動化、IT服務自動化、業務服務自動化以及總體運維運營能力升級等內容。
針對上述自動化運維的範疇,Gartner還定義了成熟度模型,以下圖所示:
Gartner將企業實施自動化的成果分爲起步、基本、標準、合理、動態等5個階段,在每一個階段定義了企業應該達成怎樣的目標,如上圖所示。
無獨有偶,在藍鯨的落地實施過程當中,針對企業的運維現狀,由淺入深通常建議按照:基礎架構自動化、應用自動化、IT服務自動化、業務運營自動化;事實上,這四個階段基本對應着Gartner的「基本、標準、合理、動態」四個階段;殊途同歸,異曲同工。
基於上述對於自動化的理解,嘉維藍鯨自動化運維解決方案提供了一套標準的,符合Gartner定義,並貼近國內IT現實的自動化運維全領域視圖,以下所示:
在上述視圖中,若是說騰訊藍鯨平臺是自動化運維這棵大樹的主樹幹,那麼:基礎架構自動化、運行監控和故障管理、業務應用自動化、運維流程自動化就是在數幹上長出來的樹枝;加上統一運維門戶,他們一塊兒構成整個自動化運維的大樹。
先說咱們的理解:標準化固然要作,可是沒有工具支撐的標準化都是耍流氓;所以二者能夠同步和諧進行,甚至能夠先構建自動化平臺或者工具,再在平臺上將咱們的標準化落地爲具體的自動化流程或者功能。
爲何這麼說呢?
騰訊藍鯨產品中心總監黨受輝同窗常常提到的一個觀點:要實現一個目標,須要三個要素——理念先行、責任到人、工具支撐。
在實現IT運維標準化層面,也是相同的道理。
例如咱們要落地IT基礎架構平常運維的標準化,天然是先把口號喊出來,最好辦公室裏貼上一個「奮戰100天,完全實現基礎架構標準化」紅色橫幅,對吧?
而後走的遠一點的公司呢,可能會專門成立一個標準化小組,來貫徹執行標準化改造的工做,成果通常是交付一大堆關於機房機架管理規範、配置管理標準流程、Linux 生命週期管理規範、平常運維操做規範手冊等的文檔,而後就沒有而後了。
你若是真誠的(哎,說你呢,把鼻子上的兩根蔥拔掉)、認真的回憶下本身公司過往的標準化項目經歷,上述的場景是否是很熟悉呢?
究其緣由是:離開自動化的平臺或者工具支撐,這種標準化不過是空中樓閣,落地成本巨大(你想象下,凡事都要按照標準流程手動執行,又沒有自動化工具幫助你,你什麼感覺?確定是原來怎麼幹,繼續怎麼幹嗎);落不了地,也談不上改進和調整標準化流程,最後天然是束之高閣,不了了之。
反過來說,好比咱們將企業內一個數據庫VM交付的流程經過藍鯨自動化運維平臺,固化成一個流程,這個流程,運維人在自動化平臺上能夠一鍵交付;若是這個流程後續知足不了標準化的要求,咱們只須要調整中間的流程節點便可(例如配置信息不知足標準化規範,能夠調整配置生成的流程原子,使之符合規範),或者從新再造一個標準化流程,成本也很是低(由於藍鯨支持組裝式流程編排,而且構成流程的原子自己能夠無限複用),經過這種方式確保標準化可以真正落地,並能持續改進,同時基於自動化平臺,使得這種流程自己執行和改造的成本都是很低的。
在藍鯨平臺上,爲運維標準化的落地提供了包括PaaS層平臺、SaaS層工具等各個層次的支撐,包括CMDB、資源交付自動化、IP地址管理等等。
標準化支撐工具-CMDB
標準化支撐工具-資源交付自動化
標準化支撐工具-網絡IP地址管理
數據中心是企業的IT心臟,涵蓋了從中間件、數據庫、操做系統等軟件到堡壘機、防火牆、路由交換、備份存儲、服務器等硬件的基礎架構。
回顧咱們前面提到的Gartner的階段劃分,自動化運維基礎層面的實現,就是實現基礎架構資源運維管理的自動化。而藍鯨徹底具有這樣的能力。
而且藍鯨在實現基礎架構自動化的過程當中,有一套通用的方法論來支撐,就是OASR模型,四個字母分別表明的是:運維對象(Objects)、運維活動(Activities)、運維場景(Scenes)、運維角色(Roles)。幾乎任何一個IT對象的運維管理場景都會涵蓋上述四個方面,不一樣的運維管理操做的過程其實就是上述四個指標項從新組裝的過程。
對於藍鯨平臺而言,經過藍鯨管控平臺提供的agent代理、API接口、遠程腳本調用等方式,可以實現運維對象的統一接入、納管以及腳本、文件、數據層面的驅動;
而藍鯨的做業平臺、標準運維、配置管理、容器平臺、大數據平臺等PaaS模塊涵蓋了幾乎企業全部IT運維運營所須要的能力,而且可以實現模塊能力的持續複用和自定義組裝;
另外,藍鯨的開發者中心所提供的敏捷APP開發功能,使得不管咱們面對如今仍是將來的各類運維運營場景,均可以經過自定義開發新的APP方式從容應對;
而針對運維人員和權限的管理,藍鯨提供了統一的權限管理中心做爲統一的控制中樞,同時可以對接AD、OpenLadp等目錄管理,實現用戶、角色、權限的統一認證和管理。
能夠看到,基於OASR方法論構建的藍鯨平臺,在自動化運維基礎架構層面,能力是很是強大的。
操做系統生命週期自動化管理
數據庫DBA統一工做臺
中間件管理工具之一__配置及監控管理
藉助於藍鯨強大的標準運維編排引擎,藍鯨能夠實現很是強大的跨越系統、應用、數據中心、工具平臺的端到端的編排操做。
關於藍鯨標準運維的能力,你們能夠參見咱們以前的文章《看藍鯨標準運維如何編排一切》,裏面對此有很是詳細的講解。
藉助於標準運維:
咱們首先考慮清楚須要實現哪些運維場景的運維流程自動化;
接下來就是進行運維流程的梳理和每一個原子節點操做的定義;
而後須要考慮哪些人可以執行這個操做,進行權限的配置;
接下來即是每一個原子操做的快速組裝開發;
再將原子經過圖形拖拽的方式組裝成流程;
進行測試後,就能夠發佈爲生產環境的流程,供運維人員使用。
標準運維編排的方法論
標準運維編排的方法論
藉助於標準運維,咱們自定義各類各樣的運維流程和操做場景,好比應用發佈自動化、ITSM工單自動化、應用災備演練自動化、AD與Exchange協同自動化等等。
最爲重要的是,在每一個場景中固定下來的原子均可以在將來進行無限次複用;除此以外,因爲藍鯨的ESB可以對接企業內各類第三方系統,由於這種編排能夠持續知足將來的運維場景需求。
應用發佈自動化
災備演練自動化
業務場景自動化
故障自愈多是藍鯨平臺在業內首倡的理念,同時藍鯨的故障自愈在騰訊內部的大規模環境中也是用的很是普遍的功能。
故障自愈的原理很是簡單:
接入監控數據源 → 識別告警,匹配故障自愈策略 → 自動化執行告警 → 通知管理員。
可是,這裏也須要一個前提條件,就是這種故障自己,在咱們的環境中出現的緣由是能夠窮舉的,而且咱們有成熟的處理流程和規範,這樣纔可以制定出恰當的故障自愈策略。
故障自愈的方法論以下,先須要對故障作分級以及處理邏輯的制定:
故障自愈的總體架構以下圖所示,這裏的監控告警源既能夠是藍鯨自身的藍鯨監控,也能夠來自其餘監控系統,好比zabbix等;而自動化的故障自愈自己則須要依賴藍鯨的自動化運維的能力去驅動、調度和實現:
支持自定義故障自愈策略
除了執行自動化運維操做以外,咱們在平常的管理中,還須要對各類各樣的數據進行彙總、分析、查詢和展現,這種需求既可能來自IT運維人,也能夠來自IT或者公司上層的領導,這個時候能夠經過嘉維藍鯨的數據可視化模塊,實現很是靈活的數據接入、分析和展現功能。
IT運維自動化時代已經來臨,對於企業而言,這是更迭本身IT運維管理模式與階段的時代,對於運維人而言,也是能夠大展拳腳的時代。
而藍鯨可以在企業IT運維轉型及運維人的轉型上,助一臂之力。
轉載請註明出處。