Balance reliability with feature velocity using measurable SLO targets and error budgets. Stop debating reliability and start measuring it with industry-standard SRE practices.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "slo-implementation". Help me define SLIs and SLOs for my API service. I need availability and latency targets.
النتيجة المتوقعة:
Here are recommended SLIs for your API:
Availability SLI:
- Successful requests / Total requests
- Target: 99.9% (allows 43.2 min/month downtime)
- PromQL: sum(rate(http_requests_total{status!~'5..'}[28d])) / sum(rate(http_requests_total[28d]))
Latency SLI (p95 < 500ms):
- Requests below threshold / Total requests
- Target: 99% (1% of requests can be slow)
- PromQL: sum(rate(http_request_duration_seconds_bucket{le='0.5'}[28d])) / sum(rate(http_request_duration_seconds_count[28d]))
Error Budget:
- 0.1% budget = 43.2 minutes/month
- Implement burn rate alerts to detect when consuming budget too quickly
استخدام "slo-implementation". Create Prometheus alerting rules for multi-window burn rate detection.
النتيجة المتوقعة:
Multi-Window Burn Rate Alert Rules:
Fast Burn Alert (Critical):
- Window: 1 hour and 5 minute confirmation
- Threshold: 14.4x burn rate
- Triggers when: Consuming 2% of error budget in 1 hour
- Action: Page on-call engineer immediately
Slow Burn Alert (Warning):
- Window: 6 hours and 30 minute confirmation
- Threshold: 6x burn rate
- Triggers when: Consuming 5% of error budget in 6 hours
- Action: Create ticket for next business day
Error Budget Exhausted (Critical):
- Trigger: Error budget remaining < 0%
- Duration: 5 minutes sustained
- Action: Feature freeze, all-hands on reliability
استخدام "slo-implementation". Design an error budget policy for a 99.9% SLO target.
النتيجة المتوقعة:
Error Budget Policy for 99.9% SLO:
Budget: 0.1% = 43.2 minutes per month
At 100% budget remaining:
- Normal development velocity
- All features allowed to ship
At 50% budget remaining:
- Postpone non-essential changes
- Require extra testing for releases
- Increase monitoring coverage
At 10% budget remaining:
- Freeze non-critical features
- Only security and hotfix releases
- Daily reliability standups
At 0% budget remaining:
- Complete feature freeze
- Focus 100% on reliability improvements
- No releases without SRE approval
- Root cause analysis required
التدقيق الأمني
آمن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)
درجة الجودة
ماذا يمكنك بناءه
Establish Reliability Baseline
Define initial SLIs and SLOs for a new microservice to set measurable reliability targets and create alerting that catches actual problems without false alarm fatigue.
Implement Error Budget Governance
Create error budget policies that automatically freeze risky deployments when reliability degrades, helping balance feature velocity with stability requirements.
Reduce Alert Fatigue
Replace brittle threshold alerts with multi-window burn rate alerts that only trigger on significant reliability degradation, cutting notification noise by 80%.
جرّب هذه الموجهات
Help me define SLIs and SLOs for my API service. I need availability and latency targets.
Design an error budget policy for a 99.9% SLO target. Define actions at 100%, 50%, 10%, and 0% remaining budget.
Create Prometheus alerting rules for multi-window burn rate detection. Use fast burn (1h/5m) and slow burn (6h/30m) windows.
Analyze my current SLO compliance data. Show error budget remaining, burn rate trends, and recommend whether to freeze feature releases.
أفضل الممارسات
- Start with user-facing SLIs that directly measure customer experience rather than backend metrics
- Set achievable SLOs slightly below current performance to allow for normal variance and prevent constant alerting
- Use multi-window burn rate alerts (combine short and long windows) to eliminate false positives from transient blips
- Review SLOs quarterly to ensure they still reflect business priorities and actual user needs
تجنب
- Setting SLO targets at 100% availability which eliminates all error budget and prevents any feature development
- Creating alerts on raw metric thresholds instead of burn rates, causing alert fatigue from normal fluctuations
- Defining too many SLIs which dilutes focus and makes it impossible to prioritize reliability improvements
- Implementing SLOs without executive buy-in for error budget policies, rendering the governance unenforceable