Chaos Engineering: sostenibilidad de los sistemas

Chaos Engineering: sostenibilidad de los sistemas

1) Por qué la ingeniería del caos

• verificar las hipótesis sobre el comportamiento del sistema y validar el SLO;
• detectar SPOF ocultos, temporizadores/retraídos incorrectos, efectos en cascada;
• entrenar comandos: game-days, practicar runbook's, comunicaciones;
• formar una cultura de «sostenibilidad por defecto» en lugar de «esperar lo mejor».

Importante: Chaos Engineering ≠ «romper todo». Es un método científico: steady-state → hipótesis → experimento → conclusiones → mejoras.

2) Ciclo básico del experimento

1. Steady-state (línea base): ¿qué SLI son estables? (por ejemplo, el éxito ≤500 ms en 99. 95%).
2. Hipótesis: si se pierde una AZ, la p95 crecerá <10% y la disponibilidad ≥99. 9%.
3. Experimento: una falta planificada con criterios limitados de blast radius y stop.
4. Observación: métricas/tracks/logs, burn-rate SLO, SLI de negocios (por ejemplo, depósitos exitosos).
5. Mejoras: confirmamos los hallazgos, cambiamos los tiempos/límites/enrutamiento, actualizamos el runbook.
6. Automatización/retroceso: repetimos en la programación, agregamos a CI/CD y calendarios de juegos-días.

3) Barandilla de seguridad (primera seguridad)

Blast radius: empezamos con un solo pod/instans/route/namespace.
Guardrails: alertas en SLO burn-rate (rápido/lento), límites de retraídas, límite de QPS, presupuesto de incidentes.
Criterios stop: «si error-rate> X% o p99> Y ms N minutos - instantáneamente stop y rollback».
Ventanas: horas de trabajo on-call, stakeholder notificados, liberaciones congeladas.
Comunicación: IC/Tech lead/Comms, canal claro (War-room), plantilla de mensajes.

4) Clases de rechazo e ideas de hipótesis

Red: retardo/jitter/pérdida, drop parcial de los puertos, comunicación «flash» entre servicios/PSP.
Ordenadores/nodos: eliminación de procesos, sobrecalentamiento de CPU, agotamiento de descriptores de archivos, agrupaciones estrechas de conexiones.
Almacenamiento y DB: crecimiento de discos latency, réplicas de lag, parada de un solo shard/líder, split-brain.
Dependencias: degradación de APIs externas, límites de proveedores, ráfagas de 5xx/429.
Gestión de cambios: lanzamiento fallido, mala bandera de ficha, rollo parcial.
Perímetro: CDN degradado, DNS/Anycast a la deriva, fallo WAF/bot protection.
Región/AZ: pérdida total o incidente «parcial» (un poco peor e impredecible).

5) Herramientas y técnicas

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Nubes: AWS Fault Injection Simulator (FIS), Fault Domains en las nubes.
Red/proxy: Toxiproxy (TCP-veneno), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Procesos/nodos: 'stress-ng', cgroups/CPU-throttle, disk fill.
Enrutamiento de tráfico: GSLB/DNS weights, conmutación canaria/azul-verde para comprobaciones falsas.

6) Ejemplos de scripts (Kubernetes)

6. 1 Delay/abort en ruta (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Hipótesis: los timeouts/retrauches y CB cliente retendrán p95 <300 ms y error-rate <0. 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Hipótesis: el equilibrador y el HPA compensan las pérdidas de una sola instancia sin crecimiento de p99> 20%.

6. 3 Caos de la red (latencia al DB)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Hipótesis: los pools/timeouts/caché reducirán el impacto; p95 pagos permanecerán ≤ SLO.

6. 4 Relleno de disco

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

Hipótesis: la rotación de los registros/cuota/alerta funcionará antes de que las rutas se degraden.

7) Experimentos fuera de K8s

7. 1 Toxiproxy (local/integración)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Envoy HTTP fault (perímetro/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (idea de ejemplo)

Experimento de «matar» N% EC2 en Auto Scaling Group, levantar artificialmente EBS-latencia, desactivar NAT-GW en un solo AZ.
Criterios de parada incorporados en las métricas SLO de CloudWatch.

8) Métricas de la observabilidad durante el caos

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
Modelo rojo en rutas críticas (Tasa, Errores, Duración).
Grupos: espera la conexión p95, utilidad.
DB: lag réplicas, locks, derivación p95 consultas.
Red: retransmits, RTT, dscp/ecn comportamiento.
SLI de negocios: éxito de las transacciones (depósitos/cheque),% de reembolsos/errores.
Trace: tracks selectivos (exemplars), correlación de release-anotaciones.

