Ingeniería de confiabilidad

1) Qué es el ERE y por qué es necesario

Ingeniería de confiabilidad (SRE, Site Reliability Engineering) es una disciplina en la unión de desarrollo y operación que transforma la confiabilidad en un atributo de producto medible. SRE conecta métricas de experiencia de usuario (SLI), objetivos de calidad (SLO), presupuestos de errores, automatización y cambios gestionados para entregar valor más rápidamente sin perder la sostenibilidad.

Objetivos clave: UX predecible, lanzamientos rápidos, downtime mínimo y costo de propiedad controlado.

2) Principios SRE

Fiabilidad como ficha. Se prioriza hasta los límites establecidos por SLO y los objetivos empresariales.
El presupuesto de errores controla la velocidad de los cambios. Si se quema el presupuesto, el foco está en la estabilidad.
Automatización> operaciones manuales. Cualquier tarea repetible es script/operador/pipeline.
Medida. Sólo lo que se mide (SLI/SLO) se puede mejorar.
Just Culture. Postmortem sin cargos, enfoque en causas sistémicas.
Shift-left. Calidad, seguridad, pruebas y observabilidad son parte del ciclo de desarrollo.

3) Organización y funciones

El equipo SRE de la plataforma: herramientas compartidas, políticas, pipelines, GitOps, directorios de servicios.
SRE incorporados (embedded): trabajan cerca del equipo de productos, objetivos de colaboración en SLO.
Servicio (on-call): rotaciones, límites de carga, compensación, entrenamiento.
RACI: propietario del servicio, propietario de SLO, IC en incidentes, Comms Lead, Scribe.

4) SLI/SLO y presupuesto de errores (conjunto con el producto)

SLI: disponibilidad, latencia, éxito de las operaciones empresariales, relevancia de los datos.
SLO: objetivos en ventanas 28-30 días + excepciones.
Error Budget = 1 − SLO. Las políticas: lanzamientos, experimentos, canarios y fiches se rigen por la tasa real de burn.
Diseño por cohorte: regiones, proveedores, segmentos VIP - SLO individuales para no perder anomalías.

5) Observabilidad predeterminada

Métricas: éxito/error, percentili p50/p95/p99, saturación (CPU/amb/IO/conn).
Registros: estructurados, con correlación de solicitudes/lanzamientos/banderas.
Treking: tarjeta de latencia y error de extremo a extremo, hot-paths.
Sintética + RUM: muestras externas y telemetría real del cliente.
SLO dashboards: presupuesto de burn-down, anotaciones de lanzamiento, canario, proveedores.

6) Gestión de cambios y versiones

CI/CD de pipeline: conjuntos deterministas, firma de artefactos, escáneres de seguridad, pruebas de contratos.
Estrategias progresivas: canary/blue-green/shadow; banderas de ficha con ciclo de vida.
Gate's calidad: policy-as-code, SLO-guardrails, auto-retroceso en la degradación.
GitOps: configuraciones/políticas como código, promoción por miércoles, auditoría.

7) Incidentes y post mortem

Declaración sobre los niveles SEV/P, IC se asigna inmediatamente, liberación-libre en SEV-1 +.
Alertas Burn-rate: ventanas cortas y largas, quórum por regiones y tipos de muestras.
Playbucks: retrocesos, degradaciones, proveedores de Feilover, límites/retiros.
RCA y CAPA: factología, causalidad, acciones medibles, puntos de control (D + 14/D + 30).
Catálogo de conocimientos: volvamos a usar las plantillas y las lecciones.

8) Pruebas de confiabilidad

Pruebas contractuales y contratos de consumo para microservicios.
Perfiles de carga según patrones reales, prueba p99/pausa GC/cola de cola de cola.
Casos Chaos/Resilience: apagar dependencias, redes, retrasos; juegos-días y enseñanzas de DR.
Migraciones DB: expand→migrate→contract, reversibilidad, pruebas de compatibilidad de dos versiones.

9) Gestión de capacidad y costo (FinOps)

