關注嘉為科技,獲取運維新知
現在大家都在講智慧型化運維,自動化運維已經逐漸少有提及。這是乙個理念和技術演進的正常過程,自動化運維已經從一種思潮和探索正在轉變為落地和使用。越來越多企業已經開始落地自動化運維,在真正把步子邁出去的時候,發現自動化運維原來並不是一件複雜的工程,很多企業其實早就開始建設了。
說到這裡,就要從運維的本原**。我們這裡把運維的詞義進行狹義的思考,其實就是對伺服器及應用進行維護管理,那麼所謂自動化運維就是把維護管理的動作規範化、批量化、自動化。如果從這個角度去考慮,很多企業很早就建設了自動化運維工具,如微軟補丁管理wsus、微軟sco等工具,只是過去我們並沒有意識到而已。
既然如此,又是什麼原因導致自動化運維突然火熱起來了呢,作者認為如下兩個原因:
隨著運維規模擴大,運維工具也大幅增加,運維工具本身的管理成為必須面對的問題,需要統一集中的運維平台。
網際網路公司作為運維技術先驅力量,在運維中應用了大資料、人工智慧等技術,將運維工作引向了新的高度。
所以,從過去分散狀態的自動化運維建設正在轉變為以平台為基礎的建設模式,平台能力主要體現在:
進而,在很多企業中自動化運維建設分為兩層建設:統一先進的自動化運維平台和持續平台上構建運維場景。我們下面分別進行**。
不同規模公司在平台建設上思路不同,總結來說有如下兩種模式:
1、自研平台或基於開源改造
大型網際網路公司和巨頭企業多採用這種模型,專門組織乙個部門開展自動化運維平台建設。這類公司在一定程度上可以保證人員的穩定性和專業性,其業務收益也可以支撐長期的的高昂成本投入。 這種模式的優點是具備完全的自主性,在滿足自身業務的同時,也可以將自研的技術商業化,變it成本部門為it利潤部門。
缺點也是顯而易見的,如此大投入、長週期,深度的技術沉澱,是絕大多數企業無法承受的。同時也需要面對失敗的風險,所謂「一榮俱榮,一損俱損」。
2、引入上述公司的產品
其缺點主要體現在自主性上,這就要看選用產品的開放程度了。
運維場景與運維平台有很大不同之處,運維場景是多樣化的、個性化的、是無法窮舉的。話雖如此,根據不同場景的特點仍然可以分為操作類、展示類、決策類。這裡著重分析各類運維場景的特點和構建方法。
1、操作類場景
在自動化運維建設前期此類場景最多,往往能佔比到60%~70%。這類場景明顯的特點是可以手冊化,即可將運維操作步驟一一寫出來,並按照某種邏輯順序按步執行皆可完成。諸如版本發布、資源建立、許可權開通等。有些操作流程可能很長,而大多數操作都是短流程。在梳理這類運維場景時,可以參考以下原則:
在建設前期可不必追求流程設計的優雅性,能確保流程的正確性和穩定性,流程節點多一些並無關係,關鍵是可以實現端到端的全流程自動化操作。
2、展示類場景
這類場景可以在運維工作中佔比到20%~30%,在面向應用的運維中應用較多,在實現邏輯上可以分為三層:採集、處理、展示。
在建設前期可選擇簡單的場景建設,逐步培養人員運維開發能力,逐步過渡實現複雜場景。
3、決策類場景
決策是自動化運維高階需求,往往需要用到大資料、機器學習等前言技術,我們後續開專題進行討論。
自動化運維工具之fabric
fabric fabric是乙個基於python 2.5 2.7 的庫和命令列工具,用來提高基於ssh的應用部署和系統管理效率。稍微了解python的人都知道,實際上它只節省了數行 ifname main 這樣的慣例 而已。fabric 的設計目的更是為了使用它自己的 api,包括執行 shell ...
自動化運維工具ansible簡單介紹
yum update yuminstall ansible 驗證ansible是否成功安裝 ansible version在 etc ansible hosts中按照格式新增相應的主機 在 etc ansible ansible.cfg關閉ssh金鑰檢查 使用命令指定test組建立檔案 root n...
運維工具之輕量級自動化運維工具Fabric原始碼安裝
在運維工作中,經常會遇到重複性的勞動,這個時候為了效率就必須要使用自動化運維工具。這裡我給大家介紹輕量級自動化運維工具fabric,fabric是基於python語言開發的,是開發同事的最愛。為了方便自動化運維,經常會將fabric部署在跳板機上。之所以部署跳板機是基於幾點考慮的 安裝fabric時...