3. 事件触发值班机器人架构：事件源、决策引擎、通知渠道

事件触发值班机器人的核心架构围绕“感知-决策-执行”闭环设计，由三个逻辑层组成：事件源负责接收外部信号，决策引擎负责判断谁该处理、如何处理，通知渠道负责将决策结果送达目标人。三层之间通过标准化事件总线解耦，便于接入 OpenTelemetry 进行全链路诊断。

3.1 整体架构分层

下图展示了值班机器人的三层架构及典型组件，箭头表示事件流转方向。

3.2 事件源层详解

事件源是值班机器人的“输入边界”。不同事件源具有不同的触发特征和负载模式，决策引擎需要根据这些特征做差异化处理。

3.3 决策引擎层

决策引擎是值班机器人的“大脑”，负责将原始事件转化为“谁、用什么方式、在什么时间内处理”的指令。核心子模块包括：

• 事件去重与聚合：相同告警在短时间内重复到达时，只触发一次通知，避免轰炸。通常使用滑动窗口 + 事件指纹（如 MD5 摘要）实现。
• 值班表匹配：根据事件的时间戳、业务标签、优先级，查询当前值班人员列表。支持主备、轮岗、自定义排班规则。
• 升级策略：如果第一责任人未确认，按时间阶梯升级到第二人、值班经理、SRE 负责人。升级间隔可配置（如 5 分钟、15 分钟、30 分钟）。
• 限流与降级：当事件速率超过阈值时，自动丢弃低优先级事件或合并通知，保护下游通知渠道不被冲垮。

3.4 通知渠道层

通知渠道负责将决策结果投递给目标人。不同渠道的可靠性、延迟、成本差异显著，通常采用“多渠道并行”或“主备切换”策略。

3.5 事件流转与可观测埋点

为了在 OpenTelemetry 中实现端到端诊断，需要在三层之间传递统一的 Trace Context。下图展示了事件从产生到通知完成的关键埋点位置。

3.6 架构设计原则

1. 无状态化：决策引擎不持有值班表状态，通过外部缓存（Redis）或配置中心获取，便于水平扩展。
2. 幂等性：相同事件重复投递时，通知结果一致。决策引擎通过事件 ID 去重，通知渠道通过消息 ID 去重。
3. 可观测性优先：每一层都输出 Metrics（事件速率、处理延迟、成功率）和 Traces（完整调用链），避免“黑盒”运维。
4. 优雅降级：当通知渠道不可用时，事件应进入死信队列（DLQ）并触发告警，而不是直接丢弃。