技能 observability-monitoring-slo-implement
📊

observability-monitoring-slo-implement

安全

实施SLO和错误预算

设计和实施服务等级目标（SLO），使用SLI和错误预算来衡量和改进系统可靠性，同时平衡功能迭代速度。

支持: Claude Codex Code(CC)
🥉 72 青铜
1

下载技能 ZIP

2

在 Claude 中上传

前往 设置 → 功能 → 技能 → 上传技能

3

开启并开始使用

测试它

正在使用“observability-monitoring-slo-implement”。 为新的电子商务结账服务设计SLO

预期结果:

一个全面的SLO框架，包括：层级分类（关键）、可用性目标（99.95%）、延迟SLI（p95 < 500ms）、错误率SLI（< 0.1%）、错误预算计算（每月4.38小时）和消耗速率告警阈值。

正在使用“observability-monitoring-slo-implement”。 创建用于SLO跟踪的Prometheus记录规则

预期结果:

包含记录规则的YAML配置，用于请求速率、多个时间窗口（5m、30m、1h）的成功率、延迟百分位数（p50、p95、p99）和错误预算消耗速率计算。

安全审计

安全
v1 • 2/24/2026

Static analysis detected 57 potential issues, but manual review confirms all findings are false positives. The skill contains documentation with Python code examples for SLO implementation - no actual executable code, no network calls, and no cryptographic operations. The placeholder URLs use example.com domain. This is a legitimate DevOps reliability skill.

2
已扫描文件
1,124
分析行数
5
发现项
1
审计总数
中风险问题 (2)
resources/implementation-playbook.md:40resources/implementation-playbook.md:154-161SKILL.md:36SKILL.md:45
External Commands Detection in Documentation
Static scanner detected 'external_commands' pattern in markdown documentation. This is a false positive - the skill contains Python code examples in markdown blocks, not executable shell commands. The backtick syntax detected is part of Python f-strings and dictionary literals in documentation examples.
resources/implementation-playbook.md:969resources/implementation-playbook.md:970
Hardcoded URLs in Example Configuration
Static scanner detected placeholder URLs in YAML configuration examples. These are example.com domain URLs used as placeholders in documentation, not actual network endpoints.
低风险问题 (3)
resources/implementation-playbook.md:7resources/implementation-playbook.md:39SKILL.md:3
Numeric Pattern False Positives
Static scanner detected 'weak cryptographic algorithm' patterns at multiple locations. These are false positives - the numeric values detected (99.9%, 0.001, 14.4) are SLO availability targets and burn rate multipliers, not cryptographic algorithms.
resources/implementation-playbook.md:24SKILL.md:40
Documentation Language False Positive
Static scanner detected 'system reconnaissance' patterns. This is a false positive - words like 'analyze', 'assess', 'identify' are used in the legitimate context of service analysis for SLO design, not reconnaissance.
resources/implementation-playbook.md:1
Code Block Bracket Pattern
Static scanner detected 'obfuscation' pattern with multiple bracket chains. This is a false positive - the pattern detected is legitimate markdown code block formatting with Python dictionary and f-string syntax.
审计者: claude

质量评分

38
架构
100
可维护性
87
内容
50
社区
89
安全
91
规范符合性

你能构建什么

为新API服务定义SLO

根据服务关键性创建具有适当目标的可用性、延迟和错误率SLO

设置错误预算告警

配置多窗口消耗速率告警，以检测快速和慢速错误预算消耗

建立SLO审查流程

为工程团队创建每周SLO审查模板和治理流程

试试这些提示

基础SLO设计 
帮助我为支付处理服务设计SLO。该服务每分钟处理10,000个请求，需要高可靠性。我应该设置什么可用性目标，如何定义SLI？
SLI实施 
我需要使用Prometheus为REST API服务实施SLI。请向我展示如何创建可用性和延迟SLI查询，以跟踪成功请求的百分比和延迟低于500毫秒的请求。
错误预算告警 
为我的服务配置错误预算消耗速率告警，SLO目标为99.9%。我需要快速消耗（立即通知）和慢速消耗（创建工单）两种告警规则。
SLO治理 
为我的团队建立SLO治理框架，包括角色和职责、每周审查模板和利益相关方沟通流程。

最佳实践

  • 从保守的SLO目标开始，根据实际服务性能数据逐步收紧
  • 使用多个时间窗口的消耗速率告警，以捕获快速和慢速预算消耗
  • 将SLO目标与业务优先级和用户期望对齐，而不是技术便利性

避免

  • 初始SLO目标设置过紧，导致持续告警和告警疲劳
  • 仅使用可用性SLI而不考虑延迟或质量指标
  • 在未与利益相关方对齐或缺乏业务背景的情况下创建SLO

常见问题

SLO和SLA有什么区别？
SLO（服务等级目标）是工程团队承诺的内部目标。SLA（服务等级协议）是对客户的合同承诺，违反时会有财务后果。
如何选择正确的SLO可用性目标？
首先分析历史可用性，了解用户期望，并考虑业务影响。关键服务通常需要99.95%以上，而标准服务可能以99.5%为目标。
SLO测量应该使用什么时间窗口？
常用窗口是30天滚动可用性或用于计费周期的日历月。较长的窗口提供稳定性，但对问题的反馈较慢。
如何在SLO计算中处理计划维护？
从SLO测量中排除计划维护窗口，或使用考虑预期停机时间的可用性公式。清楚地记录您的方法。
错误预算耗尽时我应该怎么做？
暂停功能开发，专注于可靠性改进，并向利益相关方沟通状态。使用错误预算策略指导发布决策。
一个服务应该有多少个SLO？
从2-4个SLO开始，覆盖最重要的面向用户的方面：可用性、延迟和错误率。根据需要添加更多，但要避免告警疲劳。

开发者详情

作者

sickn33

许可证

MIT

仓库

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/observability-monitoring-slo-implement

引用

main

文件结构

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md