传统的 on-call 响应模式长期存在一个核心矛盾：工程师需要在极短时间内从大量分散的日志、指标、追踪和事件数据中定位问题根因，但这一过程往往依赖个人经验与手动翻阅文档，效率低下且容易出错。Relvy 作为 Y Combinator 2024 年冬季批次（YC F24）孵化的初创公司，提出了一种全新的解决思路：将团队积累的故障响应知识编码为结构化 Runbook，结合 AI 代理实现自动化调查与修复执行。本文将从技术架构、关键特性、集成生态与工程落地参数四个维度，系统解析 Relvy 如何重新定义 on-call 响应流程。

从手动查档到声明式故障剧本的范式转移

Relvy 的核心价值主张在于将传统的 “人在看到告警后手动查档” 模式转变为 “系统自动读取 Runbook、规划调试策略并执行修复步骤”。这一转变的底层逻辑是将团队的隐性经验显性化为可执行的声明式故障剧本（Declarative Runbook），而非依赖脚本化的手动操作。

在具体实现上，Relvy 将 Runbook 设计为动态指令集。当系统接收到告警后，其内置的 Planner 组件会首先解析 Runbook 内容，规划出调试策略，随后将任务分发给专门的数据源代理（Data-Source Agents），包括日志代理（Log Agent）、指标代理（Metrics Agent）、事件代理（Events Agent）和追踪代理（Traces Agent）。这些代理并行或顺序执行相应步骤，支持条件分支与自动重试机制，最终聚合所有发现并生成根因分析报告。

这种架构的优势在于：它不仅能够执行预设的线性步骤，还能根据实际调查发现的中间结果动态调整后续行动计划。例如，当日志代理发现某个特定的错误模式时，追踪代理可以针对性地检查相关的调用链，而指标代理则可以比对历史基线数据。这种自适应的调查策略是传统静态 Runbook 难以实现的。

自动化调查与根因分析的技术实现

Relvy 的自动化调查能力建立在对多源异构数据的统一访问层之上。系统提供对主流可观测性平台的原生集成支持，包括 AWS CloudWatch、Datadog、New Relic、ElasticSearch、OpenSearch、Grafana、Prometheus、Observe Inc、PagerDuty、Sentry、Splunk 等。这意味着 Relvy 可以跨平台聚合日志、指标、事件和追踪数据，无需工程师手动在多个系统之间切换。

在具体调查流程上，Relvy 采用了一种 Planner + Specialized Agents 的协作模式。当一个典型的 API 延迟告警触发时，系统的处理流程如下：Planner 首先读取 API 相关的指标数据，对比基线判断延迟严重程度；随后调度 DB 和缓存饱和度检查代理，评估下游依赖的资源状态；接着调用追踪代理识别慢请求的具体调用栈；最后聚合日志代理在事故时间窗口内发现的错误信息。所有发现汇总后，系统生成带有置信度的根因推测，并附带推荐的修复动作。

这种自动化调查模式的工程价值体现在三个层面。其一是缩短 MTTR（Mean Time To Recovery），因为并行数据采集和自动化推理显著减少了人工排查时间。其二是标准化调查过程，确保不同工程师、不同班次处理同一类型事故时遵循一致的诊断路径。其三是知识传承，新加入团队的工程师可以通过阅读 Relvy 执行的自动化 Runbook 快速理解事故处理流程，降低学习曲线。

与协作工具的深度集成

Relvy 深刻理解现代软件团队的实际工作场景，因此在集成设计上重点关注与协作工具的衔接。系统支持通过 Slack 进行告警响应和后续问答，这意味着 on-call 工程师可以在熟悉的协作频道中接收告警、查看 Relvy 的调查结果、给出修复指令，甚至直接触发 mitigation 步骤。

具体而言，Relvy 在 Slack 中的交互模式包括：告警推送（当监控系统检测到异常时自动发送消息到指定频道）、调查进展更新（Relvy 在执行 Runbook 过程中实时推送关键发现）、问答交互（工程师可以向 Relvy 追问特定问题，系统基于已有数据给出回复）以及修复确认（对于需要人工批准的修复操作，系统提供一键确认入口）。

此外，Relvy 还支持与 GitHub 和 Confluence 的集成，前者用于触发基于 GitHub Actions 或 AWS CLI 的自动化修复操作，后者用于同步团队的知识库文档。这种端到端的集成设计使得 Relvy 不仅仅是一个调查工具，而是一个覆盖从检测到修复全流程的自动化平台。

工程落地参数与选型考量

对于考虑引入 Relvy 的团队，以下几个工程参数值得重点评估。

在 Runbook 编写与版本管理方面，Relvy 提供专用的 Runbook 编辑器，团队需要将现有的运维手册、事故复盘报告转化为 AI 可执行的指令结构。建议采用 “渐进式迁移” 策略：先从高频、低风险的事故类型开始编写自动化 Runbook，验证效果后再逐步覆盖复杂场景。Runbook 应包含明确的输入参数（如阈值、目标服务名）、执行条件（什么情况下跳过某些步骤）和输出期望（每步执行后应验证什么）。

在集成兼容性方面，需要确认 Relvy 已支持团队现有的可观测性技术栈。从文档来看，Relvy 覆盖了主流的开源和商业方案，但若团队使用小众或自研的监控平台，可能需要通过 Custom API 方式接入。建议在选型前使用 Relvy 提供的演示环境实际测试与现有工具的数据连通性。

在安全与合规方面，Relvy 已获得 SOC 2 认证，这对于企业级客户是重要的信任基础。但团队仍需关注数据访问权限的精细控制：Relvy 的代理需要读取生产环境的日志和指标，确保这些代理仅被授权访问必要的敏感数据，并开启审计日志记录所有自动化操作。

在信任与守护机制方面，由于 AI 驱动的自动化 Runbook 可能产生非确定性输出，团队应为关键修复操作设置人工审批门槛。例如，涉及数据修改、配置变更或服务重启的操作应默认要求 on-call 工程师确认后执行，而非自动执行。同时应建立回滚预案，确保自动化修复引入新问题时能够快速恢复。

Relvy 所代表的 AI + Runbook 自动化方向，反映了可观测性领域的一个重要趋势：从 “工具辅助人” 向 “人监督机器执行” 的范式转变。这一转变并非要取代工程师的判断，而是通过自动化执行标准化流程来释放工程师的认知资源，使其能够专注于更高层次的架构优化与复杂问题决策。

参考资料