摘要：2022 年 7 月 25 日，雲上自動化運維 CloudOps 系列沙龍_第二彈正式開啓！阿里雲彈性計算技術專家鮑文樂帶來的主題分享是《基於事件的自動化運維最佳實踐》，以下是他的演講內容整理，本篇內容主要分為四個部分：
- 為何事件如此重要
- 讓事件通知更有效
- 事件驅動的運維架構
- 雲上託管事件運維
01 為何事件如此重要
系統事件代表了雲資源狀態的變化。以彈性計算的系統事件為例，上圖代表彈性計算的系統事件來源。
為了給用户提供雲服務器，需要底層的物理基礎設置，以及中間的虛擬化服務。在虛擬化服務上，運行 Guest OS，最終給用户提供服務。
在運維類系統事件部分，阿里雲負責運維物理基礎設施和虛擬化服務。當計算、存儲、網絡組件出現故障，阿里雲會發出運維類的系統事件。這些運維類的系統事件，要雲廠商和用户通過協作，一起運維。
在資源狀態變化類事件部分，不一定代表故障或者問題。但它是實現事件驅動架構的基礎。
如上圖所示，展示了部分典型的系統事件。
在非預期異常方面，實例宕機可能導致用户的服務中斷。如果本地盤的實例發生宕機，阿里雲無法替用户決定，是否將實例遷移，所以用户必須響應。
在計劃內運維方面，最常見的是主動運維類事件。實例因系統維護計劃重啓。當計算、存儲、網絡等底層硬件出現問題，但沒有嚴重到立刻宕機。
在這種情況下，阿里雲檢測之後，會給用户發送一個計劃類運維事件。在一定時間內，如果用户不進行響應，阿里雲會幫用户把這台機器遷移到一個健康的硬件上。
如果用户響應，可以在阿里雲給出的的操作窗口裏，選擇一個對自己最有利的，對服務影響最小的時間點。提前遷移實例，從而規避計劃重啓。
在費用方面，如果實例到期停機，系統會在實例到期前三天，發出事件。用户需要規劃自己的續費方式，比如自動續費。
在狀態通知方面，實例生命週期狀態變化代表，ECS 的實例管控狀態發生變化。比如實例創建，實例啓動，實例停機，實例釋放等。
上圖展現了雲上事件運維，常見的幾個形態。從下往上，自動化程度越來越高。阿里雲推薦用户儘量做到事件運維的自動化。
第一層，用户被動的接收通知，登錄控制枱手工處理。
第二層，用户有一定處理事件的意識，主動訂閲事件通知。
第三層，用户有一定的技術實力，建立了自己的自動化或半自動化的運維繫統，通過事件驅動的架構，按需處理各種級別的事件消息。在處理時，通過調用雲產品的 API 運維。
第四層，託管的自動化運維。用户完全把事件的運維邏輯，放到阿里雲上，由阿里雲託管運行。
02 讓事件通知更有效
接下來，講一講如何讓事件通知更精確。雲監控提供所有云產品系統事件，統一的查詢入口以及事件報警功能。
目前，已經有一百多種雲產品，將自己的事件信息發送給雲監控。包括雲服務器、雲數據庫、容器服務等。
雲監控在用户側，提供兩大類的服務：
第一類，用户可以主動查詢。通過控制枱查詢系統事件，也可以通過 Open API 查詢系統事件。
第二類，從系統往用户的事件通知。基於雲監控事件的報警規則，訂閲事件通知的功能。
雲監控的通知渠道分兩大類：
第一類，面向人工。包括電話、短信、郵件以及基於 Webhook 的工具，比如釘釘、飛書等等。
第二類，面向自動化運維程序或者運維繫統。有消息隊列、日誌服務、函數計算、URL 回調等。基於軟件庫，可以實現事件的自動化處理。
上圖是雲監控事件的通用格式。一百多種雲產品的系統事件，彙集到雲監控之後，納入統一的事件模型。
事件數據是 json 格式，外層是事件的公共屬性，比如事件唯一的 ID，事件來源等，事件級別，事件名稱，事件發生的時間、所在地域等等。
其中，content 字段代表事件的內容。它和具體某一類事件相關聯。雲產品的事件邏輯決定了，不同事件有不同的內容。
EventRule 是事件的篩選規則，按照事件的公共屬性以及事件 content 對事件進行匹配。
Rule Targets 是事件通知的目標。其中，報警通知代表人工通知，包括電話、短信、郵件、釘釘、機器人等等。消息服務隊列、函數計算、URL 回調、日誌服務等等，供程序自動化消費使用。
一旦出現符合匹配事件報警規則的事件，雲監控會把事件路由給相應的 Target。如果選擇多個 Target，每個 Target 都會收到通知。
為了讓事件通知更有效，阿里雲通過使用標籤，對資源進行分組，讓報警規則的粒度更小。然後，通過動態標籤規則，創建雲監控的應用分組。
於是雲監控的應用分組和標籤，產生了一對一的關係。用户也可以在應用管理系統，通過導入標籤，創建應用分組。應用管理會自動配置雲監控的應用分組。
然後，基於分組創建報警規則。首先，按照不同的角色，不同的職責，創建不同的聯繫人分組。接下來，按照事件的嚴重程度和接收人，劃分多個報警規則。
除此之外，用户可以利用雲監控的篩選能力，做細粒度篩選。在一個事件裏可能有實例創建，釋放，啓動、停止等多種狀態。用户可以通過關鍵詞過濾或者是 SQLFilter，精確地篩選一類事件裏的某一類狀態。
在選擇通知方式方面，用户按照事件的級別，選擇不同的通知方式。避免事件通知淪為垃圾短信和垃圾郵件，推薦釘釘羣報警。
事件規則細化之後，創建事件報警模板。把模板應用到 N 個分組上。從而實現了報警規則的批量複製，減輕維護壓力。
03 事件驅動的運維架構
基於 OpenAPI 輪詢資源狀態獲取狀態變更實時性較低，有大量冗餘請求，系統消耗高，有限流的風險，並且依賴多個雲產品 API，進一步增加了複雜性。阿里雲通過改造事件驅動架構，提高了實時性和穩定性，降低了系統消耗。
某客户原先通過輪詢雲產品的 API，獲取事件信息，存儲到運維繫統。運維團隊把事件推送到運維門户上，由各個業務系統負責響應事件。業務系統不直接上阿里雲控制枱。
由於它使用了多個雲產品，運維繫統裏有 N 段輪詢代碼，實時性也不好。
將系統改造成事件驅動架構。系統在初始化階段，在雲監控設置了事件報警規則。雲產品發佈了事件之後，雲監控檢測到事件匹配，把這個事件推送到指定客户的消息隊列裏。客户的運維繫統從消息隊列裏，拉取事件消息，存儲之後，推送給運維門户。
通過上述操作，簡化了代碼邏輯，降低了資源消耗，提高了實時性和穩定性。
在彈性伸縮方面，當實例釋放之後，ECS 管控會發佈一個實例狀態的變更事件。雲監控根據規則，路由給彈性伸縮消息隊列。然後，彈性伸縮消費事件消息獲取實例信息。彈性伸縮將實例從伸縮組移除，根據伸縮規則，進行下一步操作。
04 雲上託管事件運維
運維編排 OOS 系統，能夠自動化管理和執行運維任務。相比傳統的純手工運維或腳本運維，門檻低、規範安全、效率高、易維護、免費。
在運維編排裏，提供了事件運維功能。首先，設定事件規則，限定資源範圍。然後，選擇事件觸發之後執行的運維模板，設定模板參數。
阿里雲提供的搶佔式實例，是一個比較便宜的實例。購買搶佔式實例之後，會有一個小時的保護期。一小時後，實例隨時有可能被釋放回收。在回收前的五分鐘，搶佔式實例會發佈一個實例中斷通知。
通過 OOS 事件運維，在實例被回收之前，摘掉所有與之關聯的負載均衡，實現不影響業務的優雅下線。
在運維模板裏，一共分了五個步驟。
第一，eventTrigger。即監控搶佔式實例的釋放事件。
第二，describeSLB。即查詢釋放的搶佔實例所在負載均衡 ID。
第三，setBackendServers。即將釋放的實例在負載均衡上的權重設置為 0。
第四，waitConnectionExpire。即等待已經建立的網絡連接斷開。
第五，removeBackendServers，即將釋放的實例從負載均衡後端服務器列表上移除。
Q&A 環節，用户問答
Q1 資源編排 ROS 和 OOS 有打通的最佳實踐案例嗎？
答：打通沒有問題。ROS 將 OOS 模板和執行定義為資源，支持執行 OOS 模板。因為 OOS 通過 API 編排，所以 OOS 裏可以調用 ROS 的 API，從而創建一個資源棧。
Q2 OOS 運維編排的模板必須自己配置嗎？
答：不是。編排提供了一些常見的運維場景，可以在控制枱操作，點擊配置即可。
Q3 突發性能實例的性能受限怎麼辦?
答：服務可能受損，需要檢查突發性能實例的使用是否符合預期。可以考慮對實例升配或者更換成非突發性能實例。
