用途：面向 Honeycomb 的可靠性配置与解读技能，聚焦 SLO 设计、SLO 与 Trigger 的取舍，以及指标含义。get_slos、get_triggers 工具的参数由其自身文档说明，本技能负责方法论。
SLO 与 Trigger 取舍：SLO 衡量一段时间内对可靠性承诺的达成情况，用于“是否达标”“预算消耗多快”“是否该放慢发布”；Trigger 捕获即时运维问题，用于“现在是否故障”“错误数是否超阈值”。SLO 需 Pro 或 Enterprise 套餐，Trigger 所有套餐可用。
设计 SLO：先定义 SLI，即逐事件布尔值，格式为 IF(<限定条件>, <成功条件>)，不满足限定条件时返回 undefined，SLI 不填充。限定条件筛选相关事件，成功条件定义成功，例如延迟 LTE(duration_ms,500)、可用性 LTE(http.status_code,499)。目标设置要保守（先 99% 再 99.99%），先用 P50/P99 查当前基线，目标略高于现状，并考虑用户真正需要的可靠性。
告警配置：至少两类耗尽时间告警——接近耗尽（约 4 小时）通过 PagerDuty 呼叫值班，趋势耗尽（24 小时预算速率）通过 Slack 通知团队；还可配置冒耗率告警，如 1 小时冒耗率大于 10 倍时呼叫值班。技能可建议这些告警，但 Agent 无法自行设置告警或接收人。
最佳实践：贴近用户侧测量；围绕用户工作流而非团队边界设计；偏好宽泛 SLO 而非大量窄 SLO；先做一个 SLO 降噪再扩展。
解读状态（用 get_slos）：预算剩余大于 50% 健康；10%-50% 谨慎、放慢变更；小于 10% 有风险、冻结非关键发布；为负则已违约，立即用 production-investigation 技能排查；合规度为 0% 多半 SLI 配置错误（列错、逻辑反、无匹配事件）。
Triggers：优先基于计数而非百分位，如“2 秒以上请求超过 50 条”比“P99 为 2100ms”更可操作，用 COUNT WHERE duration_ms > 阈值。常见：错误激增、慢请求、流量下跌。命名写告警内容，描述写处理动作并链接 runbook；持续时间至少 5-10 分钟避免抖动；先降低敏感度再按误报收紧。
多服务 SLO：最多 10 个服务共享一个错误预算，SLI 须为环境级计算字段，各服务事件等权，适用于多个边缘服务或单体拆微服务迁移。
注意：工作区 SLO 和 Trigger 数量有限，执行创建工具前须与用户确认，展示全部参数与理由；工具无法直接链接 SLO 页面，只能链接列表 /<team_slug>/environments/<environment_slug>/slos。
参考资料：slo-design-guide.md、trigger-examples.md、alerting-strategy.md；交叉参考 query-patterns 与 production-investigation 技能。以上未提及的收费、价格等信息暂未提供。