運維,請不要過度迷戀指令碼,謹防引起不可預知災難!

2019-09-06 08:20:27



過分依賴是指令碼,是運維非標準化的體現!
指令碼災難,就是運維場景管理上直接依賴大量的指令碼來完成事務。


做運維的同學都知道,指令碼是一個必備技能,在每個 JD 的崗位中必然出現。在我們的日常運維過程中,指令碼發揮作用的地方也比比皆是:系統管理的指令碼;應用釋出的指令碼;網路管理的指令碼;儲存管理指令碼等等,更復雜的場景也有用指令碼封裝來實現的都有。彷彿指令碼成了運維的大殺器,特別是 Python 語言起來之後,更是一發不可收拾。在某銀行客戶中遇到,他們運維積累了近兩千個指令碼,這真的是對的?


如果一個事情變得複雜不堪的時候,我便會質疑它是否是對的?這一點在我做產品的過程中,有深刻的體悟,回頭得空體悟。


今天我們過分依賴指令碼作為一種最初的操作入口,對各類物件進行操作,我形象的給他比喻為是過程程式設計的模式。在大部分客戶中,由於自動化運維平臺的缺失,指令碼還處於混亂的管理之中,這種混亂表現在:無版本管理;無測試管理;無集中管理,還散亂在各個運維人員手中 。這種情況下,指令碼的災難不可避免。


隨著這兩年的自動化運維平臺被不斷接受,很多客戶開始接受平臺的管理模式,大家更接受了一種形態是——原子作業庫和基於原子作業之上的排程編排。運維開始變一股腦往運維平臺中寫原子工具,然後通過運維工具來構建複雜場景的運維場景編排。這個地方尤其要注意:這種編排還是一種過程編排的模式。


在這種模式下,大家不知道注意到一個有意思的現象沒?複雜的過程編排,存在大量的複雜引數傳遞,每一個工具都有入口引數和出口引數的設定,排程設定介面非常難以簡化。

如果這麼複雜,是不是設計上又是錯的呢?那錯的根源到底在哪兒?方式、方法或者是理念設計上就出現了錯誤。在這個機制之下,出於指令碼安全的需要,我們有必要強化幾個能力的管理:

  1. 版本的管理。讓工具的修改有序進行,可以回溯,對比等等

  2. 工具的開放性管理。工具設定成公開和私有管理,確保工具使用的範圍。

  3. 工具的稽核管理。工具的每一次變更,必須通過稽核才能入庫。

  4. 工具在流程中的引用管理。排程流程是引用工具,當工具產生修改,不直接對流程產生影響。


最後一點,我要把具體的做法明確一下,就是流程引用的是工具的快照,確保工具發生修改,能夠避免對流程帶來影響。就如同在 AppStore 中應用更新,客戶可以收到更新的通知,但不代表系統給你立即更新了。尤其注意!


這個時候我想說,引起指令碼災難的核心原因:非標準化的過程管理的思維嚴重,指令碼便是最快的想工具。


那到底如何解決?如何避免指令碼依賴引起的指令碼災難?


首先我必須得說,大量不標準的IT物件存在,我們需要接受指令碼存在的合理性,而我們必須要面向未來做出一些改變。如何更有效的管理指令碼?在之前講到的引入 version control 能力,版本化控制,還不夠。我覺得更需要引入 IT物件管理的概念,把所有的方法附著到物件上,讓工具方法自動繼承物件的屬性,簡化工具的引數管理。


何為 IT 物件?從角色出發,所有形成IT場景管理的都可以稱之為物件,比如說網路管理員管理的網路裝置;系統管理員管理的 OS;DBA 管理的資料庫等等,是一種業務邏輯世界的理解;應用看到的應用系統,應用元件等等。


對於任何物件,從技術的角度來設定的抽象邏輯是:

1、物件屬性

是一個物件的描述,和麵向物件一樣,其中包含很多屬性與物件的關係。拿主機做例子:

  1. 屬性維度:固定資產編號,採購時間,過保時間;

  2. 關係維度:負責人,網絡卡、CPU、記憶體和 IO


2、物件的方法


物件的方法就是我們平時的管理動作或者場景,比如說主機的重啟,主機的啟動/停止,主機的回收,主機的申請等等。這些動作比如對其狀態和屬性產生影響。


3、物件的狀態

物件在服務支撐過程中,必然會產生一些狀態資訊,是一種執行健康狀態的表達。

4、物件的事件

事件是一種狀態變化產生的結果,比如說狀態異常產生的簡單事件,如告警,狀態經過模型計算產生的複雜事件,比如說容量事件。當然還有一個維度是人工操作事件。


當然提到了IT物件管理能力,如何降低物件複雜度的表述?這就轉換成一個IT物件標準化的課題了,是不是邏輯就簡單了。物件的標準化是運維必須面臨的課題,必須要直面。把IT物件複雜度降低,你的管理複雜度隨之下降。


此時對服務編排就有更高的要求了,不限於過去簡單的類流程引擎編排能力,需要把過程編排和物件編排(藍圖編排)合二為一。此時提到的藍圖編排方法,我還不提 TOSCA 規範,那個我依然今天對很多基礎設施來說要求很高,畢竟支援 TOSCA 的基礎設施也不多。請對你的流程編排引擎進行升級吧,讓他支援物件編排。自定義物件管理庫,把過程編排和物件編排的混合編排能力構建起來,從而滿足不同業務管理的需要。


總結來說,避免指令碼災難的方式,必須從過程管理模式變成物件管理模式以物件作為管理視角,為其構建管理方法(或者指令碼或者程式碼),通過物件來收斂管理入口,避免運維人員直面指令碼氾濫。同時基於複雜的場景能力,也起到收斂工具指令碼編排的作用。

來源:網際網路運維雜談

原文:http://t.cn/AiQ22uj0

題圖:來自谷歌圖片搜尋

版權:本文版權歸原作者所有

投稿:歡迎投稿,郵箱: editor@hi-linux.com


你可能還喜歡

點選下方圖片即可閱讀

阿里巴巴如何有效地管理億萬級 Kubernetes 叢集,看完本文你就明白了?


已同步到看一看
在看



熱點新聞