docs: 告警機制優化計畫 + ADR-030 Phase 6 + Skill 03 v1.5

- LOGBOOK: 新增告警機制完整審查記錄 - ADR-030: 新增 Phase 6 非同步分析優化章節 - Skill 03: v1.5 Stream Key 統一 + Telegram 去重 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-03-27 09:42:53 +08:00
parent 79b526b472
commit 4ee5376bd1
3 changed files with 208 additions and 12 deletions
--- a/.agents/skills/03-openclaw-cognitive-expert.md
+++ b/.agents/skills/03-openclaw-cognitive-expert.md
@@ -10,10 +10,10 @@

 | 欄位 | 值 |
 |------|-----|
-| **版本** | v1.4 |
+| **版本** | v1.5 |
 | **建立日期** | 2026-03-20 (台北) |
 | **建立者** | Claude Code |
-| **最後修改** | 2026-03-26 11:10 (台北) |
+| **最後修改** | 2026-03-27 09:45 (台北) |
 | **修改者** | Claude Code (首席架構師) |

 ### 變更紀錄
@@ -25,6 +25,7 @@
 | v1.2 | 2026-03-25 | Claude Code | 智能路由引擎 + Tool/Modular 關係 |
 | v1.3 | 2026-03-25 | Claude Code | 加入文件資訊區塊 |
 | v1.4 | 2026-03-26 | Claude Code | K8s 資源名稱驗證 (ADR-016) |
+| v1.5 | 2026-03-27 | Claude Code | Stream Key 統一 + 告警去重機制 |

 ---

@@ -46,11 +47,18 @@ Table: incident_records

 ### 3. Event Bus (Redis Streams)
 ```
-Stream: stream:awoooi_signals
+Stream: awoooi:signals  # 2026-03-27 統一格式
 Group: awoooi_workers
 用途: 告警信號傳遞
 ```

+### 4. Telegram 去重 (2026-03-27 新增)
+```
+Key: telegram_sent:{incident_id}
+TTL: 600 秒 (10 分鐘)
+用途: 防止相同 Incident 重複發送 Telegram
+```
+
 ---

 ## 核心約束 (Cognitive Iron Laws)
--- a/docs/LOGBOOK.md
+++ b/docs/LOGBOOK.md
@@ -5,18 +5,114 @@

 ---

-## 📍 當前狀態 (2026-03-26 20:05 台北)
+## 📍 當前狀態 (2026-03-27 09:40 台北)

 | 項目 | 狀態 |
 |------|------|
-| **當前 Phase** | **Phase 17.1 Incident-Approval 同步** |
+| **當前 Phase** | **告警機制優化計畫制定中** |
 | **Day** | Day 10 |
