sre

Generates SLOs, burn-rate alerts, chaos experiments, runbooks, and capacity plans for production systems.

1|Updated Jun 24, 2026
One-click install
npx skills add https://github.com/sundarshahi/drydock --skill sre-sundarshahi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sre
Source: https://github.com/sundarshahi/drydock/tree/main/skills/sre
Command: npx skills add https://github.com/sundarshahi/drydock --skill sre-sundarshahi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams shipping to production often lack defined reliability targets, actionable alerts, tested failure plans, and runbooks an on-call engineer can follow at 3 AM. This Skill turns existing infrastructure and architecture artifacts into a complete site reliability engineering package with measurable SLOs and a blocking production-readiness gate. ## Core Features & Use Cases - Production Readiness Review: Audits every service against health checks, graceful shutdown, timeouts, retries, and a 15-factor compliance table where each verdict cites a proving artifact. - SLO and Alerting Definitions: Authors SLI/SLO definitions, multi-window burn-rate Prometheus alerts, error budget policies, and Grafana dashboards using only metric names declared in the project's observability contract. - Chaos Engineering and Incident Management: Produces Chaos Mesh scenarios with steady-state hypotheses, game-day playbooks with abort criteria, severity classifications, on-call rotations, and per-service runbooks with decision trees and kill-switch procedures. - Capacity Planning: Models load at 1x, 10x, and 100x scale, validates HPA configs, projects costs, and ranks the first components to saturate. - Use Case: After DevOps provisions Kubernetes and Terraform infrastructure, invoke this Skill to define availability and latency SLOs per endpoint, emit a make production-ready CI gate, and hand on-call engineers runbooks with exact kubectl and PromQL commands. ## Quick Start Ask the drydock orchestrator to run the sre skill to define SLOs, alerts, runbooks, and a production-readiness gate for the deployed services.

Frequently Asked Questions about sre

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I define SLOs and burn-rate alerts for a Kubernetes service?▼

The Skill writes sli-definitions.yaml and burn-rate-alerts.yaml using the Google SRE workbook multi-window method, with PromQL expressions restricted to metric names declared in the project's observability contract. Latency thresholds are read from performance-budget.yaml rather than hardcoded.

What is the difference between DevOps and SRE responsibilities in this workflow?▼

DevOps owns infrastructure provisioning, CI/CD pipelines, and base monitoring installation. SRE owns SLO definitions, error budgets, service-level alerting, incident response processes, chaos engineering, and capacity planning, and DevOps implements the thresholds SRE defines.

Does the production-ready gate block deployments on failing checks?▼

Yes. The emitted production-ready.sh script and GitHub Actions job exit non-zero on metric-name drift, invalid alert rules, SLO-versus-budget mismatches, unjustified factor-compliance failures, missing kill-switch keys, or failing tests. Overrides require a logged accepted-with-justification entry.

How do chaos engineering experiments validate system reliability?▼

Each Chaos Mesh scenario defines a measurable steady-state hypothesis using contract metric names before injecting failures like pod kills, network partitions, or resource pressure. The game-day playbook includes explicit abort criteria and progresses from low-risk to high-risk experiments.

What makes the generated runbooks usable during a real incident?▼

Runbooks contain exact kubectl and PromQL commands with real pod labels and metric names, decision trees instead of prose, and an emergency mitigation step that flips an ops kill-switch flag from config/feature-flags.yaml before attempting a rollback.