通过可衡量的 SLO 目标和错误预算，在可靠性和功能开发速度之间取得平衡。停止争论可靠性，开始使用行业标准 SRE 实践来衡量它。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“slo-implementation”。 Help me define SLIs and SLOs for my API service. I need availability and latency targets.
预期结果:
以下是您的 API 的推荐 SLI：
可用性 SLI：
- 成功请求数 / 总请求数
- 目标：99.9%（允许每月 43.2 分钟的停机时间）
- PromQL：sum(rate(http_requests_total{status!~'5..'}[28d])) / sum(rate(http_requests_total[28d]))
延迟 SLI（p95 < 500ms）：
- 低于阈值的请求数 / 总请求数
- 目标：99%（1% 的请求可以较慢）
- PromQL：sum(rate(http_request_duration_seconds_bucket{le='0.5'}[28d])) / sum(rate(http_request_duration_seconds_count[28d]))
错误预算：
- 0.1% 预算 = 每月 43.2 分钟
- 实施消耗速率警报以在预算消耗过快时检测
正在使用“slo-implementation”。 Create Prometheus alerting rules for multi-window burn rate detection.
预期结果:
多窗口消耗速率警报规则：
快速消耗警报（严重）：
- 窗口：1 小时和 5 分钟确认
- 阈值：14.4x 消耗速率
- 触发条件：1 小时内消耗 2% 的错误预算
- 行动：立即呼叫待命工程师
慢速消耗警报（警告）：
- 窗口：6 小时和 30 分钟确认
- 阈值：6x 消耗速率
- 触发条件：6 小时内消耗 5% 的错误预算
- 行动：为下一个工作日创建工单
错误预算耗尽（严重）：
- 触发条件：剩余错误预算 < 0%
- 持续时间：5 分钟持续
- 行动：功能冻结，全员专注于可靠性
正在使用“slo-implementation”。 Design an error budget policy for a 99.9% SLO target.
预期结果:
99.9% SLO 的错误预算策略：
预算：0.1% = 每月 43.2 分钟
剩余 100% 预算时：
- 正常的开发速度
- 允许发布所有功能
剩余 50% 预算时：
- 推迟非必要的更改
- 为发布要求额外的测试
- 增加监控覆盖范围
剩余 10% 预算时：
- 冻结非关键功能
- 仅允许安全和热修复发布
- 每日可靠性站会
剩余 0% 预算时：
- 完全功能冻结
- 100% 专注于可靠性改进
- 未经 SRE 批准不得发布
- 需要根本原因分析
安全审计
安全Static analysis detected 35 potential security issues, all of which are false positives. The flagged 'Ruby/shell backtick execution' patterns are Markdown code formatting (backticks) used for PromQL queries and YAML examples. The 'weak cryptographic algorithm' flags are documentation text and annotations, not actual encryption code. This skill contains only documentation with no executable code, network operations, or security vulnerabilities.
低风险问题 (2)
质量评分
你能构建什么
建立可靠性基线
为新的微服务定义初始 SLI 和 SLO，以设置可衡量的可靠性目标，并创建能捕获实际问题而不会产生误报疲劳的警报。
实施错误预算治理
创建错误预算策略，当可靠性下降时自动冻结有风险的部署，帮助平衡功能速度和稳定性需求。
减少警报疲劳
使用多窗口消耗速率警报替换脆弱的阈值警报，仅在显著的可靠性下降时触发，将通知噪音减少 80%。
试试这些提示
帮我为我的 API 服务定义 SLI 和 SLO。我需要可用性和延迟目标。
为 99.9% 的 SLO 目标设计错误预算策略。定义在剩余预算 100%、50%、10% 和 0% 时的行动。
创建用于多窗口消耗速率检测的 Prometheus 警报规则。使用快速消耗（1h/5m）和慢速消耗（6h/30m）窗口。
分析我当前的 SLO 合规数据。显示剩余错误预算、消耗速率趋势，并建议是否冻结功能发布。
最佳实践
- 从直接衡量客户体验的用户端 SLI 开始，而不是后端指标
- 将可实现的 SLO 设置在略低于当前性能的水平，以允许正常变化并防止持续警报
- 使用多窗口消耗速率警报（结合短窗口和长窗口）来消除瞬时波动产生的误报
- 每季度审查 SLO，以确保它们仍然反映业务优先级和实际用户需求
避免
- 将 SLO 目标设置为 100% 的可用性，这会消除所有错误预算并阻止任何功能开发
- 在原始指标阈值上创建警报而不是消耗速率，导致正常波动引起警报疲劳
- 定义太多 SLI，这会分散注意力并使优先考虑可靠性改进变得不可能
- 在没有管理层支持错误预算策略的情况下实施 SLO，使治理无法执行