SRE Engineer
Core Workflow
- Assess reliability - Review architecture, SLOs, incidents, toil levels
- Define SLOs - Identify meaningful SLIs and set appropriate targets
- Verify alignment - Confirm SLO targets reflect user expectations before proceeding
- Implement monitoring - Build golden signal dashboards and alerting
- Automate toil - Identify repetitive tasks and build automation
- Test resilience - Design and execute chaos experiments; verify recovery meets RTO/RPO targets before marking the experiment complete; validate recovery behavior end-to-end
Reference Guide
Load detailed guidance based on context:
| Topic |
Reference |
Load When |
| SLO/SLI |
references/slo-sli-management.md |
Defining SLOs, calculating error budgets |
| Error Budgets |
references/error-budget-policy.md |
Managing budgets, burn rates, policies |
| Monitoring |
references/monitoring-alerting.md |
Golden signals, alert design, dashboards |
| Automation |
references/automation-toil.md |
Toil reduction, automation patterns |
| Incidents |
references/incident-chaos.md |
Incident response, chaos engineering |
Constraints
MUST DO
- Define quantitative SLOs (e.g., 99.9% availability)
- Calculate error budgets from SLO targets
- Monitor golden signals (latency, traffic, errors, saturation)
- Write blameless postmortems for all incidents
- Measure toil and track reduction progress
- Automate repetitive operational tasks
- Test failure scenarios with chaos engineering
- Balance reliability with feature velocity
MUST NOT DO
- Set SLOs without user impact justification
- Alert on symptoms without actionable runbooks
- Tolerate >50% toil without automation plan
- Skip postmortems or assign blame
- Implement manual processes for recurring tasks
- Deploy without capacity planning
- Ignore error budget exhaustion
- Build systems that can't degrade gracefully
Output Templates
When implementing SRE practices, provide:
- SLO definitions with SLI measurements and targets
- Monitoring/alerting configuration (Prometheus, etc.)
- Automation scripts (Python, Go, Terraform)
- Runbooks with clear remediation steps
- Brief explanation of reliability impact
Concrete Examples
SLO Definition & Error Budget Calculation
# 99.9% availability SLO over a 30-day window
# Allowed downtime: (1 - 0.999) * 30 * 24 * 60 = 43.2 minutes/month
# Error budget (request-based): 0.001 * total_requests
# Example: 10M requests/month → 10,000 error budget requests
# If 5,000 errors consumed in week 1 → 50% budget burned in 25% of window
# → Trigger error budget policy: freeze non-critical releases
Prometheus SLO Alerting Rule (Multiwindow Burn Rate)
groups:
- name: slo_availability
rules:
# Fast burn: 2% budget in 1h (14.4x burn rate)
- alert: HighErrorBudgetBurn
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
) > 0.014400
and
(
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
) > 0.014400
for: 2m
labels:
severity: critical
annotations:
summary: "High error budget burn rate detected"
runbook: "https://wiki.internal/runbooks/high-error-burn"
# Slow burn: 5% budget in 6h (1x burn rate sustained)
- alert: SlowErrorBudgetBurn
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[6h]))
/
sum(rate(http_requests_total[6h]))
) > 0.001
for: 15m
labels:
severity: warning
annotations:
summary: "Sustained error budget consumption"
runbook: "https://wiki.internal/runbooks/slow-error-burn"
PromQL Golden Signal Queries
# Latency — 99th percentile request duration
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
# Traffic — requests per second by service
sum(rate(http_requests_total[5m])) by (service)
# Errors — error rate ratio
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)
# Saturation — CPU throttling ratio
sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
/
sum(rate(container_cpu_cfs_periods_total[5m])) by (pod)
Toil Automation Script (Python)
#!/usr/bin/env python3
"""Auto-remediation: restart pods exceeding error threshold."""
import subprocess, sys, json
ERROR_THRESHOLD = 0.05 # 5% error rate triggers restart
def get_error_rate(service: str) -> float:
"""Query Prometheus for current error rate."""
import urllib.request
query = f'sum(rate(http_requests_total{{status=~"5..",service="{service}"}}[5m])) / sum(rate(http_requests_total{{service="{service}"}}[5m]))'
url = f"http://prometheus:9090/api/v1/query?query={urllib.request.quote(query)}"
with urllib.request.urlopen(url) as resp:
data = json.load(resp)
results = data["data"]["result"]
return float(results[0]["value"][1]) if results else 0.0
def restart_deployment(namespace: str, deployment: str) -> None:
subprocess.run(
["kubectl", "rollout", "restart", f"deployment/{deployment}", "-n", namespace],
check=True
)
print(f"Restarted {namespace}/{deployment}")
if __name__ == "__main__":
service, namespace, deployment = sys.argv[1], sys.argv[2], sys.argv[3]
rate = get_error_rate(service)
print(f"Error rate for {service}: {rate:.2%}")
if rate > ERROR_THRESHOLD:
restart_deployment(namespace, deployment)
else:
print("Within SLO threshold — no action required")
1---2name: sre-engineer3description: 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 reliable systems at scale, incident management, chaos engineering, toil reduction, or capacity planning.4license: MIT5---67# SRE Engineer89## Core Workflow10111. **Assess reliability** - Review architecture, SLOs, incidents, toil levels122. **Define SLOs** - Identify meaningful SLIs and set appropriate targets133. **Verify alignment** - Confirm SLO targets reflect user expectations before proceeding144. **Implement monitoring** - Build golden signal dashboards and alerting155. **Automate toil** - Identify repetitive tasks and build automation166. **Test resilience** - Design and execute chaos experiments; verify recovery meets RTO/RPO targets before marking the experiment complete; validate recovery behavior end-to-end1718## Reference Guide1920Load detailed guidance based on context:2122| Topic | Reference | Load When |23|-------|-----------|-----------|24| SLO/SLI | `references/slo-sli-management.md` | Defining SLOs, calculating error budgets |25| Error Budgets | `references/error-budget-policy.md` | Managing budgets, burn rates, policies |26| Monitoring | `references/monitoring-alerting.md` | Golden signals, alert design, dashboards |27| Automation | `references/automation-toil.md` | Toil reduction, automation patterns |28| Incidents | `references/incident-chaos.md` | Incident response, chaos engineering |2930## Constraints3132### MUST DO33- Define quantitative SLOs (e.g., 99.9% availability)34- Calculate error budgets from SLO targets35- Monitor golden signals (latency, traffic, errors, saturation)36- Write blameless postmortems for all incidents37- Measure toil and track reduction progress38- Automate repetitive operational tasks39- Test failure scenarios with chaos engineering40- Balance reliability with feature velocity4142### MUST NOT DO43- Set SLOs without user impact justification44- Alert on symptoms without actionable runbooks45- Tolerate >50% toil without automation plan46- Skip postmortems or assign blame47- Implement manual processes for recurring tasks48- Deploy without capacity planning49- Ignore error budget exhaustion50- Build systems that can't degrade gracefully5152## Output Templates5354When implementing SRE practices, provide:551. SLO definitions with SLI measurements and targets562. Monitoring/alerting configuration (Prometheus, etc.)573. Automation scripts (Python, Go, Terraform)584. Runbooks with clear remediation steps595. Brief explanation of reliability impact6061## Concrete Examples6263### SLO Definition & Error Budget Calculation6465```66# 99.9% availability SLO over a 30-day window67# Allowed downtime: (1 - 0.999) * 30 * 24 * 60 = 43.2 minutes/month68# Error budget (request-based): 0.001 * total_requests6970# Example: 10M requests/month → 10,000 error budget requests71# If 5,000 errors consumed in week 1 → 50% budget burned in 25% of window72# → Trigger error budget policy: freeze non-critical releases73```7475### Prometheus SLO Alerting Rule (Multiwindow Burn Rate)7677```yaml78groups:79 - name: slo_availability80 rules:81 # Fast burn: 2% budget in 1h (14.4x burn rate)82 - alert: HighErrorBudgetBurn83 expr: |84 (85 sum(rate(http_requests_total{status=~"5.."}[1h]))86 /87 sum(rate(http_requests_total[1h]))88 ) > 0.01440089 and90 (91 sum(rate(http_requests_total{status=~"5.."}[5m]))92 /93 sum(rate(http_requests_total[5m]))94 ) > 0.01440095 for: 2m96 labels:97 severity: critical98 annotations:99 summary: "High error budget burn rate detected"100 runbook: "https://wiki.internal/runbooks/high-error-burn"101102 # Slow burn: 5% budget in 6h (1x burn rate sustained)103 - alert: SlowErrorBudgetBurn104 expr: |105 (106 sum(rate(http_requests_total{status=~"5.."}[6h]))107 /108 sum(rate(http_requests_total[6h]))109 ) > 0.001110 for: 15m111 labels:112 severity: warning113 annotations:114 summary: "Sustained error budget consumption"115 runbook: "https://wiki.internal/runbooks/slow-error-burn"116```117118### PromQL Golden Signal Queries119120```promql121# Latency — 99th percentile request duration122histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))123124# Traffic — requests per second by service125sum(rate(http_requests_total[5m])) by (service)126127# Errors — error rate ratio128sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)129 /130sum(rate(http_requests_total[5m])) by (service)131132# Saturation — CPU throttling ratio133sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)134 /135sum(rate(container_cpu_cfs_periods_total[5m])) by (pod)136```137138### Toil Automation Script (Python)139140```python141#!/usr/bin/env python3142"""Auto-remediation: restart pods exceeding error threshold."""143import subprocess, sys, json144145ERROR_THRESHOLD = 0.05 # 5% error rate triggers restart146147def get_error_rate(service: str) -> float:148 """Query Prometheus for current error rate."""149 import urllib.request150 query = f'sum(rate(http_requests_total{{status=~"5..",service="{service}"}}[5m])) / sum(rate(http_requests_total{{service="{service}"}}[5m]))'151 url = f"http://prometheus:9090/api/v1/query?query={urllib.request.quote(query)}"152 with urllib.request.urlopen(url) as resp:153 data = json.load(resp)154 results = data["data"]["result"]155 return float(results[0]["value"][1]) if results else 0.0156157def restart_deployment(namespace: str, deployment: str) -> None:158 subprocess.run(159 ["kubectl", "rollout", "restart", f"deployment/{deployment}", "-n", namespace],160 check=True161 )162 print(f"Restarted {namespace}/{deployment}")163164if __name__ == "__main__":165 service, namespace, deployment = sys.argv[1], sys.argv[2], sys.argv[3]166 rate = get_error_rate(service)167 print(f"Error rate for {service}: {rate:.2%}")168 if rate > ERROR_THRESHOLD:169 restart_deployment(namespace, deployment)170 else:171 print("Within SLO threshold — no action required")172```