SRE Cultura y Principios de Ingeniería

1) Qué es la cultura SRE

La cultura SRE es un conjunto de valores y prácticas que hacen que la confiabilidad sea manejable: objetivos SLO → error-presupuesto → riesgos de cambio conscientes → estabilización rápida → aprendizaje en incidentes.
Paradigma clave: la velocidad ≠ el enemigo de la fiabilidad. La velocidad de liberación es posible cuando los riesgos se dosifican y automatizan.

• User-centric: denota fiabilidad de la manera que el usuario la ve (SLI/SLO).
• Automation-first: cualquier acción repetible → script/política/controlador.
• Blamelessness: los errores son sistémicos, investigamos las causas, no las personas.
• Data-driven: soluciones basadas en métricas y presupuestos de errores.
• Simplicidad: mecanismos simples y verificables> soluciones «mágicas».

2) Principios básicos de ingeniería SRE

1. SLO/SLI y el presupuesto de errores son la base de las prioridades y alertas.
2. Incidente → estabilización → RCA - primero los síntomas, luego las causas.
3. La reducción del trabajo manual (toil) es el objetivo de ≤ el 50% del tiempo de ERE, con el tiempo más bajo.
4. Preparación prod - «producción readiness» es obligatorio antes del tráfico externo.
5. Simplicidad y aislamiento: menos interconexiones, más restricciones de blast radius.
6. La observabilidad por defecto es métricas/logs/trazados, widgets SLO, sintéticos.
7. Los cambios se gestionan - delivery progresivo, posts canarios, auto-rollback.
8. Seguridad por diseño - secretos, accesos, auditoría, privilegios mínimos.
9. Ciclos de entrenamiento - driley, juegos de caos, post mortem, retrospectivas.
10. FineOps Mindfulness - «precio de nueve», costo-a-serve, SLOs eficientes.

3) Rituales y procesos

3. 1 Production Readiness Review (PRR)

• SLI/SLO, dashboard y alertas (fast/slow burn).
• Los endpoints de salud '/healthz ', '/readyz', '/startupz '.
• Runbook/playbook incidentes, owner/on-call, escalation chain.
• Plan de backups/DR, límites de recursos, cálculos presupuestarios.
• Pruebas de tolerancia a fallas (flags, escenarios rollback).

3. 2 Reunión informativa semanal de SLO

Estado de error-budget por servicio.
Incidentes en una semana, progreso CAPA.
Riesgo de lanzamiento: donde se permite/limita a depla (según el presupuesto).

3. 3 Postmortem sin cargos

Hechos y tiempo en línea, influencia del usuario, que ayudó/impidió.
Causas sistémicas (procesos/herramientas), no «culpables».
CAPA específica con propietarios y plazos, publicidad dentro de la empresa.

3. 4 Juegos de caos y drilling

Inyecciones de fallas programadas (red, DB, caché, nodos) + SLO de destino.
«Game day»: tiempo para la estabilización, medición de MTTR, ajuste de playbooks.

4) Alerting y ruido

• Alert only on symptoms: SLO o ruta de usuario roto.
• Multi-window, multi-burn: canales rápidos y lentos.
• Quorum/anti-flapping: latencia 'for', supresión en mantenimiento.
• Una fracción de «CPU> 80%» es ese tipo de señales en los dashboards, no en el buscapersonas.

• La proporción de actionables ≥ del 80%.
• Median time-to-ack ≤ 5 minutos (por P1).
• Reducción de «Pager fatigue»: ≤ 1 pagina nocturna por semana por ingeniero.

5) Gestión de cambios

Progressive delivery: canary → 10% → 25% → 50% → 100%.
Auto-rollback a través de señales SLO (errores/latencia).
Características-flags y kill-switch en lugar de retroceso global.
Change policy by risk: fast lane для low-risk; APROB - Sólo high-risk.

yaml steps:
- setWeight: 10
- analysis: { template: "slo-check" } # fail ⇒ rollback
- setWeight: 25
- analysis: { template: "slo-check" }

6) Reducción del toil (trabajo manual de rutina)

Ejemplos de fuentes de toil: despojos manuales, reinicios, tickets de «dar acceso», limpieza de colas.

• Inventario de tareas repetibles → automatización/autoservicio.
• KPI:% del tiempo en toil, «pasos automatizados/incidente», «minutos antes de auto-servicio».
• Catálogo de servicios de la plataforma (namespaces, DB, colas, dashboards, alertas).

7) Observabilidad y SLO-primer diseño

Golden Signals (latency, traffic, errors, saturation).
Tarjetas SLO en cada equipo: objetivo, ventana, presupuesto, burn-alert.
Drilldown: de métricas a registros/rutas; 'trace _ id' en los logs predeterminados.
Sintética: blackbox + guiones sin título (login/deposite/checkout).

8) Gestión de la capacidad y sostenibilidad

