iT邦幫忙

2025 iThome 鐵人賽

DAY 28
0

⚙️ Day 28 — 監控進化與測試覆蓋率救援行動

今天是那種「腦袋比 CPU 還忙」的一天。
系統雖然已經能監控自己、報警自己,但我覺得它還能更聰明一點。
所以今天的主軸是兩件事:監控升級測試覆蓋率救援計畫


🧠 一、監控全面升級:讓系統會思考

過去的監控只會報「API 正常 / 錯誤」。
今天我讓它開始懂得問:「我最近是不是慢了?」
透過這波更新,我加入了完整的 業務監控與效能監測系統

✅ 新增內容

  • BusinessMetrics 結構:
    包含通知發送數量、成功率、響應時間、Teams API 調用統計
  • Redis 指標儲存
    所有業務指標即時更新
  • MonitoringService
    統一管理 SystemHealth、PerformanceMetrics、BusinessHealth
  • 五大監控端點
    /api/v1/monitoring/health
    /api/v1/monitoring/performance
    /api/v1/monitoring/business
    /api/v1/monitoring/alerts
    /api/v1/monitoring/dashboard
    

系統現在不只會報錯,還會說:「我今天表現不錯 👍」。
這才是 AI 世代的監控該有的氣質。


🧩 二、修復容器與部署問題:不只是跑起來,要跑得漂亮

剛重建完鏡像,容器卻冷不防給我一句:

dial tcp [::1]:5432: connect: connection refused

😅
原來新容器用了錯的環境變數(拆分成 HOST + PORT),
但應用程式期望的是 DATABASE_URL

修復後改回這樣:

DATABASE_URL=postgresql://teamsnotify:teamsnotify123@teamsnotify-postgres:5432/notification_center?sslmode=disable
REDIS_URL=redis://teamsnotify-redis:6379

重新啟動後一切恢復正常,
監控指標出現了新的 JSON:

{
  "notifications_sent": 5,
  "notifications_failed": 1,
  "success_rate": 83.33,
  "teams_api_calls": 6
}

那一刻真的有種「活了」的感覺 🧬。


🧾 三、業務指標收集 + 日誌優化

我讓指標不只是展示數字,而是從程式碼自己更新。
notificationService.SendNotification() 中,
每發一封通知就會更新 Redis 的統計:

  • 成功 → IncrementNotificationSent()
  • 失敗 → IncrementNotificationFailed()
  • 呼叫 Teams API → IncrementTeamsAPICall()

同時我還改寫了日誌輸出格式:

  • 加入 BusinessMetricsLogger
  • 結構化日誌支援 latency、status_code、caller、duration
  • 每次請求都像一篇完整報告

現在 log 檔看起來像是財報,一目了然又有美感 📈。


🧰 四、測試覆蓋率救援行動

在完成監控系統後,我跑了個覆蓋率報告——結果心臟差點停機 💀
整體覆蓋率只有 1.2%
我立刻啟動「拯救覆蓋率計畫」。

🚀 改善階段成果

階段 覆蓋率 提升幅度 狀態
初始 1.2% -
高優先級測試 3.0% +150%
中優先級測試 6.7% +123%
改進後 7.3% +9% ⚙️ 進行中

我新增了以下測試:

  • Handlers / Repositories / Middleware → 基礎單元測試
  • Services → 全面測試 + 錯誤處理
  • Integration → Redis 整合測試
  • E2E → 外部 API 全流程測試

現在的覆蓋率雖然還不到 10%,
但測試分層架構、Mock 機制、Redis 整合都已成形。


🔍 覆蓋率低的真正原因

我仔細分析後發現主要有四點:

  1. 很多業務邏輯方法未被測試
  2. Mock 無法涵蓋真實行為
  3. 缺少資料庫與 Redis 測試環境
  4. 只有構造函數被測試(NewService...)

解方策略

  • 專注於無外部依賴模組:ConfigService、FileService
  • 改良 Mock 測試,覆蓋錯誤場景
  • 使用 Docker 啟動 Redis / DB,跑真實集成測試

目標:
短期 → 15%
中期 → 30%
長期 → 60%

一步步推上去,直到每一行代碼都被信任。


🧩 五、文檔同步率:80% → 95%

監控系統完成後,我連文檔也同步更新:

文件 進度
MonitoringGuide.md ✅ 100%
UserManual.md ✅ 95%
Architecture.md ✅ 90%
DocumentationSyncGuide.md ✅ 新增完成

同步率從 80% 提升到 95%,
我甚至寫了一支小工具 check-doc-sync.sh 幫忙檢查版本。

這下文檔不再是「寫過就忘」的東西,而是開發流程的一環。


🎯 今日成就總結

類別 成果
📊 系統監控 業務指標與效能監控全面實現
🧱 部署穩定化 容器修正 + 網路連線成功
🧩 日誌 結構化輸出 + BusinessMetricsLogger
🧪 測試 覆蓋率提升至 7.3%,測試架構完善
📘 文檔 同步率達 95%,新增檢查腳本

💬 結語:數據會說話,系統才會成長

今天的主題其實就一句話:

「沒有監控的系統,等於閉著眼睛開車。」

現在,我的系統會說話、會報警、會監控自己、還會記錄表現。
覆蓋率雖然還不高,但基礎已經穩得像鋼筋混凝土。

明天目標?
讓這座系統不只是「會監控」,
而是「會預測」。🔮


上一篇
Day 27 — 腳本重構與部署優化,讓系統更優雅地呼吸
下一篇
Day 29 — 從 E2E 全通到 Prod 準備:最後一哩路的壓力測試
系列文
Vibe Code與context engineering來打造個人專屬夥伴30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言