sre-engineer

Name: sre-engineer
Author: Jeffallan

11kstars971forks

How to install sre-engineer?

jeffallan/claude-skills/sre-engineer

$npx -y skills add Jeffallan/claude-skills --skill sre-engineer

Installs into the current project.

Summary

Defines service level objectives, creates error budget policies, designs incident response procedures, develops capacity models, and produces monitoring configurations and automation scripts for production systems. Use when defining SLIs/SLOs, managing error budgets, building rel

Files · 1

View on GitHub

SKILL.md

1	# SRE Engineer
2
3	## Core Workflow
4
5	1. Assess reliability - Review architecture, SLOs, incidents, toil levels
6	2. Define SLOs - Identify meaningful SLIs and set appropriate targets
7	3. Verify alignment - Confirm SLO targets reflect user expectations before proceeding
8	4. Implement monitoring - Build golden signal dashboards and alerting
9	5. Automate toil - Identify repetitive tasks and build automation
10	6. Test resilience - Design and execute chaos experiments; verify recovery meets RTO/RPO targets before marking the experiment complete; validate recovery behavior end-to-end
11
12	## Reference Guide
13
14	Load detailed guidance based on context:
15
16	\| Topic \| Reference \| Load When \|
17	\|-------\|-----------\|-----------\|
18	\| SLO/SLI \| `references/slo-sli-management.md` \| Defining SLOs, calculating error budgets \|
19	\| Error Budgets \| `references/error-budget-policy.md` \| Managing budgets, burn rates, policies \|
20	\| Monitoring \| `references/monitoring-alerting.md` \| Golden signals, alert design, dashboards \|
21	\| Automation \| `references/automation-toil.md` \| Toil reduction, automation patterns \|
22	\| Incidents \| `references/incident-chaos.md` \| Incident response, chaos engineering \|
23
24	## Constraints
25
26	### MUST DO
27	- Define quantitative SLOs (e.g., 99.9% availability)
28	- Calculate error budgets from SLO targets
29	- Monitor golden signals (latency, traffic, errors, saturation)
30	- Write blameless postmortems for all incidents
31	- Measure toil and track reduction progress
32	- Automate repetitive operational tasks
33	- Test failure scenarios with chaos engineering
34	- Balance reliability with feature velocity
35
36	### MUST NOT DO
37	- Set SLOs without user impact justification
38	- Alert on symptoms without actionable runbooks
39	- Tolerate >50% toil without automation plan
40	- Skip postmortems or assign blame
41	- Implement manual processes for recurring tasks
42	- Deploy without capacity planning
43	- Ignore error budget exhaustion
44	- Build systems that can't degrade gracefully
45
46	## Output Templates
47
48	When implementing SRE practices, provide:
49	1. SLO definitions with SLI measurements and targets
50	2. Monitoring/alerting configuration (Prometheus, etc.)
51	3. Automation scripts (Python, Go, Terraform)
52	4. Runbooks with clear remediation steps
53	5. Brief explanation of reliability impact
54
55	## Concrete Examples
56
57	### SLO Definition & Error Budget Calculation
58
59	```
60	# 99.9% availability SLO over a 30-day window
61	# Allowed downtime: (1 - 0.999) * 30 * 24 * 60 = 43.2 minutes/month
62	# Error budget (request-based): 0.001 * total_requests
63
64	# Example: 10M requests/month → 10,000 error budget requests
65	# If 5,000 errors consumed in week 1 → 50% budget burned in 25% of window
66	# → Trigger error budget policy: freeze non-critical releases
67	```
68
69	### Prometheus SLO Alerting Rule (Multiwindow Burn Rate)
70
71	```yaml
72	groups:
73	- name: slo_availability
74	rules:
75	# Fast burn: 2% budget in 1h (14.4x burn rate)
76	- alert: HighErrorBudgetBurn
77	expr: \|
78	(
79	sum(rate(http_requests_total{status=~"5.."}[1h]))
80	/
81	sum(rate(http_requests_total[1h]))
82	) > 0.014400
83	and
84	(
85	sum(rate(http_requests_total{status=~"5.."}[5m]))
86	/
87	sum(rate(http_requests_total[5m]))
88	) > 0.014400
89	for: 2m
90	labels:
91	severity: critical
92	annotations:
93	summary: "High error budget burn rate detected"
94	runbook: "https://wiki.internal/runbooks/high-error-burn"
95
96	# Slow burn: 5% budget in 6h (1x burn rate sustained)
97	- alert: SlowErrorBudgetBurn
98	expr: \|
99	(
100	sum(rate(http_requests_total{status=~"5.."}[6h]))
101	/
102	sum(rate(http_requests_total[6h]))
103	) > 0.001
104	for: 15m
105	labels:
106	severity: warning
107	annotations:
108	summary: "Sustained error budget consumption"
109	runbook: "https://wiki.internal/runbooks/slow-error-burn"
110	```
111
112	### PromQL Golden Signal Queries
113
114	```promql
115	# Latency — 99th percentile request duration
116	histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
117
118	# Traffic — requests per second by service
119	sum(rate(http_requests_total[5m])) by (service)

People who liked this also viewed

6 picks

Type

sre-engineer

11kstars971forks

View on GitHub

How to install sre-engineer?

jeffallan/claude-skills/sre-engineer

$npx -y skills add Jeffallan/claude-skills --skill sre-engineer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SRE Engineer
2
3	## Core Workflow
4
5	1. Assess reliability - Review architecture, SLOs, incidents, toil levels
6	2. Define SLOs - Identify meaningful SLIs and set appropriate targets
7	3. Verify alignment - Confirm SLO targets reflect user expectations before proceeding
8	4. Implement monitoring - Build golden signal dashboards and alerting
9	5. Automate toil - Identify repetitive tasks and build automation
10	6. Test resilience - Design and execute chaos experiments; verify recovery meets RTO/RPO targets before marking the experiment complete; validate recovery behavior end-to-end
11
12	## Reference Guide
13
14	Load detailed guidance based on context:
15
16	\| Topic \| Reference \| Load When \|
17	\|-------\|-----------\|-----------\|
18	\| SLO/SLI \| `references/slo-sli-management.md` \| Defining SLOs, calculating error budgets \|
19	\| Error Budgets \| `references/error-budget-policy.md` \| Managing budgets, burn rates, policies \|
20	\| Monitoring \| `references/monitoring-alerting.md` \| Golden signals, alert design, dashboards \|
21	\| Automation \| `references/automation-toil.md` \| Toil reduction, automation patterns \|
22	\| Incidents \| `references/incident-chaos.md` \| Incident response, chaos engineering \|
23
24	## Constraints
25
26	### MUST DO
27	- Define quantitative SLOs (e.g., 99.9% availability)
28	- Calculate error budgets from SLO targets
29	- Monitor golden signals (latency, traffic, errors, saturation)
30	- Write blameless postmortems for all incidents
31	- Measure toil and track reduction progress
32	- Automate repetitive operational tasks
33	- Test failure scenarios with chaos engineering
34	- Balance reliability with feature velocity
35
36	### MUST NOT DO
37	- Set SLOs without user impact justification
38	- Alert on symptoms without actionable runbooks
39	- Tolerate >50% toil without automation plan
40	- Skip postmortems or assign blame
41	- Implement manual processes for recurring tasks
42	- Deploy without capacity planning
43	- Ignore error budget exhaustion
44	- Build systems that can't degrade gracefully
45
46	## Output Templates
47
48	When implementing SRE practices, provide:
49	1. SLO definitions with SLI measurements and targets
50	2. Monitoring/alerting configuration (Prometheus, etc.)
51	3. Automation scripts (Python, Go, Terraform)
52	4. Runbooks with clear remediation steps
53	5. Brief explanation of reliability impact
54
55	## Concrete Examples
56
57	### SLO Definition & Error Budget Calculation
58
59	```
60	# 99.9% availability SLO over a 30-day window
61	# Allowed downtime: (1 - 0.999) * 30 * 24 * 60 = 43.2 minutes/month
62	# Error budget (request-based): 0.001 * total_requests
63
64	# Example: 10M requests/month → 10,000 error budget requests
65	# If 5,000 errors consumed in week 1 → 50% budget burned in 25% of window
66	# → Trigger error budget policy: freeze non-critical releases
67	```
68
69	### Prometheus SLO Alerting Rule (Multiwindow Burn Rate)
70
71	```yaml
72	groups:
73	- name: slo_availability
74	rules:
75	# Fast burn: 2% budget in 1h (14.4x burn rate)
76	- alert: HighErrorBudgetBurn
77	expr: \|
78	(
79	sum(rate(http_requests_total{status=~"5.."}[1h]))
80	/
81	sum(rate(http_requests_total[1h]))
82	) > 0.014400
83	and
84	(
85	sum(rate(http_requests_total{status=~"5.."}[5m]))
86	/
87	sum(rate(http_requests_total[5m]))
88	) > 0.014400
89	for: 2m
90	labels:
91	severity: critical
92	annotations:
93	summary: "High error budget burn rate detected"
94	runbook: "https://wiki.internal/runbooks/high-error-burn"
95
96	# Slow burn: 5% budget in 6h (1x burn rate sustained)
97	- alert: SlowErrorBudgetBurn
98	expr: \|
99	(
100	sum(rate(http_requests_total{status=~"5.."}[6h]))
101	/
102	sum(rate(http_requests_total[6h]))
103	) > 0.001
104	for: 15m
105	labels:
106	severity: warning
107	annotations:
108	summary: "Sustained error budget consumption"
109	runbook: "https://wiki.internal/runbooks/slow-error-burn"
110	```
111
112	### PromQL Golden Signal Queries
113
114	```promql
115	# Latency — 99th percentile request duration
116	histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
117
118	# Traffic — requests per second by service
119	sum(rate(http_requests_total[5m])) by (service)

People who liked this also viewed

6 picks

Type