GitChat · 運維 | 攜程運維工作流平臺的演進之路

NO IMAGE

GitChat 作者:徐豪傑
原文: 攜程運維工作流平臺的演進之路
關注微信公眾號:GitChat 技術雜談 ,一本正經的講技術

【不要錯過文末活動】

前言

隨著網際網路技術的迅速發展,運維的事務也日益複雜,如何能更加高效的協調好人、工具與流程之間的關係,把運維人員從低效率、高強度、易犯錯的人工操作徹底解決出來,讓他們的能力與精力有更大程度的發揮,將是一個很大的挑戰。

攜程運維工作流平臺在經過三年時間的演進,從最開始引入商業產品BMC Remedy ARS做為底層單一工作流引擎,慢慢演化到抽象工作流平臺的建設並擴充套件支援更多開源的工作流引擎,同時把原來的平臺進一步分層、建立了統一標準的介面,對業務進行了服務標準化、業務流化以及流程自動化的改造。

本文將從以下幾個主要方面分別闡述流程平臺的建設與演進:

  • 面臨的挑戰

  • 運維工作流平臺的建設

  • 收穫總結

  • 下一代流程平臺的設計

  • 未來展望

一、面臨的挑戰

在講挑戰之前,我們先簡單看一下攜程運維工作流平臺的演進歷史:

enter image description here

流程平臺的演進主要分為以下三個階段:

第一階段:摸索期

從2013年下半年到2014年上半年,我們引入了BMC Remedy ARS產品作為攜程IT服務管理工具,但是我們發現它的基於工作流工作的思路可以借鑑到更復雜和核心的運維流程中,所以開始嘗試使用它的底層引擎構建我們自己的流程。

第二階段:成熟期

在2014年下半年到2016年上半年,在Remedy平臺上相繼開發了一系列的流程,包括:伺服器上線、下線,應用上線、下線、擴容、縮容、遷移等等,還包括ENP,API gateway等一系列標準化的介面服務模組,開始漸漸形成流程平臺。

第三階段:革新升級期

在經過了一個成熟期之後,現有的流程也慢慢暴露出了一些新的問題,包括流程的視覺化、價值資料的挖掘、底層流程引擎的單一,為了解決這些問題,我們從去年下半年開始,對原來的流程進行了重新設計,抽象出更加標準化的流程模型,以及標準規範的視覺化和監控。

那麼在沒有流程平臺之前,我們到底面臨著怎麼樣的挑戰呢?

在這裡我給大家舉一些運維過程中常見例子,比如日常工作,當使用者碰到問題時IT部門報障時,使用者如何跟蹤問題處理的進度,又或者當網站發生故障時,如何能夠快速恢復服務,後續的問題分析是否有流程支援,運維人員的日常變更操作,是否有過風險評估以及審批授權,我們又是如何保障配置資料的可靠、準確性,伺服器如何上下線,應用生命週期有沒有統一的管控,等等,正是在這樣一個背景下,我們開始著手設計建設一個綜合的工具平臺來統一管理運維過程中涉及的這些流程。

enter image description here

二、工作流平臺的建設

關於自動化流程平臺建設,自動化的意義相信大家應該都是有共識的,在上面的挑戰中我們已經提到了這些運維過程中大家可能會碰到的問題,那麼我們是如何去建設這個流程平臺的呢?

系統架構

我們先來看一下最初設計的流程平臺系統架構。

enter image description here

從下往上看主要有三層:

底層工作流引擎

前面我們已經提到了,在一開始,我們引了BMC Remedy產品主要作為內部IT服務管理流程的支援,在原有的ITSM包括事件、問題、變更以及請求單基礎上做了攜程自己的一些客戶化定製,同時在這個平臺上設計開發了包括伺服器上、下線,應用相關的上線、下線,擴容、縮容等支撐業務的相關流程。

中間介面閘道器層

在中間介面閘道器這層從左往後分別是OSG服務閘道器、ENP事件通知平臺以及協助工具,為什麼會有這樣的設計呢,主要有以下幾點考慮?

