SRE工程

这个技能解决什么问题

服务可用性目标经常停留在一句「尽量稳定」上。没有明确定义 SLI、窗口和错误预算，团队会在发布节奏和稳定性之间反复拉扯：低峰期不敢发布，出了故障又找不到统一的复盘方式。运维工作也常缺一份可执行的事故响应策略，从告警到复盘行动项的链路都是断的。

@kunlungrowth/kg-sre-engineer 就是为这类模糊起点准备的。它把你对服务的约束和需求，逐步翻译成结构化的 SRE 策略，而不是给你一堆泛泛的最佳实践。

核心能力与工作流

该技能的核心产出是一个类型化的工件 SrePolicy，结构如下：

{
  "service": "支付服务",
  "slo": "成功率 ≥ 99.9%，30天滚动窗口",
  "error_budget": "月度预算 0.1%，耗尽后冻结非紧急发布",
  "incidents": ["P1 立即响应", "P2 次日复盘"],
  "notes": "大促期间预算减半"
}

工作流分为五步：

1. 明确用户旅程：先锁定最关键的体验路径，避免对所有指标一视同仁。
2. 定义 SLO：选定 SLI、目标值和时间窗口。
3. 制定错误预算策略：预算耗尽时，冻结发布还是降低风险，需要明确成规则。
4. 设计事故响应：响应流程、复盘机制和行动项负责人。
5. 输出工件：返回完整的 SrePolicy。

最终输出包含两部分：结构化的 SrePolicy 完整内容，以及一段自然语言摘要，指出最该改进的 2-3 个点。详细模板、质量自检清单和常见陷阱参考 references/template.md。

适用边界与注意点

该技能适用于需求描述阶段，以及已有 SrePolicy 需要二次优化的场景。输入可以是自然语言加可选代码片段，也可以直接接收结构化策略。

但它不做两件事：不负责监控面板设计，那部分应交给 monitoring-expert；也不替代业务侧对最终可用性的决策。生成的 SrePolicy 会作为下游 monitoring-expert 落地告警的输入，但目标值和冻结策略仍需业务方确认。