---
GA: UA-34467841-15
---

# 強化 GitOps 可靠性實現自我修復機制 - 王偉任 (Weithenn)、郭孟坤 (Mansun Kuo)

###### tags: `HelloWorld2025` `HWDC2025` `2025` `DE 會議室` `持續整合和持續部署`

<blockquote>
在傳統 GitOps 運作架構中，「Single Source of Truth」是一切自動化的核心。然而，一旦該信任來源因人為錯誤或意外情況遭到污染，自動化流程可能無法保障一致性，甚至可能造成系統損壞的風險。

在本場議程中，將會探討並展示 GitOps with Event-Driven Ansible 的應用，由 GitOps 自動化結合事件驅動機制，當新的程式碼 Checked In 時，Event-Driven Ansible 可以檢視內容是否和制訂的原則一致，確保自動化機制能夠依照管理人員希望的方式執行，並且符合制訂的原則內容，而不再因為人為失誤造成自動化機制錯誤的執行，確保不僅降低人為疏失所帶來的錯誤風險，更提升整體運作的穩定性與可控性。

此外，議程中也將分享一個真實案例，說明如何整合 Event-Driven Ansible 與 Grafana Alerting，實現服務故障後的自我修復流程。透過即時監控與自動回應，系統得以迅速恢復至正常狀態，進一步強化地端架構的韌性與自主管理能力。

聽眾收穫：

理解如何透過事件驅動機制，降低人為錯誤導致的系統風險。

理解如何針對程式碼提交事件，進行內容驗證與原則一致性檢查，確保自動化邏輯運作無誤。

理解如何結合 Grafana Alerting 告警機制，以及 Event-Driven Ansible 事件驅動機制，打造具備故障自我修復能力的運作環境。

討論無須依賴雲端平台的自動化設計，更符合企業和組織自主掌控的需求。

透過實際案例分享，有助於與會人員快速導入至自身環境。
</blockquote>

{%hackmd @HWDC/announcement-2025 %}

## 會議資訊

**時間：** 16:45 ~ 17:30
**地點：** DE 會議室
**日期：** 2025年10月15日
**語言：** 中文
**難度：** 中階

**相關連結：**
- [Hello World Dev Conference 2025 官方網站](https://hwdc.ithome.com.tw/2025) [target=_blank]
- [Hello World 2025 議程表](https://hwdc.ithome.com.tw/2025/agenda) [target=_blank]

## 筆記區

> 請從這裡開始記錄你的筆記

### AI 與自動化的關係

* **AI 的特性：** AI 最大的特色是**隨機性**，即使輸入相同的提示詞 (prompt) 和上下文 (context)，每次輸出的結果也可能不盡相同。
* **傳統自動化的必要性：** 對於公司內部許多需要**遵循既定劇本或流程**（pipeline），不希望發生意外的工作任務，傳統自動化仍有其必要性。
* **結合應用：** 未來可以將 AI 串接進自動化流程中，讓 AI 進行思考 (AI thinking) 後，再調用自動化工具執行任務。
* **技術趨勢：** 講者引用 Gartner 報告指出，2023 年 D 位於左下角，2024 年已大幅上升，而到了 2025 年 9 月的最新報告，D 已經在高原期（沙單上）。講者個人認為，企業的**頂層自動化**仍有其存在的價值。
* **AI 的影響：** AI 帶來的焦慮確實存在。有講者親身經驗表示，原本預估需兩週用 Python 處理的任務，在 AI 輔助下，只需 10 分鐘就完成，且沒有問題。此外，矽谷的大公司在招募工程師時，會優先詢問求職者是否會使用 Copilot。

### 關鍵技術概念

#### 1. 基礎設施即程式碼 (IaC)
* IaC 的概念是使用程式碼的方式管理基礎設施 (Infra)。
* 例如，管理 100 台伺服器時，可以透過程式碼設定風扇轉速、BIOS 設定，或是控制交換器埠 (switch port) 的供電狀態。
* 講者提到，SRE (Site Reliability Engineering) 的工作任務中，至少有 50% 應該是處理自動化。

#### 2. GitOps
* 講者對 GitOps 的解釋是：**將 Git 當作唯一信任的來源 (single source of truth)** 來進行操作。
* 這意味著 Git 是所有變更的反控 (rollback) 機制和觸發 (trigger) 整個流程的起點。
* 講者建議，在 AI 應用中，不應讓 AI 碰觸 Git 的東西，將其視為最後的禁止區。

#### 3. 事件驅動自動化 (Event-Driven Automation, EDA)
* **目的：** EDA 旨在實現**主動回應**，而非傳統被動式的處理。
* **機制：** 當特定事件發生時（如伺服器記憶體連續 5 分鐘超過 70%），EDA 會被觸發，然後執行相對應的自動化腳本 (runbook)。
* **Rulebook 結構：** Rulebook 由三個元素組成：**Source**（事件來源，如日誌/metric）、**Rules**（條件判斷，如 CPU/Memory 超過 70% 持續 5 分鐘）、和 **Action**（執行什麼動作）。
* **實務提醒：** 撰寫 Rulebook 時，若要執行指令列 (command line) 動作，Action 需寫 `rongbook`；若要執行圖形化介面 (GUI) 的動作，則需寫 `rong job`。

### EDA 平台與實作 (Ansible Automation Platform, AAP)

* **監控基礎：** 系統運作的監控通常仰賴 **Logs**（日誌）、**Metrics (M)**（數值記錄，如 CPU、記憶體）和 **Traces**（記錄時間點，用於追蹤服務步驟耗時）。
* **應用場景：** 尤其適用於需要自我修復機制 (self-healing) 的多台邊緣運算設備（如 Raspberry Pi 類型的機台），以避免人工開機或維護。
* **EDA 平台組成：** EDA 是一個開源的自動化平台。Red Hat 的 EDA 屬於其自動化平台 (Automation Platform) 的一部分。
* **核心元件（以 Ansible 為例）：**
* **Project：** Rulebook 所在的邏輯群組，Rulebook 需放置在特定路徑 (extension/rulebooks 或 rulebooks) 才能被平台偵測到。
* **Environment：** 運行 Rulebook 的執行環境，通常是一個包含 Ansible runtime/Python interpreter 的容器映像檔 (container image)。
* **Credentials：** 儲存執行自動化所需的驗證資訊（如 API 密鑰、雲端憑證）。
* **Activation：** 啟動 Rulebook 執行的動作，它將 Rulebook、Credentials 和 Environment 連結起來，並等待事件觸發。
* **實作流程：** 系統監控到事件（例如 CPU 滿載狀態）後，會透過預先設定的規則觸發 Activation，讓 Rulebook 執行自動化動作（如 auto-recovery 或 remediation）。
* **整合優勢：** 透過 EDA，可以將監控資料（Metrics）與自動化流程結合，處理重複性高且結果確定的維運工作，使工作更加舒適。

## 討論區

> 歡迎在此進行討論與 Q&A

## 相關資源

- 投影片連結：
- [Event-Driven Ansible Meets Observability](https://docs.google.com/presentation/d/1LTsDbjIqdI6xn22Em3OizHMmcCCdmuYYByY8-z7Zc7c/edit?usp=sharing)
- 相關文件：(待更新)