-| **AI Fallback** | ✅ **Ollama 優先 (已切回，Gemini 404 問題)** |
-| **ADR-027** | ✅ **批准** (Incident-Approval 同步架構) |
-| **ADR-026** | ✅ **批准** (CoreDNS GitOps) |
-| **Telegram 告警** | ✅ **修復完成** (INC-INC- bug + 去重機制) |
-| **架構審查** | ✅ **完成** (5 個關鍵問題識別) |
-| **K8s 部署** | ✅ **CD 自動處理 selector 不可變問題** |
+| **AI Fallback** | ✅ **Ollama → Gemini → Claude** (已切回) |
+| **LLM 模型** | `llama3.2:3b` (CPU 約 2-3 分鐘) |
+| **ADR-030** | ✅✅✅ **已實作 + 審查通過** (4/5⭐) |
+| **P0 Stream Key** | ✅ **已統一** `awoooi:signals` |
+| **Telegram 去重** | ✅ **10 分鐘 TTL** |
+| **INC- 前綴** | ✅ **已修復** |
+
+---
+
+### 🚨 2026-03-27 告警機制完整審查 (Day 10 上午 09:00)
+
+**首席架構師審查結果**: ⭐⭐⭐⭐ (4/5)
+
+#### 已修復 (本日)
+
+| 問題 | Commit | 狀態 |
+|------|--------|------|
+| P0 Stream Key 不一致 | `79b526b` | ✅ |
+| Telegram 去重 | `e34b0f2` | ✅ |
+| INC-INC-INC- 前綴 | `e34b0f2` | ✅ |
+| LLM 超時 120/180s | `d1409fc` | ✅ |
+| 舊 Stream 積壓清理 | - | ✅ |
+
+#### 優化計畫 (11 項)
+
+| 優先級 | 項目數 | 本週必做 |
+|--------|--------|----------|
+| P1 | 2 | playbook_rag 模組化 |
+| P2 | 4 | 處理中狀態、優先級排序 |
+| P3 | 4 | GPU LLM、統計儀表板 |
+| 取消 | 1 | UTC 時區 (違反鐵律) |
+
+**Memory 更新**: `project_alert_optimization_plan.md`
+
+---
+
+### ✅ 2026-03-27 ADR-030 測試驗證完成 (Day 10 深夜 00:00)
+
+| 測試項目 | 結果 |
+|----------|------|
+| 舊測試修復 (`IncidentStatus.OPEN→INVESTIGATING`) | ✅ |
+| `test_adr030_auto_approve.py` | ✅ 19 passed |
+| `test_adr030_learning_service.py` | ✅ 19 passed |
+| `test_auto_repair_service.py` | ✅ 11 passed |
+| **總計** | **49 passed** |
+
+**新增測試檔案**:
+- `tests/test_adr030_auto_approve.py` - 自動執行策略測試
+- `tests/test_adr030_learning_service.py` - 持續學習服務測試
+
+---
+
+### 🔍 2026-03-26 首席架構師審查 ADR-030 (Day 10 晚間 23:30)
+
+**審查結果**: ⭐⭐⭐⭐ (4/5) - **批准上線**
+
+| 項目 | 結果 |
+|------|------|
+| 架構設計 | ✅ 通過 |
+| 代碼品質 | ✅ 通過 |
+| 安全性 | ✅ 通過 |
+| 模組化規範 | ⚠️ P1 違規待修 |
+
+**P1 違規** (本週內修復):
+- `playbook_rag.py:29` - Service 直接存取 Redis
+- `playbook_rag.py:156` - 自建 httpx.AsyncClient
+
+**已更新文檔**:
+- `MEMORY.md` - 新增 project_adr030_architecture_review.md
+- `ADR-030` - 狀態: 提案中 → 已實作 ✅
+- `Skill 02` - v1.6 → v1.7 (新增 ADR-030 章節)
+
+---
+
+### ✅✅✅ 2026-03-26 ADR-030 全部完成 (Day 10 晚間 21:00-23:00)
+
+**Phase 1** - Expert System 重構 (診斷優先) ✅
+**Phase 2** - K8s/SignOz 診斷資料收集 ✅
+**Phase 3** - Playbook RAG 向量搜尋 ✅
+**Phase 4** - 自動執行策略 ✅
+**Phase 5** - 持續學習迴圈 ✅
+
+| Phase | 檔案 | 功能 |
+|-------|------|------|
+| 2 | `k8s_diagnostics.py` | K8s 診斷收集 |
+| 2 | `diagnosis_aggregator.py` | 多源診斷整合 |
+| 3 | `playbook_rag.py` | Ollama 向量搜尋 |
+| 4 | `auto_approve.py` | 自動執行策略 |
+| 5 | `learning_service.py` | 持續學習迴圈 |
+
+**完整架構**:
+```
+Incident → Expert 分類 → K8s/SignOz 診斷 → Playbook RAG 匹配
+    │
+    ├─ AutoApprovePolicy 判斷
+    │   ├─ 可自動執行 → 直接執行 → LearningService 學習
+    │   └─ 需人工審核 → Telegram 通知
+    │
+    └─ 執行完成 → 信任度調整 + Playbook 統計更新
+```
+
+**Commits**: `60e9538` → `3c03452` → `ce7f8a1` → `3256142`

 ### 🔴🔴 2026-03-26 Telegram 告警轟炸緊急修復 (Day 10 晚間 19:30-20:00)

