Detectar riesgos de caídas en la nube antes de que ocurran

A quién le sirve. Equipos técnicos que publican software o gestionan servidores en la nube y quieren detectar riesgos antes de una actualización, aunque el caso es un proyecto de concurso con pocos datos de prueba.

Qué hicieron

SHIPCHECK es un agente ReAct (que razona y actúa por turnos) conectado a un Sanity Content Lake mediante MCP. Ante una actualización propuesta, llama a cuatro herramientas para consultar el estado de los componentes, las restricciones de versión, las dependencias del clúster y un grafo de conocimiento. Sigue dependencias de dos saltos con GROQ y resuelve documentos contradictorios con una puntuación de autoridad de 1 a 10. Sanity contenía 18 registros de prueba.

Cómo salió

Para la actualización del servicio de pagos de la v2 a la v4, dio 13 pasos y descubrió que el Payment SDK v2.4.1 del clúster estaba por debajo de la v3.0.0 exigida. Respondió «NO PUBLICAR TODAVÍA», y una corrección simulada del SDK cambió el veredicto a seguro.

Conviene saber

Los datos son un conjunto pequeño de 18 registros de prueba, y la afirmación de que las alucinaciones bajaron de cerca del 30 % al 0 % se da sin ningún método de evaluación.

Qué necesitas

• Una exportación de registros y métricas de tu sistema, incluidos los periodos de caídas pasadas
• Un agente de programación, como Claude Code o Codex
• Un lugar donde ejecutar el programa que te prepare el agente, como tu ordenador
• Alguien con conocimientos de sistemas que valide lo que detecte

Cómo hacerlo tú, paso a paso

1. Reúne los registros y las métricas y marca cuándo hubo caídas pasadas.
2. Pide al agente que busque patrones que precedieron a esas caídas, como errores crecientes, procesador saturado o certificados a punto de caducar.
3. Pídele un script, que es un programa corto, que compruebe esas señales en los datos actuales y devuelva una lista de riesgos ordenada, con la evidencia de cada uno.
4. Ejecútalo con datos de ejemplo.
5. Revisa que cada riesgo tiene una evidencia que puedas comprobar.
6. Para ir más lejos, reúne en un solo sitio el estado de tus componentes, versiones y dependencias, y haz que el agente consulte ese sitio antes de cada actualización.

Con la exportación de registros y métricas de [ruta], busca patrones que precedieron a caídas pasadas, como errores crecientes, procesador saturado o certificados a punto de caducar. Escribe un script que compruebe en los datos actuales esas señales y devuelva una lista de riesgos ordenada, con la evidencia de cada uno. Habrás terminado cuando se ejecute con mis datos de ejemplo. No cambies nada de la infraestructura.

Consejos

• El agente solo debe leer datos. Nunca le des permiso para cambiar la infraestructura.
• El caso usa solo 18 registros de prueba. No lo tomes como prueba de fiabilidad.
• Exige la evidencia de cada riesgo. Una lista sin pruebas no sirve.

Preguntas frecuentes

Fuentes

• @rajan_mishra_a9f78ad216b4 en DEV ↗

En el directorio desde el 3 de octubre de 2026.