7.7 KiB
7.7 KiB
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 違規告警規則
# 以下情況 → 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. 本文件更新規則
- 每週: 日度報告自動收集 SLO-1、SLO-4 數值，存入趨勢記錄
- 每月第一週: 統帥 + 首席架構師 review SLO 達成情況，決定是否調整目標值
- 重大 Incident 後: 立即評估是否有 SLO 被違反，更新 Error Budget
- 目標值調整: 達到「卓越線」穩定 4 週後，將卓越線升為新的及格線
最後更新: 2026-04-14 台北時間 | 建立者: Claude Sonnet 4.6 + 統帥