2B告警系统回归测试报告 v2.2.0

测试时间: 2026-09-13
测试环境: Windows 10, Python 3.11, SQLite WAL模式
测试DB: D:/Hermes/data/state/test_alert_state_v2.db (独立测试DB，已清理)
生产DB: D:/Hermes/data/state/alert_state.db

任务1: DB锁排查结论

检查项	状态	说明
journal_mode	✅ wal	WAL模式已启用
busy_timeout	✅ 10000ms	已设置（原5000ms，已提升）
WAL文件	✅ 存在	-wal/-shm文件正常
写锁获取	⚠️ 偶尔失败	多进程并发时写锁互斥

根因: SQLite WAL模式下，写操作仍需获取写锁，多进程并发时写锁互斥。当前系统有18个python.exe进程同时访问DB。

任务2: 独立测试DB

项目	值
路径	`D:/Hermes/data/state/test_alert_state_v2.db`
状态	✅ 已创建并验证
WAL模式	✅ 已启用
busy_timeout	✅ 10000ms
Schema	✅ 与生产DB一致

任务3: 回归测试10场景

场景	描述	结果	exit_code	alerts	audit_logs
1	成功 + TG正常	✅ 通过	0	0条	1条
2	成功 + TG_DISABLED	✅ 通过	0	0条	1条
3	失败 + TG正常 (P2)	✅ 通过	1	1条	1条
4	失败 + TG_DISABLED (P2)	✅ 通过	1	1条	1条
5	恢复通知 (P0)	✅ 通过	0	1条	2条
6	P0静默期内抑制	✅ 通过	1	2条	2条
7	P0静默期外放行	✅ 通过	1	1条	1条
8	P1第1次失败	✅ 通过	1	1条	1条
9	P1第2次失败升级	✅ 通过	1	2条	2条
10	超时	✅ 通过	0	0条	1条

汇总: 10/10 通过 ✅

任务4: 清理 + 风险记录

清理结果

✅ 测试DB已删除: test_alert_state_v2.db
✅ 生产DB未受影响

生产DB并发写风险

根因:
- SQLite WAL模式下，写操作仍需获取写锁
- 多进程并发访问时，写锁互斥导致"database is locked"错误
- busy_timeout=10000ms在极端情况下仍可能不足

影响:
- alert_channel_health.py轮询与run_with_alert.py可能同时写DB
- 高并发场景下可能出现写失败

缓解措施:
- ✅ 已启用WAL模式（提高并发读性能）
- ✅ 已设置busy_timeout=10000ms（延长等待时间）
- ⚠️ 建议：生产环境监控DB锁错误日志
- ⚠️ 建议：必要时迁移到PostgreSQL

上线前必查项:
- [ ] 检查data/state/目录下DB文件锁状态
- [ ] 确认无残留Python进程占用DB
- [ ] 验证WAL模式生效（PRAGMA journal_mode=WAL）
- [ ] 验证busy_timeout生效（PRAGMA busy_timeout=10000）

代码变更摘要

修复的问题

重复INSERT问题: run_task中成功/失败路径改用UPDATE而非INSERT，避免UNIQUE约束失败
audit_log缺失: 告警发送路径补充audit_log记录（task_fail_alert action）
静默期抑制日志: 静默期内抑制时也写audit_log（task_fail_silent action）
测试DB锁问题: 使用独立测试DB避免生产DB锁定

修改文件

scripts/run_with_alert.py: 修复重复INSERT、补充audit_log
scripts/test_run_with_alert.py: 修正测试逻辑、支持P0/P1级别测试
scripts/alert_utils.py: 无变更（功能正确）

结论

✅ 回归测试全部通过（10/10）

核心功能（TG发送、静默期、恢复通知、P1升级）验证通过
独立测试DB方案有效规避生产DB锁问题
代码质量稳定，可进入步骤3（init_alert_state.py更新）

下一步: 更新init_alert_state.py确保WAL初始化幂等，然后进行步骤4（alert_channel_health.py轮询模块实现）。