{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production","title":"Chaos Engineering en Producción: Hipótesis de Estado Estable, LitmusChaos y Control de Blast Radius","description":"LitmusChaos, Chaos Monkey, control de blast radius, y la hipótesis de estado estable, una guía técnica para romper cosas a propósito de manera controlada y productiva.","language":"es","datePublished":"2025-10-09","dateModified":null,"contentFormat":"text/markdown","content":"SRE\n\n# Chaos Engineering en Producción: Hipótesis de Estado Estable, LitmusChaos y Control de Blast Radius\n\n2025-10-098 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/chaos-engineering-litmus-chaos-monkey-production>)\n\n## La Hipótesis de Estado Estable\n\nTodo experimento de chaos comienza con una hipótesis. Una acción desestructurada como terminar un pod al azar sin expectativas medibles no es un experimento. Una hipótesis correctamente formulada tiene esta forma:\n\n**\"Cuando terminemos el 30% de los pods de API en el namespace de checkout, esperamos: la tasa de éxito de requests se mantiene arriba del 99.5%, la latencia p99 se queda debajo de 500ms, y el HPA de Kubernetes escala pods de reemplazo dentro de 60 segundos.\"**\n\nEsta es tu hipótesis de estado estable. Define:\n\n1. **La perturbación**, qué se está rompiendo\n2. **Las métricas de estado estable**, cómo se ve lo \"normal\"\n3. **La tolerancia**, cuánta desviación es aceptable\n\nAntes de correr nada, se necesita un baseline. Capturá al menos 30 minutos de métricas de estado estable bajo carga representativa:\n\n```bash\n# Capturar métricas baseline con Prometheus\ncat <<'PROMQL'\n# Tasa de éxito (debería ser >99.9% en baseline)\nsum(rate(http_requests_total{status=~\"2..\"}[5m]))\n/\nsum(rate(http_requests_total[5m]))\n\n# Latencia p99 (capturar valor baseline)\nhistogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))\n\n# Cantidad de pods (baseline para verificación de scaling)\ncount(kube_pod_status_phase{namespace=\"checkout\", phase=\"Running\"})\nPROMQL\n```\n\nRegistrá estos valores. Son tu snapshot del \"antes\". Si tus métricas de estado estable ya son inestables antes del experimento, arreglá eso primero. No es posible detectar degradación inducida por chaos si el baseline es ruidoso.\n\n## LitmusChaos: chaos nativo de Kubernetes\n\n[LitmusChaos](<https://litmuschaos.io/>) es el proyecto de chaos engineering del CNCF construido para [Kubernetes](<https://kubernetes.io/>). Usa CRDs para definir experimentos, lo que significa que tus experimentos de chaos son YAML versionado y revisable, igual que todo lo demás en tu cluster.\n\nInstalalo:\n\n```bash\nhelm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/\nhelm install litmus litmuschaos/litmus \\\n --namespace litmus --create-namespace \\\n --set portal.server.serviceType=ClusterIP\n```\n\nEste es un experimento representativo, eliminación de pods en el namespace de checkout con controles específicos de blast radius:\n\n```yaml\napiVersion: litmuschaos.io/v1alpha1\nkind: ChaosEngine\nmetadata:\n name: checkout-pod-kill\n namespace: checkout\nspec:\n engineState: active\n appinfo:\n appns: checkout\n applabel: app=checkout-api\n appkind: deployment\n chaosServiceAccount: litmus-admin\n experiments:\n - name: pod-delete\n spec:\n components:\n env:\n - name: TOTAL_CHAOS_DURATION\n value: \"120\"\n - name: CHAOS_INTERVAL\n value: \"30\"\n - name: PODS_AFFECTED_PERC\n value: \"30\"\n - name: FORCE\n value: \"false\"\n - name: SEQUENCE\n value: \"parallel\"\n probe:\n - name: success-rate-probe\n type: promProbe\n mode: Continuous\n runProperties:\n probeTimeout: 5s\n interval: 10s\n retry: 3\n promProbe/inputs:\n endpoint: http://prometheus:9090\n query: >\n sum(rate(http_requests_total{namespace=\"checkout\",status=~\"2..\"}[1m]))\n /\n sum(rate(http_requests_total{namespace=\"checkout\"}[1m]))\n comparator:\n type: float\n criteria: \">=\"\n value: \"0.995\"\n - name: latency-probe\n type: promProbe\n mode: Continuous\n runProperties:\n probeTimeout: 5s\n interval: 10s\n retry: 3\n promProbe/inputs:\n endpoint: http://prometheus:9090\n query: >\n histogram_quantile(0.99,\n sum(rate(http_request_duration_seconds_bucket{namespace=\"checkout\"}[1m]))\n by (le))\n comparator:\n type: float\n criteria: \"<=\"\n value: \"0.5\"\n```\n\nLos probes son la red de seguridad. Si la tasa de éxito baja del 99.5% o el p99 supera 500ms, LitmusChaos aborta el experimento y el chaos engine transiciona a estado ` stopped `. Esto es innegociable, nunca corras un experimento sin condiciones de abort.\n\n### Chaos de red: el verdadero asesino\n\nMatar pods es el \"hello world\" del chaos engineering. Los outages reales usualmente involucran particiones de red, fallas de DNS e inyección de latencia. LitmusChaos maneja estos también:\n\n```yaml\napiVersion: litmuschaos.io/v1alpha1\nkind: ChaosEngine\nmetadata:\n name: checkout-network-latency\n namespace: checkout\nspec:\n engineState: active\n appinfo:\n appns: checkout\n applabel: app=checkout-api\n appkind: deployment\n experiments:\n - name: pod-network-latency\n spec:\n components:\n env:\n - name: NETWORK_INTERFACE\n value: \"eth0\"\n - name: TARGET_CONTAINER\n value: \"checkout-api\"\n - name: NETWORK_LATENCY\n value: \"200\"\n - name: JITTER\n value: \"50\"\n - name: TOTAL_CHAOS_DURATION\n value: \"180\"\n - name: DESTINATION_IPS\n value: \"10.0.15.0/24\"\n```\n\nEste tipo de experimento comúnmente detecta bugs en la lógica de reintentos. Considerar backoff exponencial con un máximo de 3 reintentos, pero el timeout por intento era de 5 segundos. Agregale 200ms de latencia de red a cada llamada a la DB, y de repente cada reintento tarda 5.2 segundos. Tres reintentos = 15.6 segundos en total. El gateway HTTP tenía un timeout de 10 segundos. Cada intento de reintento después del segundo era trabajo tirado, el cliente ya había recibido un 504.\n\nLa solución fue simple: timeout por intento de 2 segundos, timeout total de 8 segundos, máximo 4 reintentos. Pero este tipo de problema rara vez se detecta sin inyectar latencia específicamente en el path de la base de datos.\n\n## Chaos Monkey y el linaje de Netflix\n\nChaos Monkey, la herramienta original de chaos de Netflix, opera diferente a LitmusChaos. Termina instancias al azar en tu entorno de [AWS](<https://aws.com/>). La filosofía es chaos continuo, corre constantemente, matando cosas al azar, y tus sistemas lo manejan o no.\n\nPara setups nativos de AWS, el Simian Army (la evolución de Chaos Monkey) se integra con Auto Scaling Groups:\n\n```python\nimport boto3\nimport random\nimport logging\n\nlogger = logging.getLogger('chaos-monkey')\n\ndef chaos_monkey_run(asg_name: str, kill_probability: float = 0.1):\n \"\"\"Mata una instancia random en el ASG con la probabilidad dada\"\"\"\n ec2 = boto3.client('ec2')\n asg = boto3.client('autoscaling')\n\n response = asg.describe_auto_scaling_groups(\n AutoScalingGroupNames=[asg_name]\n )\n instances = response['AutoScalingGroups'][0]['Instances']\n healthy = [i for i in instances if i['HealthStatus'] == 'Healthy']\n\n if len(healthy) <= 1:\n logger.warning(f\"Solo {len(healthy)} instancia(s) healthy en {asg_name}, salteando\")\n return\n\n if random.random() > kill_probability:\n logger.info(f\"Los dados dicen que hoy no hay chaos para {asg_name}\")\n return\n\n victim = random.choice(healthy)\n instance_id = victim['InstanceId']\n\n logger.info(f\"Terminando {instance_id} en {asg_name}\")\n ec2.terminate_instances(InstanceIds=[instance_id])\n\n return instance_id\n```\n\nLa salvaguarda clave: nunca matés si solo queda una instancia healthy. Y observar el parámetro de probabilidad, en producción, correr al 10% de probabilidad por ciclo es lo común. La mayoría de los ciclos no hacen nada. Pero en una semana, cada servicio recibe un golpe.\n\n## Metodología GameDay\n\nUn GameDay es una sesión estructurada de chaos donde todo el equipo participa. No es solo sobre el experimento técnico, es sobre observar cómo los humanos responden a las fallas.\n\nEste es un template probado:\n\n```markdown\n## Plan de GameDay: Failover de Base de Datos\n\n**Fecha**: 2026-01-09 14:00 UTC\n**Duración**: 90 minutos (60 min experimento + 30 min retro)\n**Facilitador**: Lucio\n**Participantes**: Equipo backend, SRE, ingeniero de guardia\n\n### Pre-condiciones\n- [ ] Todos los participantes informados del alcance del experimento\n- [ ] Dashboards abiertos: Grafana main, PagerDuty, Slack #incidents\n- [ ] Procedimiento de abort documentado y entendido\n- [ ] Soporte al cliente notificado (no detalles, solo \"estamos corriendo tests de resiliencia\")\n\n### Hipótesis de estado estable\nCuando la base de datos primaria (RDS Aurora) haga failover a la read replica:\n1. Las operaciones de escritura pausan por <10 segundos\n2. Las operaciones de lectura continúan sin interrupción\n3. La aplicación reconecta automáticamente dentro de 30 segundos\n4. No hay pérdida de datos\n5. La alerta de PagerDuty se dispara dentro de 2 minutos\n\n### Condiciones de abort\n- Error rate supera 20% por más de 60 segundos\n- Outage completo del servicio (0 requests exitosos)\n- Corrupción de datos detectada\n- Cualquier participante llama abort\n```\n\nLa retro es donde vive el valor real. Un GameDay típico puede revelar:\n\n1. El connection pool reconecta bien, pero mantiene conexiones stale por 45 segundos antes de health-checkearlas\n2. La alerta de PagerDuty no se dispara porque el intervalo de chequeo es de 5 minutos, ajustarlo a 30 segundos resuelve esto\n3. El ingeniero de guardia no sabe dónde está el runbook de failover de RDS, agregarlo al wiki de respuesta a incidentes cierra la brecha\n\nNada de esto habría salido a la superficie leyendo diagramas de arquitectura.\n\n## Control de blast radius: lo innegociable\n\nTodo experimento necesita límites de blast radius. Estos deben aplicarse en múltiples capas:\n\n**Nivel de infraestructura**: Etiquetá nodos y namespaces que son elegibles para chaos. Todo lo demás está fuera de límites.\n\n```bash\n# Solo estos nodos pueden ser target\nkubectl label nodes worker-{1..3} chaos-eligible=true\n\n# Opt-in a nivel de namespace\nkubectl annotate namespace checkout litmuschaos.io/chaos=true\n```\n\n**Nivel de experimento**: Tope en el porcentaje de recurse es afectados. Nunca pases del 50% para un primer experimento en cualquier target.\n\n**Nivel temporal**: Configurar duración máxima. Si el experimento excede su ventana, se auto-revierte.\n\n**Nivel de métricas**: Probes que auto-abortan cuando los budgets de SLO están amenazados.\n\n**Nivel organizacional**: Aprobación de change management para experimentos en producción. Un proceso liviano de RFC funciona bien, un thread en Slack en #chaos-proposals con el YAML del experimento adjunto y dos aprobaciones de SRE requeridas.\n\n## Construyendo el hábito\n\nChaos engineering no es una herramienta, es una práctica. La herramienta es la parte fácil. Lo difícil es hacerlo un hábito. Esto es lo que funciona:\n\n1. **Slot semanal de chaos**: Todos los jueves a las 14:00 UTC, corre un experimento. Está en el calendario del equipo. Innegociable.\n2. **Scoreboard de chaos**: Trackeá experimentos corridos, issues encontrados, mejoras en MTTR. Hacelo visible.\n3. **Pipeline de incidente a experimento**: Después de cada incidente, preguntá \"¿qué experimento de chaos habría catcheado esto?\" Agregalo al backlog.\n4. **Complejidad graduada**: Iniciar con pod kills. Graduá a chaos de red. Después fallas multi-AZ. Después failovers regionales. Cada nivel requiere éxito demostrado en el nivel anterior.\n\nUn experimento de failover de base de datos como el descrito arriba puede llevar a un fix del connection pool que prevenga múltiples outages potenciales durante el año siguiente. Cada uno sería un incidente p1 afectando a miles de usuarios. Cuarenta y siete segundos de disrupción durante un experimento controlado es una lección extraordinariamente barata comparada con la alternativa.\n\n## Preguntas frecuentes\n\n### ¿Es seguro hacer chaos engineering en producción?\n\nSí, cuando se hace bien. La clave es el control de blast radius, comenzar con un alcance reducido (un solo pod, un solo nodo), definir condiciones de abort, y disponer de mecanismos de rollback. La mayoría de las organizaciones maduras corren experimentos de chaos continuamente en producción.\n\n### ¿Cuál es la diferencia entre chaos engineering y testing?\n\nTesting verifica que condiciones conocidas producen resultados esperados. Chaos engineering explora modos de falla desconocidos introduciendo turbulencia real en sistemas de producción. Testing dice '¿esto funciona?' Chaos engineering dice '¿qué pasa cuando esto se rompe?'\n\n### ¿Cómo consigo buy-in para chaos engineering?\n\nIniciar con un GameDay apuntando a una debilidad conocida. Cuando el experimento revela un problema concreto que podría haber causado un outage, el valor se vuelve auto-evidente. Enmarcalo como 'respuesta proactiva a incidentes' en vez de 'romper cosas.'\n\n## Tips\n\n1. **Tip:** El primer experimento de chaos debería apuntar a algo con un 90% de probabilidad de sobrevivir. Se recomienda construir confianza organizacional antes de probar lo desconocido, un primer experimento fallido puede terminar con el programa entero.\n2. **Tip:** Se recomienda definir siempre las ` condiciones de abort ` antes de comenzar. Es importante documentarlas. Si la latencia p99 supera 2x el baseline O el error rate supera 5%, el experimento se frena automáticamente. Nada de heroísmos.\n3. **Tip:** Los experimentos deben ejecutarse en horario laboral, no a las 2 AM. El punto es testear tu sistema bajo carga real con gente disponible para observar. Las corridas de fin de semana producen falsa confianza.\n4. **Tip:** Se recomienda utilizar ` kubectl label nodes chaos-eligible=true ` para restringir el blast radius de LitmusChaos. No se debe permitir que un experimento apunte a nodos que no se hayan incluido explícitamente.\n\n- chaos-engineering\n- litmus-chaos\n- chaos-monkey\n- gameday\n- sre\n- reliability\n- kubernetes\n- blast-radius\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Chaos Engineering en Producción: Hipótesis de Estado Estable, LitmusChaos y Control de Blast Radius","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#title"},{"level":2,"text":"La Hipótesis de Estado Estable","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#la-hiptesis-de-estado-estable"},{"level":2,"text":"LitmusChaos: chaos nativo de Kubernetes","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#litmuschaos-chaos-nativo-de-kubernetes"},{"level":3,"text":"Chaos de red: el verdadero asesino","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#chaos-de-red-el-verdadero-asesino"},{"level":2,"text":"Chaos Monkey y el linaje de Netflix","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#chaos-monkey-y-el-linaje-de-netflix"},{"level":2,"text":"Metodología GameDay","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#metodologa-gameday"},{"level":2,"text":"Control de blast radius: lo innegociable","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#control-de-blast-radius-lo-innegociable"},{"level":2,"text":"Construyendo el hábito","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#construyendo-el-hbito"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#questions"},{"level":3,"text":"¿Es seguro hacer chaos engineering en producción?","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#question-1"},{"level":3,"text":"¿Cuál es la diferencia entre chaos engineering y testing?","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#question-2"},{"level":3,"text":"¿Cómo consigo buy-in para chaos engineering?","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#article-tips"}],"sections":[{"heading":"Chaos Engineering en Producción: Hipótesis de Estado Estable, LitmusChaos y Control de Blast Radius","level":1,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production","content":"SRE"},{"heading":"Chaos Engineering en Producción: Hipótesis de Estado Estable, LitmusChaos y Control de Blast Radius","level":1,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#title","content":"2025-10-098 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/chaos-engineering-litmus-chaos-monkey-production>)"},{"heading":"La Hipótesis de Estado Estable","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#la-hiptesis-de-estado-estable","content":"Todo experimento de chaos comienza con una hipótesis. Una acción desestructurada como terminar un pod al azar sin expectativas medibles no es un experimento. Una hipótesis correctamente formulada tiene esta forma:\n\n**\"Cuando terminemos el 30% de los pods de API en el namespace de checkout, esperamos: la tasa de éxito de requests se mantiene arriba del 99.5%, la latencia p99 se queda debajo de 500ms, y el HPA de Kubernetes escala pods de reemplazo dentro de 60 segundos.\"**\n\nEsta es tu hipótesis de estado estable. Define:\n\n1. **La perturbación**, qué se está rompiendo\n2. **Las métricas de estado estable**, cómo se ve lo \"normal\"\n3. **La tolerancia**, cuánta desviación es aceptable\n\nAntes de correr nada, se necesita un baseline. Capturá al menos 30 minutos de métricas de estado estable bajo carga representativa:\n\n```bash\n# Capturar métricas baseline con Prometheus\ncat <<'PROMQL'\n# Tasa de éxito (debería ser >99.9% en baseline)\nsum(rate(http_requests_total{status=~\"2..\"}[5m]))\n/\nsum(rate(http_requests_total[5m]))\n\n# Latencia p99 (capturar valor baseline)\nhistogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))\n\n# Cantidad de pods (baseline para verificación de scaling)\ncount(kube_pod_status_phase{namespace=\"checkout\", phase=\"Running\"})\nPROMQL\n```\n\nRegistrá estos valores. Son tu snapshot del \"antes\". Si tus métricas de estado estable ya son inestables antes del experimento, arreglá eso primero. No es posible detectar degradación inducida por chaos si el baseline es ruidoso."},{"heading":"LitmusChaos: chaos nativo de Kubernetes","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#litmuschaos-chaos-nativo-de-kubernetes","content":"[LitmusChaos](<https://litmuschaos.io/>) es el proyecto de chaos engineering del CNCF construido para [Kubernetes](<https://kubernetes.io/>). Usa CRDs para definir experimentos, lo que significa que tus experimentos de chaos son YAML versionado y revisable, igual que todo lo demás en tu cluster.\n\nInstalalo:\n\n```bash\nhelm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/\nhelm install litmus litmuschaos/litmus \\\n --namespace litmus --create-namespace \\\n --set portal.server.serviceType=ClusterIP\n```\n\nEste es un experimento representativo, eliminación de pods en el namespace de checkout con controles específicos de blast radius:\n\n```yaml\napiVersion: litmuschaos.io/v1alpha1\nkind: ChaosEngine\nmetadata:\n name: checkout-pod-kill\n namespace: checkout\nspec:\n engineState: active\n appinfo:\n appns: checkout\n applabel: app=checkout-api\n appkind: deployment\n chaosServiceAccount: litmus-admin\n experiments:\n - name: pod-delete\n spec:\n components:\n env:\n - name: TOTAL_CHAOS_DURATION\n value: \"120\"\n - name: CHAOS_INTERVAL\n value: \"30\"\n - name: PODS_AFFECTED_PERC\n value: \"30\"\n - name: FORCE\n value: \"false\"\n - name: SEQUENCE\n value: \"parallel\"\n probe:\n - name: success-rate-probe\n type: promProbe\n mode: Continuous\n runProperties:\n probeTimeout: 5s\n interval: 10s\n retry: 3\n promProbe/inputs:\n endpoint: http://prometheus:9090\n query: >\n sum(rate(http_requests_total{namespace=\"checkout\",status=~\"2..\"}[1m]))\n /\n sum(rate(http_requests_total{namespace=\"checkout\"}[1m]))\n comparator:\n type: float\n criteria: \">=\"\n value: \"0.995\"\n - name: latency-probe\n type: promProbe\n mode: Continuous\n runProperties:\n probeTimeout: 5s\n interval: 10s\n retry: 3\n promProbe/inputs:\n endpoint: http://prometheus:9090\n query: >\n histogram_quantile(0.99,\n sum(rate(http_request_duration_seconds_bucket{namespace=\"checkout\"}[1m]))\n by (le))\n comparator:\n type: float\n criteria: \"<=\"\n value: \"0.5\"\n```\n\nLos probes son la red de seguridad. Si la tasa de éxito baja del 99.5% o el p99 supera 500ms, LitmusChaos aborta el experimento y el chaos engine transiciona a estado ` stopped `. Esto es innegociable, nunca corras un experimento sin condiciones de abort."},{"heading":"Chaos de red: el verdadero asesino","level":3,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#chaos-de-red-el-verdadero-asesino","content":"Matar pods es el \"hello world\" del chaos engineering. Los outages reales usualmente involucran particiones de red, fallas de DNS e inyección de latencia. LitmusChaos maneja estos también:\n\n```yaml\napiVersion: litmuschaos.io/v1alpha1\nkind: ChaosEngine\nmetadata:\n name: checkout-network-latency\n namespace: checkout\nspec:\n engineState: active\n appinfo:\n appns: checkout\n applabel: app=checkout-api\n appkind: deployment\n experiments:\n - name: pod-network-latency\n spec:\n components:\n env:\n - name: NETWORK_INTERFACE\n value: \"eth0\"\n - name: TARGET_CONTAINER\n value: \"checkout-api\"\n - name: NETWORK_LATENCY\n value: \"200\"\n - name: JITTER\n value: \"50\"\n - name: TOTAL_CHAOS_DURATION\n value: \"180\"\n - name: DESTINATION_IPS\n value: \"10.0.15.0/24\"\n```\n\nEste tipo de experimento comúnmente detecta bugs en la lógica de reintentos. Considerar backoff exponencial con un máximo de 3 reintentos, pero el timeout por intento era de 5 segundos. Agregale 200ms de latencia de red a cada llamada a la DB, y de repente cada reintento tarda 5.2 segundos. Tres reintentos = 15.6 segundos en total. El gateway HTTP tenía un timeout de 10 segundos. Cada intento de reintento después del segundo era trabajo tirado, el cliente ya había recibido un 504.\n\nLa solución fue simple: timeout por intento de 2 segundos, timeout total de 8 segundos, máximo 4 reintentos. Pero este tipo de problema rara vez se detecta sin inyectar latencia específicamente en el path de la base de datos."},{"heading":"Chaos Monkey y el linaje de Netflix","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#chaos-monkey-y-el-linaje-de-netflix","content":"Chaos Monkey, la herramienta original de chaos de Netflix, opera diferente a LitmusChaos. Termina instancias al azar en tu entorno de [AWS](<https://aws.com/>). La filosofía es chaos continuo, corre constantemente, matando cosas al azar, y tus sistemas lo manejan o no.\n\nPara setups nativos de AWS, el Simian Army (la evolución de Chaos Monkey) se integra con Auto Scaling Groups:\n\n```python\nimport boto3\nimport random\nimport logging\n\nlogger = logging.getLogger('chaos-monkey')\n\ndef chaos_monkey_run(asg_name: str, kill_probability: float = 0.1):\n \"\"\"Mata una instancia random en el ASG con la probabilidad dada\"\"\"\n ec2 = boto3.client('ec2')\n asg = boto3.client('autoscaling')\n\n response = asg.describe_auto_scaling_groups(\n AutoScalingGroupNames=[asg_name]\n )\n instances = response['AutoScalingGroups'][0]['Instances']\n healthy = [i for i in instances if i['HealthStatus'] == 'Healthy']\n\n if len(healthy) <= 1:\n logger.warning(f\"Solo {len(healthy)} instancia(s) healthy en {asg_name}, salteando\")\n return\n\n if random.random() > kill_probability:\n logger.info(f\"Los dados dicen que hoy no hay chaos para {asg_name}\")\n return\n\n victim = random.choice(healthy)\n instance_id = victim['InstanceId']\n\n logger.info(f\"Terminando {instance_id} en {asg_name}\")\n ec2.terminate_instances(InstanceIds=[instance_id])\n\n return instance_id\n```\n\nLa salvaguarda clave: nunca matés si solo queda una instancia healthy. Y observar el parámetro de probabilidad, en producción, correr al 10% de probabilidad por ciclo es lo común. La mayoría de los ciclos no hacen nada. Pero en una semana, cada servicio recibe un golpe."},{"heading":"Metodología GameDay","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#metodologa-gameday","content":"Un GameDay es una sesión estructurada de chaos donde todo el equipo participa. No es solo sobre el experimento técnico, es sobre observar cómo los humanos responden a las fallas.\n\nEste es un template probado:\n\n```markdown\n## Plan de GameDay: Failover de Base de Datos\n\n**Fecha**: 2026-01-09 14:00 UTC\n**Duración**: 90 minutos (60 min experimento + 30 min retro)\n**Facilitador**: Lucio\n**Participantes**: Equipo backend, SRE, ingeniero de guardia\n\n### Pre-condiciones\n- [ ] Todos los participantes informados del alcance del experimento\n- [ ] Dashboards abiertos: Grafana main, PagerDuty, Slack #incidents\n- [ ] Procedimiento de abort documentado y entendido\n- [ ] Soporte al cliente notificado (no detalles, solo \"estamos corriendo tests de resiliencia\")\n\n### Hipótesis de estado estable\nCuando la base de datos primaria (RDS Aurora) haga failover a la read replica:\n1. Las operaciones de escritura pausan por <10 segundos\n2. Las operaciones de lectura continúan sin interrupción\n3. La aplicación reconecta automáticamente dentro de 30 segundos\n4. No hay pérdida de datos\n5. La alerta de PagerDuty se dispara dentro de 2 minutos\n\n### Condiciones de abort\n- Error rate supera 20% por más de 60 segundos\n- Outage completo del servicio (0 requests exitosos)\n- Corrupción de datos detectada\n- Cualquier participante llama abort\n```\n\nLa retro es donde vive el valor real. Un GameDay típico puede revelar:\n\n1. El connection pool reconecta bien, pero mantiene conexiones stale por 45 segundos antes de health-checkearlas\n2. La alerta de PagerDuty no se dispara porque el intervalo de chequeo es de 5 minutos, ajustarlo a 30 segundos resuelve esto\n3. El ingeniero de guardia no sabe dónde está el runbook de failover de RDS, agregarlo al wiki de respuesta a incidentes cierra la brecha\n\nNada de esto habría salido a la superficie leyendo diagramas de arquitectura."},{"heading":"Control de blast radius: lo innegociable","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#control-de-blast-radius-lo-innegociable","content":"Todo experimento necesita límites de blast radius. Estos deben aplicarse en múltiples capas:\n\n**Nivel de infraestructura**: Etiquetá nodos y namespaces que son elegibles para chaos. Todo lo demás está fuera de límites.\n\n```bash\n# Solo estos nodos pueden ser target\nkubectl label nodes worker-{1..3} chaos-eligible=true\n\n# Opt-in a nivel de namespace\nkubectl annotate namespace checkout litmuschaos.io/chaos=true\n```\n\n**Nivel de experimento**: Tope en el porcentaje de recurse es afectados. Nunca pases del 50% para un primer experimento en cualquier target.\n\n**Nivel temporal**: Configurar duración máxima. Si el experimento excede su ventana, se auto-revierte.\n\n**Nivel de métricas**: Probes que auto-abortan cuando los budgets de SLO están amenazados.\n\n**Nivel organizacional**: Aprobación de change management para experimentos en producción. Un proceso liviano de RFC funciona bien, un thread en Slack en #chaos-proposals con el YAML del experimento adjunto y dos aprobaciones de SRE requeridas."},{"heading":"Construyendo el hábito","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#construyendo-el-hbito","content":"Chaos engineering no es una herramienta, es una práctica. La herramienta es la parte fácil. Lo difícil es hacerlo un hábito. Esto es lo que funciona:\n\n1. **Slot semanal de chaos**: Todos los jueves a las 14:00 UTC, corre un experimento. Está en el calendario del equipo. Innegociable.\n2. **Scoreboard de chaos**: Trackeá experimentos corridos, issues encontrados, mejoras en MTTR. Hacelo visible.\n3. **Pipeline de incidente a experimento**: Después de cada incidente, preguntá \"¿qué experimento de chaos habría catcheado esto?\" Agregalo al backlog.\n4. **Complejidad graduada**: Iniciar con pod kills. Graduá a chaos de red. Después fallas multi-AZ. Después failovers regionales. Cada nivel requiere éxito demostrado en el nivel anterior.\n\nUn experimento de failover de base de datos como el descrito arriba puede llevar a un fix del connection pool que prevenga múltiples outages potenciales durante el año siguiente. Cada uno sería un incidente p1 afectando a miles de usuarios. Cuarenta y siete segundos de disrupción durante un experimento controlado es una lección extraordinariamente barata comparada con la alternativa."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#questions","content":""},{"heading":"¿Es seguro hacer chaos engineering en producción?","level":3,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#question-1","content":"Sí, cuando se hace bien. La clave es el control de blast radius, comenzar con un alcance reducido (un solo pod, un solo nodo), definir condiciones de abort, y disponer de mecanismos de rollback. La mayoría de las organizaciones maduras corren experimentos de chaos continuamente en producción."},{"heading":"¿Cuál es la diferencia entre chaos engineering y testing?","level":3,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#question-2","content":"Testing verifica que condiciones conocidas producen resultados esperados. Chaos engineering explora modos de falla desconocidos introduciendo turbulencia real en sistemas de producción. Testing dice '¿esto funciona?' Chaos engineering dice '¿qué pasa cuando esto se rompe?'"},{"heading":"¿Cómo consigo buy-in para chaos engineering?","level":3,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#question-3","content":"Iniciar con un GameDay apuntando a una debilidad conocida. Cuando el experimento revela un problema concreto que podría haber causado un outage, el valor se vuelve auto-evidente. Enmarcalo como 'respuesta proactiva a incidentes' en vez de 'romper cosas.'"},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#article-tips","content":"1. **Tip:** El primer experimento de chaos debería apuntar a algo con un 90% de probabilidad de sobrevivir. Se recomienda construir confianza organizacional antes de probar lo desconocido, un primer experimento fallido puede terminar con el programa entero.\n2. **Tip:** Se recomienda definir siempre las ` condiciones de abort ` antes de comenzar. Es importante documentarlas. Si la latencia p99 supera 2x el baseline O el error rate supera 5%, el experimento se frena automáticamente. Nada de heroísmos.\n3. **Tip:** Los experimentos deben ejecutarse en horario laboral, no a las 2 AM. El punto es testear tu sistema bajo carga real con gente disponible para observar. Las corridas de fin de semana producen falsa confianza.\n4. **Tip:** Se recomienda utilizar ` kubectl label nodes chaos-eligible=true ` para restringir el blast radius de LitmusChaos. No se debe permitir que un experimento apunte a nodos que no se hayan incluido explícitamente.\n\n- chaos-engineering\n- litmus-chaos\n- chaos-monkey\n- gameday\n- sre\n- reliability\n- kubernetes\n- blast-radius\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/chaos-engineering-litmus-chaos-monkey-production"},{"text":"LitmusChaos","url":"https://litmuschaos.io/"},{"text":"Kubernetes","url":"https://kubernetes.io/"},{"text":"AWS","url":"https://aws.com/"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production"},"headline":"Chaos Engineering en Producción: Hipótesis de Estado Estable, LitmusChaos y Control de Blast Radius","description":"LitmusChaos, Chaos Monkey, control de blast radius, y la hipótesis de estado estable, una guía técnica para romper cosas a propósito de manera controlada y productiva.","datePublished":"2025-10-09","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://statics.lucioduran.com/images/lucioduran-social-card.jpg","url":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"SRE","keywords":"chaos-engineering, litmus-chaos, chaos-monkey, gameday, sre, reliability, kubernetes, blast-radius","wordCount":1472,"timeRequired":"PT8M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/chaos-engineering-litmus-chaos-monkey-production"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Chaos Engineering en Producción: Hipótesis de Estado Estable, LitmusChaos y Control de Blast Radius","item":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Es seguro hacer chaos engineering en producción?","acceptedAnswer":{"@type":"Answer","text":"Sí, cuando se hace bien. La clave es el control de blast radius, comenzar con un alcance reducido (un solo pod, un solo nodo), definir condiciones de abort, y disponer de mecanismos de rollback. La mayoría de las organizaciones maduras corren experimentos de chaos continuamente en producción."}},{"@type":"Question","name":"¿Cuál es la diferencia entre chaos engineering y testing?","acceptedAnswer":{"@type":"Answer","text":"Testing verifica que condiciones conocidas producen resultados esperados. Chaos engineering explora modos de falla desconocidos introduciendo turbulencia real en sistemas de producción. Testing dice '¿esto funciona?' Chaos engineering dice '¿qué pasa cuando esto se rompe?'"}},{"@type":"Question","name":"¿Cómo consigo buy-in para chaos engineering?","acceptedAnswer":{"@type":"Answer","text":"Iniciar con un GameDay apuntando a una debilidad conocida. Cuando el experimento revela un problema concreto que podría haber causado un outage, el valor se vuelve auto-evidente. Enmarcalo como 'respuesta proactiva a incidentes' en vez de 'romper cosas.'"}}]}]}],"contentHash":"60e3d5177c7a19ab2789428600413227f496c73311a759a2dca0d1d093769ef8","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/chaos-engineering-litmus-chaos-monkey-production","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":67123,"contentBytes":13527}}