1. 值班机器人概述
1.1 值班机器人定义
值班机器人（On-Call Robot）是一种自动化运维实体，它通过监听监控系统、日志平台、告警网关等数据源，在检测到异常事件时自动执行预定义的响应动作，并在必要时通过即时通讯工具（如钉钉、飞书、Slack）通知值班人员。其核心目标是将“人找事”转变为“事找人”，缩短故障发现与响应时间。
关键特征： 事件驱动、自动化响应、人机协同、可观测性数据闭环。
1.2 核心功能
值班机器人通常包含以下六大核心功能模块：
| 功能模块 | 说明 | 典型输出 |
|---|---|---|
| 事件接入 | 接收来自 Prometheus、ELK、Sentry、自定义 Webhook 等来源的告警或事件 | 标准化事件对象 |
| 事件路由 | 根据事件等级、服务归属、值班日历将事件分发给对应处理人 | 值班人 @消息 |
| 自动化诊断 | 触发预置脚本或工具链（如日志查询、链路追踪、指标分析）进行根因定位 | 诊断报告摘要 |
| 动作执行 | 执行重启、扩缩容、回滚、屏蔽等运维操作 | 操作结果状态 |
| 通知与升级 | 通过多渠道通知，并在超时未响应时升级到更高层级 | 通知记录、升级链路 |
| 事件闭环 | 记录事件处理全链路，生成事后复盘报告 | 事件时间线、Action Log |
1.3 常见架构模式
根据团队规模和系统复杂度，值班机器人通常采用以下三种架构模式之一：
- 单体模式： 所有功能集成在一个进程中，适合小团队或初期验证阶段，部署简单但扩展性差。
- 事件驱动微服务模式： 将事件接入、路由、诊断、执行拆分为独立服务，通过消息队列（如 Kafka、RabbitMQ）解耦，适合中大型团队。
- Serverless 模式： 使用云函数（如 AWS Lambda、阿里云函数计算）实现无状态的事件处理，按需付费，适合事件量波动大的场景。
下图展示了一种典型的事件驱动微服务架构：
1.4 可观测性挑战
值班机器人在实际落地中面临以下可观测性挑战：
- 事件风暴与告警疲劳： 大量重复或关联告警导致机器人处理队列积压，关键事件被淹没。
- 诊断链路断裂： 机器人触发诊断时，若目标服务未接入 OpenTelemetry，则无法获取完整 Trace，导致根因定位失败。
- 动作执行黑盒： 机器人执行重启、扩缩容等操作后，缺乏对操作效果的实时观测反馈，无法判断操作是否生效。
- 通知风暴与升级混乱： 多级通知策略配置不当，导致同一事件重复通知多人，或升级逻辑未触发。
- 数据孤岛： 指标、日志、链路数据分散在不同平台，机器人难以关联分析。
注意： 上述挑战中，“诊断链路断裂”是值班机器人最常见的失效模式。本课程后续章节将重点讲解如何通过 OpenTelemetry 注入和 Trace 上下文传播来修复这一断裂。
下图总结了值班机器人可观测性挑战的分布与影响：