Planificación de la capacidad: objetivo RPS/competencia, stock por región/AZ.
Bulkhead/shedding: aislamiento de pools, falla de funciones secundarias primero.
Backpressure y colas: Control de registros, DLQ, competencia adaptativa.
Failover y DR: RPO/RTO, driles DR regulares.

9) La seguridad como parte de la confiabilidad

Secretos: administrador de secretos, accesos JIT, auditoría.
WAF/DDoS-guard en el perímetro, límites por cliente/tenant.
PII-minimización, DSAR/Legal Hold en incidentes.
Seguridad de cadena de suministro: firma de artefactos, política de imágenes básicas.

10) Salud on-coll

Rotaciones sin «solteros», ventanas de descanso claras.
El umbral para «despertar por la noche» es solo P1/P2 por SLO.
Psicogigieno: la deficiencia del sueño se registra como un riesgo operativo.
Métricas: paginas/ned, paginas nocturnas/ingeniero, tiempo de recuperación.

11) Métricas de madurez SRE

SLO coverage: porcentaje de rutas críticas con SLO/alertas ≥ 90%.
Error-budget governance: hay reglas freeze y se aplican.
Toil: ≤ 30-40% del tiempo, tendencia a la baja.
MTTD/MTTR: medianas en dinámica trimestral.
Tasa de automitigación:% de los incidentes con acción automática.
PRR pass-rate: la proporción de lanzamientos que han pasado el pre-estado de preparación.
Postmortem SLA: SEV-1 - post mortem ≤ 48 horas.

12) Documentación y conocimientos

• Runbooks/playbooks (escenarios superiores: 5xx spike, DB lag, Kafka lag, NodeNotReady, TLS).
• Tarjetas SLO y dashboards.
• Listas de comprobación PRR y plantillas de lanzamiento.
• Catálogo de servicios de plataforma y OLAs/SLAs.
• Material didáctico: SRE 101, Chaos 101, On-call 101.

13) Anti-patrones

Hero-cultura: «salvavidas» en lugar de fijos del sistema.
Alerting ruidoso: CPU/discos en buscapersonas, cientos de señales innecesarias.
«DevOps es un ser humano»: una responsabilidad mancillada, sin propietarios.
Ausencia de SLO: «mantengamos todo verde» → el caos de la prioridad.
Postmortem diferido y «caza de brujas».
Retrocesos globales sin Canarias.
Secretos en la confiscación/repo; no hay auditoría de acciones.
Observabilidad como «gráficos hermosos» sin señales activables.

14) Patrones de artefactos

14. 1 SRE-Carta (fragmento)

yaml mission: "Make reliability manageable and economical"
tenets:
- "User - SLI/SLO Center"
- "Automation-first, minimizing toil"
- "Blameless & learning"
governance:
error_budget:
freeze_threshold: 0. 8 # 80% of the budget burned ⇒ release frieze review_cadence: "weekly"
oncall:
paging_policy: "SLO-only, P1/P2 at night"
health_metrics: ["pages_per_week", "night_pages_per_engineer"]

14. 2 Mini lista de verificación PRR

• SLI/SLO y burn-alerts personalizados
• Endpoints y sintéticos de salud
• Runbook/playbook + propietario/on-call
• Banderas Rollback/Fika/Canario
• Dashboards latency/errors/traffic/saturation
• Límites/cuotas/guardrails de seguridad
• Se ha probado el plan de DR y los backups

15) Implementación por etapas (4 sprints)

Sprint 1 - Fundación

Identificar rutas de usuario críticas y SLI.
Formular SLO y ejecutar burn-alertas.
Introduzca PRR y playbooks mínimos.

Sprint 2 - Gestión de cambios

Puestos canarios, auto-rollback por SLO.
Autoservicio de operaciones, catálogo de servicios.
Inventario de toil y plan de automatización.

Sprint 3 - Ciclos de formación

Un ritual post mortem, un calendario de juegos de caos.
Dashboards SLO + incidentes, informe error-budget.

Sprint 4 - Optimización y escala

Cartera de SLO, FinOps «costo por 9».
Implementación de la disciplina DR, auditoría de seguridad.
KPI on-colla, prevención de burnout.

16) Mini preguntas frecuentes

¿SRE = «arreglar todo»?
No. SRE gestiona el sistema de fiabilidad: SLO, alerting, procesos, automatización y formación.

¿Cómo convencer a las empresas para que inviertan en fiabilidad?
Mostrar ROI: reducción de MTTR, aumento de la conversión, menos créditos de SLA, menor costo-a-servicio, versiones estables.

¿Se necesitan equipos SRE individuales?
Modelo híbrido: SRE estratégico en plataforma + embedded-SRE en productos críticos.

Resultado

La cultura SRE no es un puesto, sino una forma de trabajar con riesgo: SLO → presupuesto de errores → cambios gestionados → automatización → capacitación. Fija los principios, establece rituales (PRR, postmortem, juegos de caos), quita el toil, construye la observabilidad «por defecto» y cuida de él-call. Así obtendrá una velocidad de desarrollo constante, lanzamientos predecibles y una plataforma confiable y económica.