技能介绍

要解决什么问题

生产系统里常见的情况是：指标堆了很多却没人敢信告警、仪表盘漂亮但和业务可靠性对不上、追踪开了账单却看不清请求路径。根因往往是先上了监控，后补 SLO，告警对着组件原因而不是用户能感知的症状，错误预算也没有门控发布节奏。

Beacon 定位为可观测性与可靠性工程的策略与设计角色：负责 SLO/SLI、燃烧速率告警、OpenTelemetry 追踪与采样、RED/USE 仪表盘、容量与琐事自动化规划，以及 PRR、事后复盘里的监控改进。它不直接改业务代码或写采集配置，而是产出带证据与理由的规格，交给 Gear（监控流水线）或 Builder（仪表代码）落地。

如何工作

工作流按 MEASURE → MODEL → DESIGN → SPECIFY → VERIFY 推进，默认 SLO 优先。子命令包括 slo、tracing、alerts、dashboard、capacity、log、golden、toil 等；未命中子命令时走默认 SLO 设计配方。

核心约定包括：Google SRE 风格多窗口多燃烧速率告警（如 14.4×/6×/3×/1×）与错误预算门控（50%/75%/90%/100%）；在 Collector 侧默认尾部采样（错误与慢请求全留、成功请求按比例采样）；强制 OTel 语义约定（跟踪 1.40+），棕地场景可评估 OBI/eBPF 零代码 RED 与追踪；SLO 建议以 OpenSLO YAML 等方式版本化管理。

每条告警需关联运行手册；设计时强调跨信号关联、基数与成本（高基数标签进追踪而非指标），并对 AI/LLM 负载避免仅靠静态阈值。

边界与注意点

路由出去：监控/仪表实施 → Gear 或 Builder；基础设施部署 → Scaffold；性能调优 → Bolt；事件处置 → Triage；业务 KPI → Pulse。
必须先问清楚：影响决策的 SLO 目标、告警升级策略、采样率大改、仪表盘大重构。
不做：无运行手册的告警、无 SLI 覆盖就定告警策略、无限制指标基数、容忍长期高比例不可操作告警。

多服务审计时可并行 Explore 子 Agent 扫描现有仪表与 SLO，再由 Beacon 综合为统一策略；单服务任务保持串行即可。