第一, 外部工具服務過多,需要統一標準化管理

需要對流程介面服務進行標準統一的管理,所有工具提供的服務需要註冊在平臺;

第二, 服務訪問許可權的控制

可以通過平臺對提供服務進行許可權控制,可以檢視提供的服務由哪些外部使用者或者工具呼叫,同時申請了哪些外部工具的服務,可以對申請進行授權。

第三, 工具提供的服務質量

可以通過視覺化的前端頁面檢視當前提供的服務的質量,比如服務的響應時間。

第四, 訪問日誌

當進行問題分析排障時,可以有被追蹤的日誌。

第五, 產品侷限

現有解決方案提供的介面只支援JAVA以及基於Web Services的SOAP協議,無法提供很好的擴充套件,所以需要在這層做些介面的包裝,以支援更主流靈活一些介面協議,比如RESTful。

上層外部工具外服

最上面就是需要來訪問流程的所有外部工具服務。

標準服務閘道器 – OSG

OSG是介面閘道器的核心的元件之一,那麼什麼是OSG呢?

OSG,全稱:Open Service Gateway,開放的標準服務閘道器,外部工具作為服務提供者可以將他們的服務註冊在OSG閘道器,其它工具若需要消費可以找到對應的服務,以服務消費者形式申請某項服務的訪問許可權。

enter image description here

當服務與服務之間相互互動的時候,OSG就充當著路由的角色,對訪問的請求進行轉發,OSG另一個主要功能就是流控熔斷機制,可以為服務設定每分鐘最大訪問次數,當最大的訪問次數超過設定閥值時,服務自動設定為Blocked,直到服務提供者重新啟用。

對於工具之間服務相互訪問日誌都會被集中採集並吐到後臺ES伺服器,使用者可以通過前端視覺化的介面對服務的質量、工具的訪問進行實時監控、同時可以根據日誌進行問題排查。

enter image description here

流程與外部工具的橋樑 – ENP

ENP – Event Notification Platform(事件通知平臺),這裡大家可能會有這樣的疑問,這個不就是訊息佇列嗎?可以這麼說,事件通知平臺設計參考訊息佇列,但實現上又稍有些不同,之所以會有這個平臺,是因為從Remedy產生的訊息資料在處理上有些侷限,所有的資料的格式化處理都需要交給ENP,由ENP根據設定規則進行封裝處理後再轉發給外部工具。

為什麼需要這麼一個平臺呢?

剛開始Remedy平臺上開發第一個伺服器上線流程的時候,整個上線流程中涉及到了多個環節與外部不同工具互動,不同工具之間的介面實現非常複雜,所以在流程從半自動化到全自動化的轉化過程中,開發人員花費了大量的時間與精力與工具進行聯調,而且不同介面在實現方式也不統一,比如有些是基於Soap的Web Service,有些是RESTful API等等,另外通過這樣一個平臺可以降低工具之間的耦合度。

舉個場景:

我有一個應用,呼叫了很多其它服務,其它服務有時會發生異常,為此又不想花太多精力去實現與維護。

我希望:

  • 及時通知我

  • 及時通知服務提供人

  • 能看到異常發生頻率、次數、時間

  • 能看到異常的內容

  • 能看到所有通知事件

那麼平臺是如何運作一個訊息從產生到工具的傳遞呢?

  1. 首先需要在平臺註冊一個事件。

  2. 工具訪問之前需要在平臺上搜尋該事件到並且訂閱,需要提供一些必要的資訊,比如工具服務的呼叫地址。

  3. ENP根據規則對訊息進行格式化並封裝。

  4. ENP轉發訊息到外部工具。

  5. 工具回寫訊息到ENP,ENP最終回寫到流程平臺。

enter image description here

流程場景:伺服器上線

下面我以伺服器上線流程具體場景為例進行說明如何設計流程:

在經過前期與各個業務部門,運維團隊一起分析設計出來的最終伺服器上線流程圖,流程由一系列流物件組成,這些流物件可以任務,也可以是子流程,比如下圖中所示的子流程“虛擬機器入池”,同時這些任務與子流程之間由連線物件銜接,比如順序,並行,分支判斷處理。

流程還需要設定了一系列的業務規則,包括審批、狀態遷移、SLA、CMDB資料落地等等。

enter image description here

視覺化的流程執行例項

在有了流程之後,對於不同角色的使用者,比如運維人員、開發人員、流程組以及管理人員,需要有個視覺化的介面:

  • 能清晰直觀的看到所有執行的流程執行。

  • 能清楚瞭解當前某個流程執行或者等待在哪一個環節。

  • 流程的執行狀態、時效。

下圖就是流程平臺視覺化介面,可以看到目前所有執行中的流程例項,它們的執行狀況,流程的執行時間,不同流程的執行數,當某個流程例項執行超過預定SLA時長,也可以查詢超時子單,並找到相應的責任團隊。

enter image description here

通過開啟單條例項資料,可以進一度檢視例項詳情,在此可進一步看到所有執行或者已經完成的任務以及它們的處理時間,一旦任務處理異常掛起時,可以通過檢視任務的責任團隊迅速找到相關責任人進行快速處理。

enter image description here

三、收穫總結

10X服務交付能力的提升

enter image description here

2014年當時還沒伺服器上線流程時,業務部門從提出需求到最後交付平均需要一週左右的時間,最長可能會達到二週,所有上線的相關環節的協同操作幾乎都由低效率的人工完成,很少有工具參與自動化處理,有一個場景讓我至今映像深刻,當時整個網站運營中心的各個運維團隊座位比較近,所有每當有上線的時候,經常會聽到不同團隊之間隔空對話方式進行溝通,還停留在通訊基本靠吼的原始時代,在有了流程支援,這種低效率的團隊合作方式也大大得到了改善,各個運維團隊開始嘗試開發自己的工具並接入到流程,流程也慢慢的從部份工具的接入的半自動化到所有工具接入的全自動化處理模式執行,在流程完全自動化後,最終上線效率得到了大大的提升。

服務流程標準化流程化到自動化

enter image description here

工作流平臺的建設過程主要也是經過了以下幾個階段的發展,

第一,服務標準化, 前面我們已經講到了關於服務標準化,就是把現有的平臺進一步分層,建立標準介面,像OSG這種的標準化介面閘道器。

第二,業務流程化,梳理各項業務,把大部分的IT運維工作流程化,確保這些工作都可重複。

第三,流程自動化,把運維人員從低效率、高強度、易犯錯的人工操作徹底解決出來,讓他們的能力與精力有更大程度的發揮。

在經過成熟期後,現有的流程平臺也逐漸暴露出一些問題,最主要的就是過度依賴單一的底層流程引擎,我們希望能夠擴充套件更多的開源流程引擎,多個流程引擎之間可以隨意切換,最終可以完全替換掉原有的商業引擎,如果需要支援更多不同的流程引擎,那麼對流程進行抽象是必不可少的,建立出一個新的流程模型。另外一個問題,原來的流程引擎只能處理序列、並行以及簡單的分支合流,新一代的引擎可以覆蓋到所有複雜的流程分支處理,接下來的章節我們會講到,如何設計處理複雜的場景。

enter image description here

四、下一代流程平臺的設計

改進後的系統架構

我們再來看一下改進後的系統架構。

enter image description here

可以對比一下原來的系統架構,大家應該能發現他們之間的主要區別,底層除了原先的 Remedy外,可以引入其它的開源流程引擎,比如基於BPMN標準的Camunda,或者Activiti、Airflow、Stackstorm等等,中間也是最核心的就是抽象工作流層,主要以幾個模組組成:

  1. 介面卡

    主要負責不同流程引擎之間的資料對映互動。

  2. 基於BPMN標準的模組,包括倉庫、執行時、歷史、身份

    倉庫(Repository)主要儲存流程的定義以及部署資訊,所有流程執行過程中產生的例項、任務例項以及變數例項的資料會儲存在歷史(History)模組中,執行時(Runtime)模組主要負責所有正在執行中的使用者任務,執行例項以及定時作業等,最後身份(ID)模組是用於儲存使用者、組以及他們之間的關係。

  3. 介面閘道器

    主要負責與原來的介面層進行資料之間的互動,並實現與外部工具服務的通訊前端由自研的Mario運維工作流平臺做為核心資料的視覺化集中展現,監控報表等等。