--- a/docs/adr/ADR-030-intelligent-auto-remediation.md
+++ b/docs/adr/ADR-030-intelligent-auto-remediation.md
@@ -1,6 +1,6 @@
 # ADR-030: 智能自動修復系統 (Intelligent Auto-Remediation)

-**狀態**: 提案中
+**狀態**: 已實作 ✅
 **日期**: 2026-03-27 (台北時區)
 **決策者**: 統帥
 **觸發**: Expert System 只會重啟，缺乏根因診斷能力
@@ -821,6 +821,98 @@ Phase 5: 持續學習     [░░░░░░░░░░] 0%   (2-3 週)

 ---

+## 7.1 Phase 6: 非同步分析優化 (2026-03-27 新增)
+
+> **觸發**: LLM 分析 (llama3.2:3b CPU) 需 2-3 分鐘，導致告警回應延遲
+
+### 問題分析
+
+| 現狀 | 影響 | 根因 |
+|------|------|------|
+| LLM 同步等待 2-3 分鐘 | 告警回應延遲 | Ollama 純 CPU 模式 |
+| 超時後 Fallback Expert System | 用戶只看到 75% 信心度 | 超時設定不合理 |
+| 等待期間 API 阻塞 | 批量告警處理緩慢 | 非非同步設計 |
+
+### 解決方案
+
+```
+優化前:
+  告警 → 等 LLM (2-3分鐘) → 發 Telegram
+         ↑_____________↑
+           阻塞等待
+
+優化後:
+  告警 → Expert System 立即發 (75%) → Telegram
+           ↓
+         背景 LLM 分析 (2-3分鐘)
+           ↓
+         edit_message 更新 Telegram (90%+)
+```
+
+### 實作細節
+
+```python
+# decision_manager.py 修改
+
+async def get_or_create_decision(
+    incident: Incident,
+    timeout_sec: float = 180.0,  # 已修改
+) -> DecisionToken:
+    # Phase 6 優化: 非同步雙軌
+
+    # Step 1: Expert System 立即返回
+    expert_result = await self._expert_analyze(incident)
+    await _push_decision_to_telegram(incident, expert_result)
+
+    # Step 2: 背景啟動 LLM 分析
+    asyncio.create_task(
+        self._background_llm_analyze(incident, token)
+    )
+
+    return token
+
+async def _background_llm_analyze(
+    self,
+    incident: Incident,
+    token: DecisionToken,
+) -> None:
+    """背景 LLM 分析，完成後更新 Telegram"""
+    try:
+        llm_result = await self._llm_analyze(incident)
+
+        # 更新 Token
+        token.proposal_data = llm_result
+        await self._save_token(token)
+
+        # 更新 Telegram 訊息
+        await self._update_telegram_message(incident, llm_result)
+    except Exception as e:
+        logger.warning("background_llm_failed", error=str(e))
+```
+
+### 驗收標準
+
+- [ ] Expert System 告警回應 < 5 秒
+- [ ] LLM 結果 2-3 分鐘後更新 Telegram
+- [ ] 更新使用 `edit_message` 而非新發訊息
+- [ ] 錯誤處理：LLM 失敗不影響已發送的 Expert 結果
+
+### 依賴
+
+- 需修改 `decision_manager.py` (Tier 3 紅區)
+- 需擴展 `telegram_gateway.py` 支援 `edit_message`
+- 需首席架構師簽核
+
+### 狀態
+
+| 項目 | 狀態 |
+|------|------|
+| 設計文件 | ✅ 完成 (本章節) |
+| 首席架構師審查 | 🔴 待審 |
+| 實作 | 🔴 待開始 |
+
+---
+
 ## 八、結論

 本方案提供了一個**完整的智能自動修復系統**，從「盲目重啟」進化到「根因診斷 + 智能決策 + 持續學習」。