sre-operational-readinesslisted

Use whenever building, launching, or operating a service that runs in production — new services, endpoints, or any system that must stay up and be debuggable. Applies Google-style Site Reliability Engineering: define SLIs/SLOs and error budgets, instrument the four golden signals, write symptom-based alerts that don't page on noise, and prepare incident response, blameless postmortems, runbooks, and a production-readiness review BEFORE launch. Trigger proactively on "SLO," "SLA," "uptime," "reliability," "monitoring," "alerting," "on-call," "incident," "postmortem," "runbook," "observability," "metrics," "dashboards," "goes down," "how do we know if it breaks," or any production launch — even without those words. Pairs with enterprise-architecture-standards (observability), release-deployment-safety (canary signals), and bdd-comprehensive-testing.
techfleetworks/enterprise-software-AI-skills · ★ 0 · Code & Development · score 70

Install: claude install-skill techfleetworks/enterprise-software-AI-skills

# SRE & Operational Readiness ## Why this exists Software that "works" and software that "runs reliably at scale" are different disciplines. The gap is operational: knowing your service is healthy from the *user's* perspective, being paged only when it matters, resolving incidents fast, and learning from failure without blame. Elite orgs (Google SRE, and the teams that copied them) treat reliability as a measured, budgeted engineering property �� not a hope. This skill makes a service *operable* before it's launched, not after the first 2 a.m. page. It complements the `enterprise-architecture-standards` observability reference (which covers instrumentation mechanics) by adding the SRE *practices* around it: what to measure, when to page, how to respond, and how to learn. ## The core principle **100% reliability is the wrong target.** The right target is an explicit SLO (e.g. 99.9%) with an **error budget** — the allowed amount of unreliability. That budget turns reliability into a shared, quantitative decision: if you're within budget, ship features fast; if you've burned it, freeze features and fix reliability. Everything below serves this loop: measure user-facing health → alert on it → respond → learn → adjust. ## The workflow ### Step 1: Define SLIs and SLOs before launch Read `references/slis-slos-error-budgets.md`. For each user-facing service: - Pick **SLIs** (Service Level Indicators) that reflect *user experience*: availability (successful requests / tota