拿什麼解救你我的指令碼？

騰訊織雲發表於2018-09-17

本文由陳鎮杭發表於騰訊織雲公眾號

隨著雲端計算的不斷髮展，從最初的網際網路初創企業，到現在的政府機關、金融和證券等行業，都在往雲上遷移。在建設運維平臺的過程中，大部分企業對於自動化運維能力非常重視，期望平臺能管理好運維的批量作業以及日常運維操作，而且對於效率、安全和審計等方面的要求特別高。織雲作業平臺，正是為了解決當前使用者對於自動化運維的種種迫切需求而產生的。

本文介紹了織雲作業平臺的設計初衷，發展歷程，以及如何採用作業平臺逐步地將日常運維工作規範化、標準化。

起步—工具建設

日常的運維工作中，存在著大量的重複度高的工作需要被執行，經常會出現需要開啟很多個終端執行一個指令碼的場景。

小H的故事

以某個公司的運維同學小H為例。小H平時會將見的業務處理流程中按照步驟和對應的命令記錄在筆記中。需要上去處理問題時，小H是這麼做的：

在筆記中找到對應的處理方式
開啟終端，登入對應的機器
按照步驟，貼上程式碼、執行、檢視執行結果。

小H覺得，這種方式足夠應對平時的工作。

直到有一天，小H在執行A服務的遷移時，突然B服務反饋了一些問題，需要協助排查，於是，在已經開啟了好幾個終端的情況下，小H再開啟一個終端，登入了服務B的機器。解決完B問題之後，剛好又遇上臨時開會，小H走開了一下，之後回到工位上繼續操作。

剛剛A服務的遷移執行到一半，小H從當時的步驟，繼續操作，複製命令，繼續貼上到終端，沒想到，剛剛服務B的終端沒關，誤將一條重啟服務的命令，貼上到了B伺服器的終端上並執行，導致B服務短時間內無響應。

從成本和安全的角度出發，小H的工作方式中存在著這些問題：

• 人肉上機器執行，執行效率低，沒有做好審計，同時也存在極大的風險；

• 管理混亂，大量指令碼/工具無處安放，無法很好地整合；

• 運維各自建設工具，存在大量重複建設的問題；

• 學習成本高，使用指令碼/工具的人往往需要了解整個指令碼後才可以放心使用。

為了解決使用者存在的這些問題，織雲作業平臺也就應運而生。從使用者（運維人員）的角度出發，我們將工具作為我們整個系統的核心進行建設。圍繞著工具做文章，將工具從建立、編輯到執行以及執行記錄的整合納入我們系統的能力中。

在作業平臺中，工具作為最小的操作單元，將常見的運維操作從日常的運維場景中抽離出來，獨立為一個最小的原子性操作，賦予相應的描述資訊和基本特徵（比如執行環境、超時時間等），像程式語言中的函式一樣，具備最基本的獲取輸入引數以及返回值的能力。

• 工具的詳細資訊

• 工具的引數配置

作業平臺提供多種的內建引數型別，滿足使用者在定義輸入輸出時的需求。

• 工具的程式碼內容

通過以上對於工具的基本資訊，對使用者一個個的指令碼進行包裝，對於使用者來說，再也不需要過多地瞭解指令碼的內容，可以從工具的描述以及輸入引數的描述中瞭解該工具的功能以及引數的作用。

作業平臺提供了一個簡單的介面供使用者執行工具使用，執行工具時，只需要傳入工具所需要的輸入引數，並指定工具的執行機器，剩下的工作，包括將工具分發到指定機器上，發起執行，收集執行結果等，都交給作業平臺來解決。

• 執行工具的介面

可以看到，前端可以根據工具採用的引數型別展示相應的輸入框，並做基本格式校驗，很大程度上簡化了對引數的處理。

同時，在選擇執行機器上，採用了業務裝置選擇器，方便使用者選擇裝置，儘量避免手動輸入可能造成的誤差。

• 執行結果的展示介面

支援根據機器檢視執行的日誌和返回結果，也可以批量匯出所有資料。

進階—編排整合

在完成了對於工具的封裝之後，使用者對我們作業平臺的能力又提出了新的要求，即解決工具間的執行順序的依賴問題。

前面我們講到，工具在我們系統中的定位是一個最小的操作單元，即專注於完成一項特定的任務。而實際的運維場景中，往往需要多個工具組裝起來一起解決一個特定的問題。

比如我們下面提到的例子，使用者需要做一個機器日常的巡檢，需要將工具順序執行，後面三個步驟的資料依賴於第一步的工具獲取到的機器列表。

從上面的圖中可以看出，使用者對於作業執行的要求有這麼幾點：

• 支援按照定義好的執行順序執行相應的工具；

• 支援引用其他工具的返回值作為當前工具的輸入；

• 支援將執行順序、引數對映關係“包裝”成模板重複使用；

• 只暴露一部分執行時需要使用者輸入的引數供使用者手動指定。

為了滿足這種需求，織雲作業平臺中，採用了編排的方式來解決工具間的依賴關係，編排的模板包括瞭如下資訊：

編排基本資訊：包括編排名稱和描述；
編排的引數：當前編排需要使用者輸入的引數列表；
編排步驟：

i. 每一個步驟都對應一個工具，步驟與步驟之間是序列執行的；

ii. 工具所需要的引數可以從其他工具的執行結果或者編排引數中獲取；

iii. 可以指定當前步驟執行完成後是否需要使用者確認後再繼續執行。

上述需求在作業平臺中體現為如下的編排模板：

在這個例子中，使用者只需要輸入相應的模組 ID 即可完成對模組裝置的巡檢工作：

這種方式，滿足了絕大多數的應用場景，比如擴容、初始化裝置等操作。

通過編排的方式，我們讓更多的工具有序地組織起來，通過不同的搭配，滿足使用者各種需求場景，讓工具發揮出更強大的實力。

擴充套件—融入更多模組API

在前面講到的日常的裝置巡檢例子中，有一個工具的作用比較關鍵——根據模組 ID 獲取機器列表，因為需要用它將使用者輸入的業務模組 ID 轉換成機器列表，作為後面一系列工具的執行物件。

這個工具的實現思路，一般來說，就是發起http請求織雲CMDB的API介面，傳入業務模組 ID，獲取裝置列表，設定到返回值中。但是，直接讓使用者在工具程式碼中構造一個個http請求呼叫後臺API介面，有這麼幾個弊端：

• 構造過程比較繁瑣，需要使用者反覆除錯；

• 程式碼不好複用，容易造成大量重複勞動；

• 在工具中發起對後端的http請求，不利於安全審計，存在隱患。

從另一個角度再來看這個工具。我們的織雲CMDB、包系統以及監控等都是圍繞著自動化運維能力去建設的，作業平臺作為一個子系統，在織雲的體系中的定位，是對於各個平臺所提供自動化運維能力的整合和擴充套件。因此，在我們的體系中，工具不可避免地會大量呼叫到其他系統提供的介面，實現資料查詢或者自動化操作處理等作業。