基於事件驅動的自動化運維平臺

作者：李森

部門：技術中臺 / PaaS 平臺

一、前言

隨着公司規模的增長，業務越來越複雜，運維的場景越來越多，對運維自動化的要求也越來越高。事物的發展不是孤立的，運維也不例外，運維的發展過程大致可以分爲：手動運維 -> 自動運維 -> DevOps -> 智能運維。我們希望在已有的 OPS 運維平臺的基礎上再向前邁進一步，構建基於事件驅動的自動化運維平臺。

發展圖： 

本文將介紹基於事件驅動的自動化運維平臺（Whale）的系統設計、實踐以及未來的展望。

二、整體設計

系統運行分爲兩大階段：編排期和運行時

編排期：

運行時：

系統流程： 

2.1 事件中心

事件中心作爲整個平臺事件的入口，主要的職責是：

使用預定義的事件類型，可以標準化事件，更好從全局視角瞭解事件接入情況。ES 的使用讓事件中心的存儲和索引更加強大，便於用戶可能需要的問題排查以及事件重現。

2.2 規則匹配

規則匹配模塊是事件驅動的大腦，是事件到任務的決策單元。整體分爲 3 個模塊：規則特徵匹配、任務參數組裝、任務觸發限流。

2.2.1 規則特徵匹配

規則特徵匹配是通過對事件本身內容進行匹配，對用戶使用 DSL 配置的匹配規則予以放行，反之會被丟棄。目前特徵支持常用關係如：等於、不等於、大於、小於、正則匹配等。用戶配置的特徵組成一個特徵管道，事件需要經過特徵管道來判斷匹配結果。比如：我們想根據某個事件的某個指標的大小來決定是否觸發任務，這個閾值的設置，可以增加一個特徵規則；或者我們的任務只針對生產環境的資源，可以增加一個環境特徵規則。 

2.2.2 參數組裝

爲了讓事件內容與任務解耦，所以抽象了參數組裝層。讓事件和任務都具有流動性，同時一個事件也可以觸發多個任務。任務參數組裝需要用戶使用 DSL 來配置一個任務參數模板，系統會根據事件內容以及參數模板渲染出執行這個任務所需要的全部參數。

例如事件消息爲：
{
  "event_type": "opsst2_stone",
  "detail": "{"msg": ["test1", "test2", "test3"], "code": "1"}"
}
則轉發參數可以爲：
{
  "messages": "{{.detail.msg}}}",  #指定引用事件detail字段的msg字段
  "default1": "ok",  #指定固定的默認值
  "default2": [1,2,3]
}

2.2.3 任務限流

事件具有重複性，但是任務理論上不應該被重複創建。爲了避免這種情況，對下游的任務執行引擎進行保護，此模塊實現了一個基於緩存的令牌桶限流器。每個規則都可以配置一個限流策略：

限流標識 key 同樣需要 DSL 來創建模板，根據事件內容渲染出真正的 key 。如：

{{.detail.app}}_{{.detail.host}}

2.3 執行引擎

執行引擎作是一個 “真正幹活” 的模塊。根據已有的一些運維繫統的痛點，我們需要的是一個有狀態的、可編程的、支持 Workflow 、帶容錯、可擴展的分佈式任務編排框架。目前有很多成熟的開源任務編排框架，對比了一些開源軟件後我們選擇了 StackStorm 。基於 StackStorm 提供任務編排 DSL ，用戶可以通過編寫 Yaml 輕鬆對原子任務進行組合，像搭積木一樣完成數據自己的任務流。

在此基礎上，爲了更好管理多個集羣（根據業務的優先級隔離出單獨集羣），滿足跨機房高可用、用戶無感知升級等需求，我們實現了一個多集羣的 Proxy 做流量隔離控制。

2.3.1 任務管理

任務管理模塊可以對任務執行狀態進行管理

2.3.2 集羣變更發佈

爲了應對原子任務日常迭代發佈，我們抽象出共享 Pack 的概念（若干個 Pack 組合體，Pack 的體現形式類似一個 Git Repo），發佈過程中會把這若干個 Pack 構建成一個 Docker 鏡像，替換老的 Worker 節點的鏡像。

2.3.3 多集羣管理

我們對底層的 StackStorm 集羣進行了屏蔽，用戶不需要感知我們下層集羣的情況。有了這一層的存在，後續可以很方便對集羣的滾動升級、維護、甚至替換其他開源方案。 

不僅如此，這裏我們還可以在用戶無感知的情況下對不同的業務路由不同的集羣，實現業務層面的集羣級別的隔離。

三、實踐

利用事件驅動的自動化運維平臺，與監控同學合作實現兩個小場景的告警自動處理：

處理流程： 

集成企業微信： 

四、後續展望

  1. 目前的場景的自動執行還需要人爲在企業微信授權，後續基於數據的分析場景成熟可以不需授權直接處理，只需要同步處理結果即可。

  2. 嘗試更多場景，如將告警事件和預案結合打造故障自愈產品，通過打通企業微信和 OPS 平臺，讓開發同學享受 ChatOps 的快樂。

  3. 目前用戶構建 Workflow 和編寫任務只能通過編寫代碼提交到倉庫，後續會提供更成熟的產品，讓用戶可以在界面編寫腳本和拖拽就完成自己的 Workflow 。

  4. 平臺更多數據的沉澱，通過數據來分析出規則，更遠期的設想通過將人工智能的能力與運維能力點結合，讓運維更智能。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/GAjF_-Pkip377TSHkw8AYA

猜你喜歡