Capacity Units y headroom en rutas críticas.
HPA/VPA/KEDA por métricas personalizadas y registros de colas.
Multi-proveedores: cuotas, enrutamiento por SLO/latencia, auto-failover.
Unit-economics: $/1k solicitudes, $/transacción exitosa; optimización de cachés, registros, egresos.

10) Seguridad como parte de la confiabilidad

SAST/DAST/SCA, búsqueda de secretos, SBOM, firma de imágenes.
mTLS y políticas de acceso (OPA/ABAC); privilegios mínimos.
Rotación de claves/certificados, control de plazos, escenarios de prueba de caducidad.
Incidentes de seguridad - playbucks individuales, forenziques, notificaciones regulatorias.

11) Cultura y procesos

Revisiones de SLO: semanal/mensual, priorizando deudas sobre «púrpura púrpura».
Entrenamiento y simulaciones: entrenamientos on-call, ensayos de incidentes, días de chaos.
Normas uniformes: listas de comprobación de preparación para el prod, SLA de comunicaciones, formato post-mortem.
Indicadores de fatiga de alertas: ruido ≤ el umbral objetivo, afinación regular.

12) Métricas de madurez de la función SRE

DORA-métricas: frecuencia de deployes, tiempo de lectura, MTTR, cambio-tasa de falla.
Ejecución de SLO: proporción de servicios en la zona verde, tendencia burn-rate.
Higiene de alerta:% de las acciones de paginas, mediana de alertas/turno, proporción de falsas.
RCA/CAPA: cumplimiento a tiempo, proporción de razones sistémicas (no personales), reopen-rate.
Costo: $/SLO-ítem, $/1k consultas, eficiencia de la etiqueta automática.

13) Check-list «Preparación del servicio para el prod»

• SLI/SLO, propietario de SLO y ventana de vigilancia, están identificados.
• Las alertas de dashboards y burn-rate están personalizadas, hay sintética externa.
• Pipeline: firmas/escáneres, pruebas de contratación/integración, canario/banderas, auto-rollback.
• Las migraciones de DB son reversibles, los perfiles de carga cubren los picos.
• Playbucks de incidentes y contactos de proveedores; página de estado.
• Se ha confirmado el encabezado de la capacidad; HPA/KEDA y cuotas de proveedores verificados.
• Configuraciones y políticas - en Git, promoción por miércoles, auditoría incluida.
• Seguridad: secretos fuera de código, mTLS/rotación, tiempo TLS bajo control.

14) Anti-patrones

«99. 999% o nada" - objetivos inalcanzables → eterno burn-rate rojo.
Lanzamientos sin canarios y banderas fich → grandes explosiones.
Un punto de monitoreo → falsas alarmas y omisiones.
Los cambios manuales de las confecciones en la venta → la deriva y la inaudibilidad.
Los post mortems sin CAPA → incidentes recurrentes.
Los ERE como «bomberos» sin derecho a cambiar la arquitectura → la deuda no se cierra.

15) Hoja de ruta para la implementación de los ERE (ejemplo durante 3-6 meses)

1. Mes 1: inventario de servicios y rutas críticas; borradores SLI/SLO; dashboards básicos y alertas burn-rate; Inicio on-call.
2. Mes 2: Canarios/Banderas de fin de semana, giros automáticos; GitOps de las configuraciones; Catálogo de playbooks de incidentes; página de estado.
3. Mes 3: pruebas contractuales, perfiles de carga, migraciones de DB bajo el esquema expand/aprox; primeros días de juego.
4. Mes 4-6: rutas de múltiples proveedores, ejercicios de DR, optimización de costos, métricas de madurez, KPI para equipos.

16) Resultado

SRE es un sistema operativo de desarrollo: objetivos de calidad transparentes (SLO), velocidad de cambio controlada (presupuesto de errores), automatización y disciplina de incidentes, pruebas de sostenibilidad y costo consciente. Con este enfoque, los lanzamientos se convierten en una rutina y la fiabilidad en una ventaja competitiva.