攜程運維工作流平台的演進之路

前言

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

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

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

• 面臨的挑戰
• 運維工作流平台的建設
• 收穫總結
• 下一代流程平台的設計
• 未來展望

一、面臨的挑戰

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

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

第一階段：摸索期

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

第二階段：成熟期

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

第三階段：革新升級期

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

那麼在沒有流程平台之前，我們到底面臨著怎麼樣的挑戰呢？

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

二、工作流平台的建設

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

1、系統架構

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

從下往上看主要有三層：

• 底層工作流引擎

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

• 中間介面網關層

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

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

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

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

可以通過平台對提供服務進行許可權控制，可以查看提供的服務由哪些外部用戶或者工具調用，同時申請了哪些外部工具的服務，可以對申請進行授權

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

可以通過可視化的前端頁面查看當前提供的服務的質量，比如服務的響應時間

第四， 訪問日誌

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

第五， 產品局限

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

• 上層外部工具服務

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

2、標準服務網關 – OSG

OSG是介面網關的核心的組件之一，那麼什麼是OSG呢？

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

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

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

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

ENP – Event Notification Platform（事件通知平台），這裡大家可能會有這樣的疑問，這個不就是消息隊列嗎？可以這麼說，事件通知平台設計參考消息隊列，但實現上又稍有些不同，之所以會有這個平台，是因為從Remedy產生的消息數據在處理上有些局限，所有的數據的格式化處理都需要交給ENP，由ENP根據設置規則進行封裝處理後再轉發給外部工具。

為什麼需要這麼一個平台呢？

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

舉個場景：

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

我希望：

• 及時通知我
• 及時通知服務提供人
• 能看到異常發生頻率、次數、時間
• 能看到異常的內容
• 能看到所有通知事件

那麼平台是如何運作一個消息從產生到工具的傳遞呢？

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

2. 工具訪問之前需要在平台上搜索該事件到並且訂閱，需要提供一些必要的信息，比如工具服務的調用地址

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

4. ENP轉發消息到外部工具

5. 工具回寫消息到ENP，ENP最終回寫到流程平台

4、流程場景：伺服器上線

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

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

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

5、可視化的流程運行實例

在有了流程之後，對於不同角色的用戶，比如運維人員、開發人員、流程組以及管理人員，需要有個可視化的界面：

• 能清晰直觀的看到所有運行的流程運行
• 能清楚了解當前某個流程運行或者等待在哪一個環節
• 流程的運行狀態、時效

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

通過打開單條實例數據，可以進一度查看實例詳情，在此可進一步看到所有運行或者已經完成的任務以及它們的處理時間，一旦任務處理異常掛起時，可以通過查看任務的責任團隊迅速找到相關責任人進行快速處理。

三、收穫總結

1、10X服務交付能力的提升

2014年當時還沒伺服器上線流程時，業務部門從提出需求到最後交付平均需要一周左右的時間，最長可能會達到二周，所有上線的相關環節的協同操作幾乎都由低效率的人工完成，很少有工具參與自動化處理。

有一個場景讓我至今映像深刻，當時整個網站運營中心的各個運維團隊座位比較近，所有每當有上線的時候，經常會聽到不同團隊之間隔空對話方式進行溝通，還停留在通信基本靠吼的原始時代。

現在有了流程支持，這種低效率的團隊合作方式也大大得到了改善，各個運維團隊開始嘗試開發自己的工具並接入到流程，流程也慢慢的從部份工具的接入的半自動化到所有工具接入的全自動化處理模式運行，在流程完全自動化後，最終上線效率得到了大大的提升。

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

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

第一，服務標準化， 前面我們已經講到了關於服務標準化，就是把現有的平台進一步分層，建立標準介面，像OSG這種的標準化介面網關;

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

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

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

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

1、改進後的系統架構

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

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

1）適配器

主要負責不同流程引擎之間的數據映射交互

2）基於BPMN標準的模塊，包括倉庫、運行時、歷史、身份

倉庫（Repository）主要存儲流程的定義以及部署信息，所有流程執行過程中產生的實例、任務實例以及變數實例的數據會存儲在歷史（History）模塊中，運行時（Runtime）模塊主要負責所有正在運行中的用戶任務，執行實例以及定時作業等，最後身份（ID）模塊是用於存儲用戶、組以及他們之間的關係

3）介面網關

主要負責與原來的介面層進行數據之間的交互，並實現與外部工具服務的通信

前端由自研的Mario運維工作流平台做為核心數據的可視化集中展現，監控報表等等。

2、可視化

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

3、監控告警-EITS

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

4、支持複雜流程

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

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

2) 分支一由排他性的網關處理，根據中間產生的不同數據進行條件判斷，如果滿足條件則執行任務a2，若不滿足，則執行a3，排他性網關只會有一個任務被執行

3) 分支二由包含性的網關處理，任務a4 如果滿足條件則被執行，a5始終會被執行

4) 分支三隻不包括任務網關，任務a6會與分支一、二並行處理

5) 待所有分支處理完成後，流程合併

6) 繼續處理串列任務a7

五、未來的展望

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

? 智能化

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

? 自助式的流程編排

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

【作者簡介】徐豪傑，攜程旅行網技術保障中心流程工具團隊資深軟體工程師，於2013年加入攜程，主要負責攜程工作流平台架構設計與建設，在流程建設方面有著比較豐富的積累與經驗。

沒看夠？更多攜程技術人一手乾貨，歡迎搜索關注「攜程技術中心」微信公號~