# AWOOOI AIOps SLO/SLI 定義文件

> **文件類型**: 服務層級目標（Service Level Objectives）  
> **版本**: v1.0  
> **建立日期**: 2026-04-14（台北時間）  
> **建立者**: Claude Sonnet 4.6（首席架構師）+ 統帥確認  
> **審查週期**: 每月第一週複查，重大事件後即時更新  
> **權威性**: 本文件是 AWOOOI 系統「好不好」的唯一量尺

---

## 0. 為什麼需要 SLO？

> **沒有量尺，就不知道飛輪轉得好不好。**

在自動化系統中，以下問題沒有 SLO 就無法回答：

- 「今天的自動修復成功率算好還是算差？」
- 「上週比這週好多少？」
- 「現在該出手介入了嗎？還是讓系統自己處理？」
- 「我們的 Error Budget 還剩多少？能不能再做一次有風險的部署？」

SLO 把「系統表現好壞」從**主觀感受**變成**可量化的數字**。

---

## 1. SLI 定義（Service Level Indicators — 量什麼）

> SLI = 我們用來量測系統健康狀態的**指標**

### SLI-1：自動修復執行成功率

```
定義: 在給定時間窗口內，auto_repair 執行成功次數 / 總執行次數

計算:
  分子: ApprovalRequest.execution_success = True 的筆數
  分母: ApprovalRequest.execution_success IS NOT NULL 的筆數

查詢:
  SELECT
    COUNT(*) FILTER (WHERE execution_success = true) * 100.0 /
    COUNT(*) FILTER (WHERE execution_success IS NOT NULL)
  FROM approval_requests
  WHERE created_at >= NOW() - INTERVAL '24 hours';

單位: 百分比（%）
時間窗口: 24 小時滾動 / 7 天滾動
```

### SLI-2：告警分析延遲（從告警進入到 Telegram 卡片發出）

```
定義: webhook 接收告警 → Telegram 卡片成功發出的時間

計算:
  開始: POST /webhooks/alerts 收到請求時間戳
  結束: Telegram sendMessage API 成功回應時間戳

目前測量方式:
  - Langfuse trace duration（已整合）
  - structlog "telegram_card_sent" 與 "alertmanager_received" 的 delta

單位: 秒（s）
時間窗口: P50 / P95 / P99 百分位數
```

### SLI-3：決策引擎可用性（LLM 路徑成功率）

```
定義: LLM 分析請求中，成功返回決策的比率（含降級到 Expert System 的情況）

計算:
  分子: 有 analysis_result 且 confidence > 0 的決策數
  分母: 進入 LLM 分析路徑的告警總數

注意:
  - LLM timeout → 降級 Expert System = 計為「成功」（有決策輸出）
  - LLM 完全失敗（exception）= 計為「失敗」

單位: 百分比（%）
```

### SLI-4：KM 知識沉澱率（飛輪健康指標）

```
定義: 在執行完成的 Incident 中，成功產出 KM Entry 的比率

計算:
  分子: 有對應 KM Entry（category='execution_result' 或 'auto_repair'）的 Incident 數
  分母: status='resolved' 的 Incident 總數

單位: 百分比（%）
時間窗口: 7 天滾動
```

### SLI-5：Telegram 通知送達率

```
定義: 應發送的 Telegram 通知中，成功送達的比率

計算:
  分子: structlog "telegram_card_sent" 事件數
  分母: structlog "telegram_card_sent" + "telegram_send_failed" 事件數

單位: 百分比（%）
```

---

## 2. SLO 目標值（Service Level Objectives — 要到多好）

> SLO = 我們**承諾**系統要達到的水準

### 主要 SLO 表

| SLO ID | SLI | 及格線（Minimum） | 卓越線（Target） | 測量窗口 |
|--------|-----|-----------------|-----------------|---------|
| **SLO-1** | 自動修復執行成功率 | **≥ 70%** | ≥ 85% | 24h 滾動 |
| **SLO-2** | 告警分析延遲 P95 | **≤ 60s** | ≤ 30s | 7d 滾動 |
| **SLO-3** | 決策引擎可用性 | **≥ 95%** | ≥ 99% | 24h 滾動 |
| **SLO-4** | KM 知識沉澱率 | **≥ 60%** | ≥ 80% | 7d 滾動 |
| **SLO-5** | Telegram 通知送達率 | **≥ 98%** | ≥ 99.5% | 24h 滾動 |

### 各 SLO 設定理由

**SLO-1（自動修復成功率 ≥ 70%）**

目前系統基準：~0.5%（ADR-073 盤點發現）。
設定 70% 為及格是因為：
- K8s 操作本身有 ~10-15% 失敗率（網路短暫不通、資源不足）
- 含重試後，70% 是合理的第一個里程碑
- 卓越線 85% = 業界 AIOps 成熟系統的平均水準（Google SRE 報告）

