Avito conectó un LLM con pruebas de caos y elevó la cobertura de incidentes del 22% al 41%

El incidente terminó, el equipo redactó el análisis y creó las tareas correspondientes; un trimestre después, sufrió un fallo casi idéntico. Es una historia conocida: las funcionalidades de producto se imponen constantemente a la deuda técnica y las conclusiones de los post-mortem acaban convirtiéndose poco a poco en un archivo.

Avito intentó cerrar esta brecha. Los fallos pasados se convirtieron en una fuente de escenarios para pruebas de caos y el LLM, en un filtro que ayuda a procesar cientos de informes. El modelo estudió 977 LSR, evaluó qué fallos podían reproducirse y propuso anomalías adecuadas. Después, un ingeniero comprueba si la prueba realmente reproduce la causa raíz en lugar de limitarse a crear una imagen parecida en los gráficos.

Del informe de un incidente a la validación en producción

El pipeline enriquecía el texto del LSR con los mensajes del chat asociado y después planteaba al modelo seis preguntas independientes. El modelo describía brevemente la causa y el síntoma, evaluaba la viabilidad de una prueba de caos, comprobaba qué había ocurrido con los Action Items, puntuaba el escenario de 0 a 10 y seleccionaba anomalías de una biblioteca interna. Los resultados se almacenaban en MongoDB, mientras que en Elasticsearch se creaba un índice vectorial para buscar incidentes similares.

Así, Avito obtuvo 432 conclusiones actualizadas automáticamente para 408 servicios. Según la estimación del modelo, el 41% de los fallos analizados podía reproducirse con herramientas existentes o previstas. Con LitmusChaos por sí solo, que opera principalmente en el nivel de los pods, la cifra rondaba el 22%. El orquestador de dominio Kratos casi duplicó la cobertura potencial gracias a escenarios para bases de datos y redes.

Un ejemplo sencillo es la conmutación por error del master de Redis. Una prueba convencional puede finalizar un proceso o eliminar un pod, pero no equivale a una reelección real del primary dentro de un replica set. Por eso, el equipo añadió el escenario trigger-primary-re-election para MongoDB y Redis. Se utiliza en el 95,6% de las ejecuciones automáticas: los servicios se prueban con una conmutación real del master, no con una imitación aproximada.

Donde se equivoca el LLM

Una puntuación alta del modelo todavía no implica que la prueba sea útil. En un caso, el fallo se debió a una configuración incorrecta de Nginx tras corregir una vulnerabilidad. El LLM otorgó al escenario una puntuación de 10 sobre 10 y propuso introducir latencia de red. Los síntomas sí eran similares: errores HTTP, timeouts y documentos no disponibles. Sin embargo, la prueba de caos no podía modificar la configuración de un sistema de terceros y, por tanto, nunca habría reproducido la causa raíz.

Esta es una limitación importante. El modelo clasifica bien un gran conjunto de informes y señala al ingeniero dónde buscar, pero puede confundir la causa con el efecto. Avito no le cede la decisión final: una persona verifica la hipótesis, el radio de impacto y la seguridad de la ejecución. El propio pipeline de análisis está suspendido actualmente tras el cierre del servicio interno que alojaba el modelo anterior, aunque se han conservado el dataset acumulado y la metodología.

Que puede aplicar en su propia organización

El punto de partida no debería ser la compra de una plataforma de caos, sino un mapa de fallos reales. Divídalos en recursos, red, procesos, capa de aplicación, infraestructura externa y lógica de negocio. Después, asocie cada clase con una causa raíz verificable, una ventana segura y un criterio de recuperación medible.

Aquí, un LLM resulta útil como capa de búsqueda sobre los post-mortem: encuentra causas recurrentes, agrupa incidentes y propone candidatos para automatización. Pero una prueba solo debe añadirse cuando reproduce el mecanismo del fallo. De lo contrario, el equipo obtendrá un informe en verde, un calendario de ejecuciones y una peligrosa falsa sensación de seguridad.