01. 何為自動化運維&普通運維?
在了解兩者的區別前,我們得先明確對二者的定義,總的來說運維工作的目的都是為了保障企業業務連續性,核心在于提供高效、高質量、安全的IT運維服務。
大部分人對“普通運維”的認知應該是指IT的傳統運維模式,大量依靠人工的手段去維護企業基礎設施和應用運行穩定,基本都包括日常維護、監控保障、變更發布、資源管理、運維流程、服務支持等內容。至于“自動化”這一詞,隨著現代控制理論和電子計算機的出現,更多的是指將自動控制和信息處理相結合,使得機器設備、系統或過程在沒有人或較少人的直接參與下,按照人的要求,經過自動檢測、信息處理、分析判斷和操作控制來實現預期的目標的過程。
放到自動化運維的維度,更多的是針對特定的運維場景,將運維一線人員長期做的一些周期性、重復性的工作抽離出來,借助自動化工具或平臺來替代或協助完成運維工作,提升運維效率降低系統風險,促進運維組織的成熟和能力的升級。
“普通運維”和自動化運維并不存在嚴格的邊界劃分,自動化運維是普通傳統運維演進的一種更高階狀態。至于為何企業運維部門會大力投入資源做運維的自動化升級,根源在于圍繞運維的三個核心(效率、質量、安全),原來的傳統運維方式都存在著對應的問題:
就筆者近幾年在各個行業內的調研和實踐情況來看,企業IT部門的數字化水平和運維部門的工具能力建設都難以支撐或無法完全替代傳統運維的全部工作,要實現真正意義上的完全自動化運維還存在包括運維技術和理念、企業內部管理制度和工作規范等等的約束,但傳統運維方式向自動化逐步演進的趨勢是可以預見的。
02. 企業從傳統普通運維向自動化運維升級能否一步到位?
2016年互聯網行業開始進入所謂下半場,各種“數字經濟”“云原生”“大數據”“AI”等概念層次不窮,傳統行業特別是金融、能源、政府單位等也開始卷入數字化轉型的大潮,從業務端數字化最先開始也即轉向O2O、云計算到傳統開發架構轉向云原生,最終運維也隨之主動或被迫迎來屬于自己的數字化轉型。
其中自動化運維就是數字化轉型中很熱門的話題之一,在2017-2020年間是各企業/單位紛紛上馬各類自動化運維項目最為活躍的時期。但在落地后的一段時間漸漸會發現還是存在種種的問題,比如各工具相對獨立無法實現聯動,工具擴展性能差,開源工具漏洞無人維護,IT的配置數據不準確等,原本的目的是希望借助自動化工具能提升運維的效率,沒想到在某種程度上反而成為制約運維效率提升的原因之一。
近兩年來這些企業又開始返工,回來重新修煉“基本功”。在筆者看來要實現從普通運維向自動化運維的升級,必須先做好以下幾方面的基本功,否則自動化運維只會曇花一現,無法持續的支撐運維工作,更談不上提升運維工作的效率和保障業務的數字化轉型。那么企業要實現自動化運維之前要做好哪些鋪墊呢?
筆者認為運維的數字化轉型依次遵循“對象數字化”、“行為數字化”、“運營數字化” 的方式是目前最佳的演進路徑。具體來說,建議企業在對運維進行數字化轉型或運維升級的過程中,首先將CMDB作為企業IT架構進行數字化描述的基礎,只有實現IT架構中每一個對象的數字化,才能實現其狀態的數字化,從而實現其可觀測性,進而通過操作和服務行為的數字化,實現不同場景下的運維自動化來保障業務的連續性和敏捷性。在此基礎上才有可能實現運維的終極目標——構建企業級的技術運營體系,全面支撐企業數字化實現成功。
值得一提的是,并非要求所有企業一定嚴格按照以上的路徑來提升自己的運維水平,建議企業可以根據自身的實際情況在統一的運維平臺之上進行建設,一方面對于已有的工具可以盡量整合充分利舊,另一方面對于缺失的能力進行補足和加強。
03. 那么企業如何真正的落地自動化運維呢?
如果我們企業在前期已經有了相對扎實的基礎,比如有比較完善的配置管理系統、監控告警體系和運維流程管理平臺再來考慮自動化運維的建設會更加合理,避免出現返工或重復建設的情況,落地的效果和產生的收益也會更顯著。筆者認為落地自動化運維要分為以下幾個步驟:
1)評估企業所處的運維發展階段
企業可組織梳理現在內部的運維工具特別是自動化工具的建設情況,是否具備腳本/命令批量執行、文件下發和數據采集能力,是否具備作業執行包括定時、API調用和作業編排的能力,是否擁有跨區域的平臺底座,評估現有人員的配置情況和能力。最簡單的方式見下圖判斷企業目前處于自動化運維成熟度的哪一階段?
2)打造統一的自動化運維平臺
組織一個團隊負責自動化基礎平臺的建設,IT各個部門和組織根據需求自行在平臺上開發SaaS工具。既要求發揮多方的積極性,又可以形成很好的合力,兼顧個性化需求和團隊共性。這就對平臺本身的建設提出極高挑戰,要求能夠提供統一架構、統一認證、統一調用、統一接入等能力,實現自動化工具的敏捷和快速迭代。
這意味著自動化運維平臺的能力層(PaaS)需要將原有的運維能力進行拆分,將公用的能力沉淀下來形成各個原子比如有管控平臺、作業平臺、標準運維等,有統一接入的接口API Gateway能對接外部的系統和第三方工具(iPaaS),同時具備基于PaaS的開發框架針對不同的運維場景去做運維工具的開發(aPaaS)。正是基于運維平臺開發的所有自動化工具才能在平臺上能實現天然的交互聯動,形成真正統一的自動化運維平臺。
3)梳理企業現有的運維流程
絕大部分的運維流程都會同時涉及到各類操作執行流和審批流,因此有必要提前梳理清楚各類運維流程,比如在金融行業都會有非常嚴格的運維流程要求,一般都會參照像ITIL、ISO20000、ITSS等的標準去建設。對于已完善的流程要梳理哪些環節可以通過自動化手段代替或協助完成,保證涉及的流程節點盡量實現線上化、自動化、標準化,以此提高整個流程的效率。
4)在運維平臺上持續構建自動化運維場景
通過OASR(對象-場景-工具-人員)模型具體分析運維場景,首先明確針對的是哪些運維對象、應用系統和基礎架構;其次梳理現有運維的組織架構中人員的構成,針對這些運維對象可以使用哪些運維工具;最后我們對運維操作進行編排和執行,形成自動化運維的場景。按這類方法梳理出來的場景會有很多,在這里我們核心解決日常運維任務、應用發布、災備切換、資源交付等自動化場景。
04. 嘉為藍鯨提供的自動化運維解決方案
針對不同的運維場景,嘉為藍鯨提供一系列自動化運維解決方案,自動化運維提升的關鍵在于IT對象執行能力的整合和場景構建。為實現ITOM融合的體系自動化并全面覆蓋運維工作,需在執行能力整合達到運維能力原子化的基礎上完成跨IT對象的執行編排調度,從單對象的自動化突破到發布、災切、應用巡檢等復合場景的構建。
限于篇幅的原因,在這里筆者提供三個常見的自動化運維場景(應用發布自動化、災備切換自動化、巡檢自動化)供題主參考,后續其他自動化場景可持續擴展。
1)應用發布自動化
背景:應用架構不斷更新,用戶需求激增,應用數量成倍增長,發布迭代的速度越來越快。應用運維確保應用穩定運行,還需同時響應研發、業務訴求,完成版本變更或上線交付,提供相關服務給到業務、運營和測試等外部人員。 產品能力:嘉為藍鯨應用發布中心支持單體、SOA、微服務、容器化應用的發布與管理;支持程序包、配置文件及其實例化、SQL包、模板集(K8s YAML文件)的發布;支持多應用、多實例、多環境、多集群發布;支持定時、并行、滾動、分批發布、藍綠發布、灰度發布等方式;可快速發布或回滾,具備靈活的可視化編排引擎。幫助企業高效、快速、規范、穩定地實現自動化部署。
2)災備切換自動化
背景:企業對業務中斷的容忍度不斷降低,業務架構復雜度提升,切換流程也越來越復雜。企業能否順利完成災備切換,取決于災備系統的建設,災備演練是否充分以及災備切換步驟是否準確到位。同時企業需要通過實際的災備切換演練來不斷地優化改進災備預案。
產品能力:嘉為藍鯨災備切換自動化提供靈活的流程編排能力,幫助企業實現應用災備切換及恢復的預案管理和操作自動化,支持一鍵災備切換和大屏跟蹤展示,能夠保證企業定期災備切換活動的成功進行,同時助力企業數字化轉型。
3)應用巡檢自動化
背景:自動化巡檢是對網絡、服務器、服務/應用的巡檢手動操作轉變成自動化的形式。通常巡檢工作面臨如下幾個場景的問題:
產品能力:嘉為藍鯨自動化巡檢中心改變運維人員傳統重復手動巡檢的工作方式,支持用戶自定義巡檢腳本和巡檢對象,覆蓋即時性、周期性等巡檢場景,根據任務計劃實現自動化巡檢并生成標準可視化報告,減少巡檢工作量并提高巡檢有效性,助力運維人員輕松全面掌握IT對象運行狀態及潛在風險。
申請演示