視覺化

除了原來對流程例項以及例項詳情進行視覺化管理外,底層的其它有價值資料並沒有得到深挖,比如跟業務相關的資料,各個業務部門關心的歷史伺服器、應用的趨勢等,那麼通過新的視覺化我們可以更清晰看到業務部門的相關指標資料以及歷史趨勢。

enter image description here

enter image description here

監控告警-EITS

流程執行過程的異常由監控告警平臺EITS負責處理,通過這個平臺我們可以配置告警策略以及不同報警的分類,一旦流程執行異常時,告警會通過郵件方式提醒使用者處理,使用者可以登入到平臺查詢到對應的告警進行問題處理。

enter image description here

支援複雜流程

前面我們提到了,原來的流程引擎只能處理序列、並行以及簡單的分支合併,在新一代流程平臺我們做了一些設計調整,可以覆蓋所有流程場景,我們以下圖中最後面的一張圖為例進行詳細說明:

  1. 任務a1處理完畢後,同時產生三個並行的分支任務

  2. 分支一由排他性的閘道器處理,根據中間產生的不同資料進行條件判斷,如果滿足條件則執行任務a2,若不滿足,則執行a3,排他性閘道器只會有一個任務被執行

  3. 分支二由包含性的閘道器處理,任務a4 如果滿足條件則被執行,a5始終會被執行

  4. 分支三隻不包括任務閘道器,任務a6會與分支一、二並行處理

  5. 待所有分支處理完成後,流程合併

  6. 繼續處理序列任務a7

enter image description here

五、未來的展望

最後就是我們對未來流程平臺的幾點考慮。

智慧化

目前告警種類過多,很多流程上的異常告警,在經過人工分析後,多數是不需要處理的,我們的目標是系統能做一些基礎的分析,並在自動診斷問題後,對問題進行自我恢復,對於有些需要人工介入的,也能做些初步的分析,同時把經過分析後的日誌傳送給處理人員,這樣可以提高處理人員的效率。

自助式的流程編排

目前的流程的開發還是需要流程團隊參與,我們期望在未來,所有的使用者可以自行編排流程,自行定義流程中的每一步工藝,所有的工藝可以釋出到一個共享的市場,當使用者需要編排流程的時候,除了定義自己的工藝外,也可以引用其它團隊已經寫好的工藝。


實錄:《徐豪傑:攜程運維工作流平臺演進實戰解析》


彩蛋

重磅 Chat 分享:《一場 Chat 讓你搞清 BAT 程式設計師的技術職級》

分享人:
勝洪宇,一線網際網路公司前端技術組長,掘金簽約作者,前端部落格博主,所講課程幫助超過20萬前端小夥伴學習。
Chat簡介:
很多程式設計師嚮往進入 BAT 這樣的大型網際網路公司,但是又不知道他們如何評定技術職級。
– 阿里集團薪資職級如何劃分?讓你快速得到馬雲的青睞。
– 在百度明白這些,你將快速晉升。
– 騰訊職級裡的小祕密,這樣工作你會更強。
一場 Chat 讓你搞清 BAT 的技術評價體系,為您進入超級網際網路公司指明技術方向,時刻做好準備!如果您希望您的技術團隊也像這些網際網路巨頭一樣強大,本場 Chat 我將幫您馬上模仿建立有效的技術職級體系。

想要免費參與本場 Chat ?很簡單,「GitChat技術雜談」公眾號後臺回覆「BAT」

這裡寫圖片描述