**SLO-2（分析延遲 P95 ≤ 60s）**

- 告警→卡片 60s 以內 = 人可接受的「準即時」反應
- P95 而非 P99 = 允許偶發的 LLM 高延遲（deepseek-r1:14b 推理本身需 15-40s）
- 30s 卓越線 = Playbook RAG 命中時的典型速度

**SLO-3（決策引擎可用性 ≥ 95%）**

- 95% = 每 20 個告警允許 1 個完全失敗（Expert System 也無法決策）
- 99% 卓越線 = 幾乎零失敗，依賴 LLM 穩定性提升

**SLO-4（KM 沉澱率 ≥ 60%）**

- 當前基準：接近 0%（BP-1 修復前 KM 幾乎不寫入）
- 60% 及格線 = 允許 40% Incident 因各種原因未能沉澱（DB 失敗、無 incident_id 等）
- 80% 卓越線 = 飛輪「穩定運轉」的健康標準

**SLO-5（Telegram 送達率 ≥ 98%）**

- 通知是 AWOOOI 對外的唯一溝通渠道
- 98% = 每 50 個通知允許 1 個失敗（網路短暫中斷）
- 99.5% 卓越線 = 等同電信級別的高可用

---

## 3. Error Budget（錯誤預算）

> Error Budget = 我們「允許系統不完美」的配額

### 計算方式

```
Error Budget = 1 - SLO 目標值

以 SLO-1（自動修復成功率，卓越線 85%）為例：
  Error Budget = 1 - 0.85 = 15%

含義：在 100 次自動修復中，允許最多 15 次失敗。
當失敗次數超過 15 次，Error Budget 耗盡 → 凍結新功能部署，優先修復。
```

### Error Budget 使用規則

| 剩餘預算 | 狀態 | 允許行為 |
|---------|------|---------|
| > 50% | 🟢 充裕 | 可推高風險變更（新功能、架構調整） |
| 20-50% | 🟡 注意 | 只推低風險變更（Bug Fix、配置調整） |
| 5-20% | 🟠 警戒 | 凍結所有非緊急變更，優先修復 SLO |
| < 5% | 🔴 耗盡 | 緊急模式：所有 PR 需統帥親自批准 |

---

## 4. SLO 監控與告警

### 當前監控方式

| SLO | 資料來源 | 查看位置 |
|-----|---------|---------|
| SLO-1 | PostgreSQL `approval_requests` 表 | 日度報告（08:00 台北）|
| SLO-2 | Langfuse trace duration | Langfuse Dashboard |
| SLO-3 | structlog 決策成功/失敗計數 | SignOz Logs |
| SLO-4 | PostgreSQL incidents + knowledge_entries JOIN | 日度報告 |
| SLO-5 | structlog telegram_card_sent/failed | SignOz Logs |

### SLO 違規告警規則

```yaml
# 以下情況 → TYPE-8M「飛輪健康告警」→ 發 AwoooI SRE 戰情室群組

SLO-1 連續 2 小時 < 50%:
  告警: "⚠️ 自動修復成功率跌破 50%，飛輪瀕死"
  
SLO-2 P95 連續 15 分鐘 > 120s:
  告警: "⚠️ LLM 分析嚴重延遲，可能 OOM 或網路問題"
  
SLO-3 連續 30 分鐘 < 90%:
  告警: "🔴 決策引擎大規模失敗，立即介入"
  
SLO-5 連續 10 分鐘 < 95%:
  告警: "🔴 Telegram 送達率跌破 95%，告警鏈路中斷"
```

---

## 5. 里程碑目標（隨飛輪成熟演進）

| 時間點 | SLO-1 目標 | 備註 |
|-------|-----------|------|
| **現在（2026-04-14）** | 基準：~0.5% | ADR-073 盤點確認 |
| **Phase 1 完成（+2 週）** | ≥ 40% | KM 寫入、重試邏輯生效後 |
| **Phase 2 完成（+4 週）** | ≥ 70% | 告警聚合、規則覆蓋強化 |
| **Phase 3 完成（+6 週）** | ≥ 80% | 飛輪閉環、SSH KM 沉澱 |
| **成熟運轉（+3 個月）** | ≥ 85% | 達到業界 AIOps 平均水準 |

---

## 6. 本文件更新規則

1. **每週**: 日度報告自動收集 SLO-1、SLO-4 數值，存入趨勢記錄
2. **每月第一週**: 統帥 + 首席架構師 review SLO 達成情況，決定是否調整目標值
3. **重大 Incident 後**: 立即評估是否有 SLO 被違反，更新 Error Budget
4. **目標值調整**: 達到「卓越線」穩定 4 週後，將卓越線升為新的及格線

---

*最後更新: 2026-04-14 台北時間 | 建立者: Claude Sonnet 4.6 + 統帥*