SLO 架构师

它解决什么问题

很多团队的"SLO"只是随手抄来的 99.9%：没有 SLI 定义、没有错误预算，预算烧完了也没人知道该做什么。slo-architect 针对《Google SRE 手册》总结的四类经典错误：目标定得太高（小抖动就违规，告警沦为噪音）、SLI 选错（拿 CPU 使用率当用户体验代理）、没有错误预算策略（烧预算没有任何约定动作）、单窗口告警（要么太吵，要么事后才发现）。

它如何工作

技能内置三个纯标准库 Python 工具，分工明确：

• slo_designer.py：生成结构化 SLO 定义，缺少必填字段直接拒绝渲染（exit 1），支持 request-success-rate、request-latency、availability-time、data-freshness、correctness 五种 SLI 类型；
• error_budget_calculator.py：给定目标可用性和统计窗口，算出允许停机时间与多窗口 burn-rate 阈值（fast burn：1 小时烧掉 2% 月预算；slow burn：6 小时烧 10%），并输出可直接粘贴的 PromQL 形态告警规则；
• slo_review.py：批量审计 SLO 定义目录，检查目标过高或过低、窗口太短、缺少 SLI 定义、缺少错误预算策略、拿 CPU 当 SLI 等常见缺陷。

典型工作流是先定义 SLO，再把 error_budget_calculator.py 的输出喂给 chaos-engineering 的爆炸半径计算器，让发布中止、混沌实验和告警规则围绕同一份错误预算运转。/slo-design 命令会把三个工具串成一个交互式向导。

适用边界

它不管通用可观测性策略（那是 observability-designer 的事），不写有法律效力的客户 SLA，不做性能压测，也不处理进行中的事故响应。SLO 目标必须比合同 SLA 更紧——客户察觉到之前，你应该已经达标。