sre-patterns

Provides Site Reliability Engineering best practices for SLOs, SLIs, SLAs, error budgets, toil reduction, reliability reviews, and capacity planning. Use when defining service objectives, measuring reliability, reducing toil, planning capacity, or when user mentions 'SRE', 'SLO', 'SLI', 'SLA', 'error budget', 'toil', 'reliability', 'on-call', 'capacity planning'.

Ir a la instalación

Repositorio: Tibsfox/gsd-skill-creator
Última actividad en el origen: 14 de abril de 2026 a las 07:57
Idioma detectado de SKILL.md: inglés
Estrellas: 69
Forks: 9

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.

npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill sre-patterns

El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.

¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

SKILL.md

Instrucciones de origen · Vista previa de solo lectura

Volver a la búsqueda Volver a la instalación

goal-ambiguity-gate

Use the moment a request is underspecified and you are about to act on an ASSUMED goal. Enumerate the candidate goals the request could mean, project the action or artifact each one implies, and check whether they diverge: if two or more plausible goals lead to materially different actions or artifacts, ask exactly ONE targeted clarifying question; otherwise proceed on the most-likely goal and state the assumption in one line. Clarification is an evidence-producing action, not a delay — but one question, never an interrogation. Distinct from gsd-spec-phase (GSD-phase-bound, emits a heavy SPEC.md) and intent-router (fetch strategy, not goal disambiguation). Backed by agent goal-state inference (arxiv 2606.16813v1). Triggers on acting under an assumed goal when the request admits more than one materially different reading.

2026-07-19

memory-hubness-gate

Use at write time to vector/embedding memory — Grove content-addressed insertion, chroma/pgvector upserts, memory-consolidation promoting session traces to MEMORY.md, or embedding externally-ingested content. Scores each candidate record against a fixed panel of sentinel queries and quarantines any record that would become the nearest neighbor of too many unrelated queries — a hub — whether from adversarial poisoning or accidental over-generality. This is the memory-record-side sibling of skill-injection-guardian (file-side) and the write-side complement of memory-use-warrant (read-side). Quarantine, never silently drop; a human reviews. Backed by the admission-time hubness gate (arxiv 2606.19692v1). Triggers on inserting into vector memory, consolidating memory, and embedding stranger content.

2026-07-19

memory-use-warrant

Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response.

2026-07-19

Ver todos los de este repositorio

name	sre-patterns
description	Provides Site Reliability Engineering best practices for SLOs, SLIs, SLAs, error budgets, toil reduction, reliability reviews, and capacity planning. Use when defining service objectives, measuring reliability, reducing toil, planning capacity, or when user mentions 'SRE', 'SLO', 'SLI', 'SLA', 'error budget', 'toil', 'reliability', 'on-call', 'capacity planning'.
type	skill
category	ops
status	stable
origin	tibsfox
modified	false
first_seen	"2026-02-07T00:00:00.000Z"
first_path	examples/sre-patterns/SKILL.md
superseded_by	null

SRE Patterns

Best practices for building and operating reliable systems using Site Reliability Engineering principles.

SLO / SLI / SLA Definitions

These three concepts form the foundation of SRE. They are distinct and frequently confused.

Concept	Definition	Owner	Example
SLI (Service Level Indicator)	A quantitative measurement of a service attribute	Engineering	99.2% of requests completed in < 300ms
SLO (Service Level Objective)	A target value or range for an SLI	Engineering + Product	99.5% of requests must complete in < 300ms
SLA (Service Level Agreement)	A contract with consequences for missing an SLO	Business + Legal	99.9% uptime or customer receives service credits

Relationship

SLI (what you measure)
 --> SLO (what you target, always stricter than SLA)
  --> SLA (what you promise externally, with penalties)

Key rule: SLO must be stricter than SLA. If your SLA promises 99.9% uptime, your internal SLO should target 99.95%. The gap is your safety margin.

SLI Specification

SLIs must be precise, measurable, and tied to user experience. Vague indicators lead to meaningless objectives.

SLI Types by Service Category

Service Type	SLI Category	Good Event	Valid Event
Request-driven	Availability	Response status < 500	All HTTP requests
Request-driven	Latency	Response time < 300ms	All HTTP requests
Data pipeline	Freshness	Data age < 10 minutes	All data records
Data pipeline	Correctness	Records with no processing errors	All processed records
Storage system	Durability	Objects retrievable after write	All stored objects
Storage system	Throughput	Read operations < 50ms	All read operations

SLO Target	Error Budget (30 days)	Error Budget (per quarter)	Practical Meaning
99.0%	7 hours 12 min	21 hours 36 min	Tolerates significant outages
99.5%	3 hours 36 min	10 hours 48 min	Weekly maintenance window feasible
99.9%	43 minutes 12 sec	2 hours 9 min	No room for long outages
99.95%	21 minutes 36 sec	1 hour 5 min	Requires high automation
99.99%	4 minutes 19 sec	12 min 58 sec	Requires redundancy at every layer