9) Integración con SLO/Error-budget

Planificar experimentos dentro del presupuesto de errores: el caos no debe «arruinar» los objetivos trimestrales.
Burn-rate alertas como un kill-switch automático.
Informes: «cuánto presupuesto se quemó», «qué desviaciones steady-state».

10) Juegos-días (enseñanzas)

Escenario: leyenda breve (por ejemplo, «región-Este perdido»), pasos de inyección, objetivos de SLO, roles, tiempo.
Evaluación: RTO/RPO real, calidad de las comunicaciones, correcto runbook.
Retro: lista de mejoras con propietarios y plazos, actualización de documentación/dashboards.

11) Automatización y CI/CD

Smoke-chaos: pruebas cortas de staging en cada lanzamiento (por ejemplo, 1 pod-kill + 200 ms delay por ruta).
Nocturnos/semanales: escenarios más severos (5-15 min) con el informe.
Juegos promocionales: si p95/errores> umbral en canary - auto-retroceso.
Repositorios con catálogo de experimentación (YAML + runbook + SLO-thresholds).

12) Anti-patrones

«Romper la proda sin barandilla»: no hay criterios de stop, no hay on-call → el riesgo de un incidente real.
Una acción única en lugar de un proceso.
Caos sin steady-state: no está claro qué considerar éxito/fracaso.
Retraídas excesivas → auto-DDoS cuando se inyectan retrasos.
Ignorar SLI empresarial: avances «tecnológicos» en el fracaso de pagos/pedidos.
Falta de post-análisis y propietarios de mejoras.

13) Lista de verificación de implementación (0-45 días)

0-10 días

Definir SLI steady-state (personalizado + negocio).
Seleccionar herramienta (Chaos Mesh/Litmus/Toxiproxy/FIS).
Describir barandilla: blast radius, criterios stop, ventanas, roles.

11-25 días

Ejecutar los primeros experimentos: pod-kill, 100-200 ms delay en apstream crítico, drop 1% paquetes.
Configurar alertas burn-rate, asociar kill-switch a criterios stop.
Para pasar el primer día de juego, recoger retro y fixes.

26-45 días

Agregar scripts de nivel de AZ/dependencias (PSP externo, DAB-lag).
Automatizar el caos nightly en staging; preparar escenarios «estacionales» (picos).
Catálogo de experimentos e informes periódicos para guías/ERE.

14) Métricas de madurez

≥80% de las rutas críticas tienen los experimentos descritos y las métricas steady-state.
Auto kill-switch se activa cuando se superan los umbrales p99/error-rate.
Trimestral - juego-día de nivel AZ/región; ≥1 veces/mes es el escenario objetivo de las dependencias.
El MTTR disminuye después de un ciclo de mejoras, la correlación «liberación ↔ incidente» disminuye.
La proporción de caídas «inesperadas» con fallos reales → tiende a cero.
Los dashboards muestran «resiliencia» como KPI (burn-rate, tiempo de recuperación, proporción de acciones de DR exitosas).

15) Ejemplos de guardrails y disparadores stop

Stop cuando: 'http _ req _ failed> 1%' 3 minutos, 'p99> 1000 ms' 3 ventanas, 'deposits _ success <99. 5%`.
Reducción de blast radius: auto-retroceso del manifiesto, recuperación de pesos GSLB, desactivación de inyecciones fault.
Comando stop: un solo botón/script con lógica de causa.

16) Cultura y procesos

El caos forma parte del ritmo SRE, no del «extremo».
Informes transparentes, reconocimiento de vulnerabilidades, acciones correctivas.
Formación on-call, simulación de comunicaciones con clientes/socios.
Vinculación con el SLA/SLO y los presupuestos: el caos debe aumentar, no socavar, la fiabilidad.

17) Conclusión

Chaos Engineering convierte la «esperanza para los nueve» en una sostenibilidad demostrable. Formule steady-state, coloque barandillas, rompa pequeñas y controladas, observe SLO y SLI de negocios, fije y automatice las mejoras. Entonces, los fallos reales se convertirán en eventos manejables: RTO predecible, error-budget protegido y la disposición del equipo a actuar sin pánico.