Lark域名告警配置

一、需求背景

FB、DB三方服务异常时，同一域名或同一出口IP可能在短时间内产生大量重复失败告警，影响运营查看其他有效信息。需要增加告警白名单及冷却时间配置，减少Lark群内的重复消息。

二、需求目标

1. 支持配置域名告警冷却时间和IP告警冷却时间。
2. 支持维护不发送Lark告警的域名白名单。
3. 告警过滤不影响原有健康检测、失败统计、动态切换和自动禁用。
4. 后台配置修改可追溯。

三、需求范围

四、功能需求

4.1 告警规则

4.2 告警白名单

4.3 操作记录

如现有后台已有统一操作日志，直接复用；否则本页面提供操作记录，记录操作时间、操作人、操作类型、操作对象及变更内容。

五、业务规则

1. 检测到动态域名异常后，系统先识别域名所属业务，再依次判断：该业务启用中的告警白名单 → 该业务域名冷却 → 该业务IP冷却。
2. 白名单判断维度为“业务类型＋域名”；域名冷却判断维度为“业务类型＋域名”；IP冷却判断维度为“业务类型＋客户端真实出口IP”。
3. FB与DB分别计算冷却时间，FB产生的域名或IP冷却不得过滤DB告警，DB同理。
4. 同一业务内，IP冷却不区分用户和域名；IP实际取值字段由后端和运维评审确认。
5. 命中任一过滤条件时不发送Lark，但异常仍参与健康检测、失败统计、动态切换和自动禁用。
6. Lark接口返回发送成功后，更新对应业务下该域名和IP的最近告警时间；被过滤或发送失败的事件不刷新冷却时间。
7. 冷却结束后再次发生异常，且未命中其他过滤条件时，允许重新发送并重新计算冷却时间。
8. 同一时刻发生并发异常时，同一业务下的同一域名或同一IP在冷却规则内只能产生一条Lark告警，具体实现方式由技术确定。
9. 告警消息沿用现有动态域名Lark告警模板、告警群及机器人配置，不新建模板。

六、异常与校验

七、验收标准

• FB、DB各自的域名冷却和IP冷却均可独立编辑，修改一方不影响另一方。
• 白名单支持自动展示业务类型，并支持按FB、DB筛选。
• 同一IP连续访问两个FB域名失败，FB仅发送第一次；同一IP先访问FB失败、再访问DB失败，FB和DB各允许发送一次。
• 同一FB或DB域名更换用户或IP后再次失败，命中对应业务的域名冷却。
• 启用白名单的域名不发送Lark，停用或删除后恢复按所属业务的冷却规则判断。
• Lark发送成功才刷新对应业务的域名和IP冷却时间，被过滤或发送失败的事件不刷新。
• 并发异常场景下，同一业务、同一维度只发送一条告警。
• 所有被过滤事件仍执行原有检测、统计、切换和自动禁用逻辑。
• 有编辑权限的账号可操作，无编辑权限的账号只读；所有配置变更可追溯。

八、评审确认项