241 lines
7.7 KiB
Markdown
241 lines
7.7 KiB
Markdown
# 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 + 統帥*
|