Characteristic	Description	Example
Manual	Requires a human to perform	SSH into server to restart service
Repetitive	Done more than once or twice	Weekly cert rotation by hand
Automatable	A machine could do it	Copying logs to analysis bucket
Reactive	Triggered by an event, not proactive	Responding to disk full alerts
No enduring value	Does not improve the service	Re-running failed batch jobs
Scales with service	More instances = more work	Manually updating configs per server

Review Area	Key Questions	Pass Criteria
SLOs defined	Are SLIs and SLOs documented?	At least availability + latency SLOs
Monitoring	Are dashboards and alerts configured?	SLO-based alerts with multi-window burn rate
Incident response	Is there a runbook?	Documented runbook with escalation paths
Capacity	Can it handle 2x current load?	Load test results proving headroom
Dependencies	Are failure modes mapped?	Dependency map with fallback behavior
Rollback	Can you revert within 5 minutes?	Tested rollback procedure
Data integrity	Are backups tested?	Backup restore tested within last 30 days
Security	Has threat modeling been done?	Threat model documented, critical items resolved

Practice	Recommendation	Rationale
Rotation length	1 week	Long enough for context, short enough to avoid burnout
Team size	Minimum 6-8 engineers	Ensures no one is on-call more than 1 in 6 weeks
Handoff	30-minute overlap meeting	Transfer context on active issues
Escalation	Primary -> Secondary -> Team Lead -> Manager	Clear chain prevents ambiguity
Response time	5 min acknowledge, 15 min start investigation	Documented in on-call agreement
Compensation	Time off in lieu or pay differential	On-call without compensation causes attrition

Alert Severity	Burn Rate	Long Window	Short Window	Action
Page (urgent)	14.4x	1 hour	5 minutes	Immediate investigation
Page (less urgent)	6x	6 hours	30 minutes	Investigate within 30 min
Ticket	3x	3 days	6 hours	Fix within 1 business day
Log	1x	28 days	3 days	Review at next planning

Severity	Definition	Response	Example
SEV1	Service down, all users affected	Immediate, all-hands	Total outage of payment processing
SEV2	Significant degradation, many users affected	Immediate, on-call team	Latency 10x normal, 30% errors
SEV3	Partial degradation, some users affected	Within 1 hour	One region experiencing failures
SEV4	Minor issue, few users affected	Next business day	Cosmetic issue in dashboard

Anti-Pattern	Problem	Fix
SLOs set by management without engineering input	Unrealistic targets that create constant fire-fighting	SLOs must be data-driven and jointly owned by eng + product
100% availability SLO	Impossible to maintain, blocks all deployments	Highest practical target is 99.999%; most services need 99.9%
SLIs measured at the server, not at the user	Misses network issues, CDN failures, client-side errors	Measure SLIs at the load balancer or client where possible
Error budget without a policy	Budget is tracked but nothing changes when it is consumed	Write and enforce a formal error budget policy document
Alerting on raw metrics instead of SLOs	Alert fatigue from non-user-impacting events	Use multi-window burn rate alerting tied to SLOs
Treating all toil as unavoidable	Team spends 60%+ time on repetitive manual work	Measure toil, set a budget (< 50%), automate top sources
No postmortems or blame-focused postmortems	Same incidents recur; engineers hide mistakes	Blameless postmortems with tracked action items
Capacity planning by gut feel	Over-provisioning wastes money; under-provisioning causes outages	Model growth, load test regularly, maintain 30% headroom
On-call without runbooks	Engineers waste time investigating known issues	Every alert must link to a runbook with diagnosis steps
On-call hero culture	One person handles everything, burns out, leaves with all context	Minimum team size of 6-8, mandatory rotation, no opt-out
Monitoring everything, alerting on nothing useful	Thousands of metrics, dashboards no one looks at	Focus on the 3-5 SLIs that represent user experience
SLAs more aggressive than SLOs	No safety margin; internal failures immediately become contract breaches	SLOs must be stricter than SLAs by a meaningful margin
Skipping reliability reviews before launch	Production issues discovered by users, not engineers	Mandatory pre-launch review with documented pass criteria

sre-patterns

Datos de origen

Opciones de instalación

Revisa los archivos de origen

Más de este repositorio

Más de este repositorio

SRE Patterns

SLO / SLI / SLA Definitions

Relationship

SLI Specification

SLI Types by Service Category

SLI Specification Example

SRE Patterns

SLO / SLI / SLA Definitions

Relationship

SLI Specification

SLI Types by Service Category

SLI Specification Example

Error Budget Calculation

Formula

Error Budget by SLO Level

Error Budget Burn Rate

Error Budget Policy

Toil Measurement and Reduction

Toil Characteristics

Toil Measurement Framework

Capacity Planning

Capacity Planning Model

Reliability Review Process

Pre-Launch Review

Ongoing Review Cadence

Monthly Service Health Review Template

On-Call Best Practices

On-Call Structure

Alert Quality

Multi-Window Burn Rate Alerting

Incident Management

Severity Levels

Postmortem Structure

Anti-Patterns

SRE Maturity Checklist

Level 1: Foundations

Level 2: Operational

Level 3: Proactive

Level 4: Optimized