1. Chaos Engineering y Resiliencia

Principios y prácticas de Chaos Engineering para construir sistemas resilientes.

1.1 💥 Principios de Chaos Engineering

1.1.1 Qué es Chaos Engineering

Definición: Disciplina de experimentar en sistemas distribuidos para construir confianza en su capacidad de resistir condiciones turbulentas.

Principios:

Hipótesis sobre steady state: Definir qué es "normal"
Variar eventos del mundo real: Simular fallos realistas
Ejecutar experimentos en producción: Donde importa
Automatizar experimentos: Ejecutar continuamente
Minimizar blast radius: Empezar pequeño, escalar gradualmente

1.1.2 Proceso

1. Define Steady State
   ↓
2. Hypothesize
   ↓
3. Run Experiment
   ↓
4. Verify Hypothesis
   ↓
5. Learn & Improve

1.2 🔧 Inyección de Fallos

1.2.1 Tipos de Fallos

Tipo	Descripción	Herramienta
Network latency	Agregar delay a requests	Toxiproxy, Chaos Mesh
Service failure	Matar pods/servicios	Chaos Monkey, Chaos Mesh
Resource exhaustion	CPU/memory/disk al 100%	Gremlin, Chaos Toolkit
DNS failure	Resolver DNS falla	Chaos Mesh
Clock skew	Desincronizar relojes	Chaos Mesh

1.2.2 Ejemplo: Network Latency con Toxiproxy

# Instalar Toxiproxy
docker run -d -p 8474:8474 -p 808010:808010 shopify/toxiproxy

# Crear proxy para DB
toxiproxy-cli create database -l localhost:8001 -u postgres:5432

# Agregar latency de 1000ms
toxiproxy-cli toxic add database -t latency -a latency=1000

# Remover latency
toxiproxy-cli toxic remove database -n latency_downstream

1.2.3 Ejemplo: Chaos Mesh (Kubernetes)

# Matar pods aleatoriamente
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-example
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment-service
  scheduler:
    cron: "@every 10m"

# Network delay
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - production
    labelSelectors:
      app: api-gateway
  delay:
    latency: "500ms"
    correlation: "50"
    jitter: "100ms"
  duration: "5m"

1.3 🎮 Game Days

1.3.1 Qué es un Game Day

Definición: Simulación de incidente para entrenar equipos en respuesta.

Objetivos:

Validar runbooks
Entrenar on-call
Identificar gaps en monitoring/alerting
Mejorar comunicación

1.3.2 Planificación

# Game Day Plan: Database Outage

**Date:** YYYY-MM-DD
**Duration:** 2 hours
**Participants:** On-call SRE, Tech Lead, PM

## Scenario
Simular outage de base de datos principal.

## Hypothesis
- Equipo detecta outage en <5 min
- Failover a replica en <15 min
- Sistema recuperado en <30 min

## Execution
1. **T+0**: Inyectar fallo (matar DB pod)
2. **T+0-5**: Equipo detecta via alertas
3. **T+5-15**: Equipo ejecuta runbook de failover
4. **T+30**: Verificar que sistema está estable

## Success Criteria
- [ ] Alerta recibida en <5 min
- [ ] Failover ejecutado en <15 min
- [ ] 0 data loss
- [ ] Runbook seguido correctamente

## Rollback Plan
Si experimento causa impacto real:
1. Detener inyección de fallo
2. Restaurar DB desde backup
3. Comunicar a stakeholders

1.4 🛡️ Patrones de Resiliencia

1.4.1 Circuit Breaker

Qué hace: Detecta cuando servicio está fallando y deja de llamarlo temporalmente.

Estados:

Closed: Normal, requests pasan
Open: Servicio fallando, requests fallan inmediatamente
Half-Open: Probar si servicio se recuperó

Ejemplo (Python):

from pybreaker import CircuitBreaker

# Configurar circuit breaker
breaker = CircuitBreaker(
    fail_max=5,  # Abrir después de 5 fallos
    timeout_duration=60  # Intentar cerrar después de 60s
)

@breaker
def call_payment_service(amount):
    response = requests.post('https://payment-api.com/charge', json={'amount': amount})
    response.raise_for_status()
    return response.json()

# Usar
try:
    result = call_payment_service(100)
except CircuitBreakerError:
    # Circuit está abierto, servicio está down
    return {"error": "Payment service unavailable"}

1.4.2 Retry with Backoff

Qué hace: Reintentar requests fallidos con delay exponencial.

Ejemplo:

import time
from functools import wraps

def retry_with_backoff(max_retries=3, base_delay=1):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(max_retries):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    if attempt == max_retries - 1:
                        raise
                    delay = base_delay * (2 ** attempt)  # Exponential backoff
                    time.sleep(delay)
        return wrapper
    return decorator

@retry_with_backoff(max_retries=3, base_delay=1)
def call_api():
    response = requests.get('https://api.example.com/data')
    response.raise_for_status()
    return response.json()

1.4.3 Bulkhead

Qué hace: Aislar recursos para que fallo en un área no afecte otras.

Ejemplo (Thread Pools):

from concurrent.futures import ThreadPoolExecutor

# Pool separado para cada servicio
payment_pool = ThreadPoolExecutor(max_workers=10)
notification_pool = ThreadPoolExecutor(max_workers=5)

# Si payment service se satura, notification sigue funcionando
payment_pool.submit(process_payment, order_id)
notification_pool.submit(send_email, user_id)

1.4.4 Timeout

Qué hace: Limitar tiempo de espera para evitar bloqueos indefinidos.