Prompt para análisis de causa raíz de errores

Cuándo utilizarlo

Utilízalo cuando ocurra un fallo inesperado en producción y necesites un documento post-mortem estructurado y libre de culpas. Sustituye los detalles del incidente por tus propios registros, trazas de pila (stack traces) y telemetría antes de distribuirlo a los responsables de ingeniería.

El prompt

## Rol
Actúa como un staff reliability engineer. Aplica un criterio diagnóstico riguroso garantizando que las explicaciones técnicas sigan siendo claras tanto para los ingenieros como para los colaboradores de otras áreas.

## Contexto
KitePay, una plataforma de procesamiento de pagos digitales, experimentó una caída de 27 minutos en su clúster de API principal durante el procesamiento de pagos. La telemetría de errores mostró un incremento abrupto de HTTP 504 Gateway Timeouts tras el despliegue de la versión v2.14.0. El lanzamiento introdujo una búsqueda mediante clave foránea sin indexar en la tabla `merchant_settlements` durante la autorización de tokens, agotando el grupo de conexiones (connection pool) de PostgreSQL. La reversión (rollback) a la versión v2.13.9 solucionó los timeouts.

## Objetivo
Elaborar un análisis de causa raíz (RCA) completo que explique cómo el cambio de código desencadenó el agotamiento de conexiones a la base de datos, cómo se mitigó el fallo y cómo evitar que vuelva a ocurrir.

## Audiencia
Los lectores principales son ingenieros backend y directores de ingeniería. Proporciona el nivel de detalle arquitectónico necesario para justificar las tareas de remediación, evitando explicaciones teóricas innecesarias.

## Requisitos
Un documento RCA de entre 400 y 600 palabras que contenga: una tabla de resumen del incidente; un cronograma secuencial de detección, respuesta y resolución; un desglose técnico de la causa raíz mediante el método de los 5 Porqués; las remediaciones inmediatas aplicadas; y las acciones preventivas a largo plazo. Incluye recomendaciones explícitas sobre índices y consultas de base de datos.

## Restricciones
No inventes componentes de infraestructura no especificados, cifras arbitrarias de latencia, montos de compensación a clientes ni dependencias de servicios no verificadas. Limita las conclusiones técnicas al fallo suministrado sobre la base de datos y el pool de conexiones. Señala explícitamente cualquier factor especulativo como suposición no confirmada.

## Tono y estilo
Objetivo, constructivo (sin señalar culpables) y con precisión analítica. Emplea un lenguaje técnico directo, viñetas concisas y una jerarquía estructural clara. Evita expresiones defensivas, ambigüedades y promesas vagas.

## Formato de salida
Presenta primero el documento RCA con encabezados de markdown diferenciados. Organiza el cronograma y los responsables de remediación en tablas de markdown bien estructuradas. Concluye con una lista de verificación que detalle las alertas de telemetría y las políticas de revisión de código que deben auditarse.

## Qué evitar
Evita conclusiones superficiales como "error humano", afirmaciones sin justificar sobre disponibilidad continua y la omisión del mecanismo específico de consulta en base de datos que provocó el agotamiento del pool de conexiones.

## Criterios de éxito
Un responsable de ingeniería debe poder leer el documento y explicar el mecanismo exacto del fallo, verificar por qué el rollback restableció el servicio y asignar tareas preventivas concretas.

## Preguntas aclaratorias
Formula un máximo de tres preguntas específicas únicamente si falta información arquitectónica crítica. De lo contrario, procede con los datos del escenario, expón tus supuestos de trabajo y describe las comprobaciones de telemetría requeridas para confirmar la solución.

Por qué funciona

• El escenario proporciona al modelo un mecanismo de fallo técnico concreto, evitando que recurra a los tópicos habituales sobre caídas genéricas de servidores.
• Los requisitos exigen artefactos de ingeniería estandarizados, como el análisis de los 5 Porqués y un cronograma de remediación preciso.
• Las restricciones evitan que el modelo alucine fallos de infraestructura no relacionados o métricas inexistentes.
• Los criterios de éxito garantizan que el informe resultante sea inmediatamente revisable y procesable por parte de los responsables técnicos.

Adáptalo a tu caso

Crea una versión personalizada con PromptDeck sustituyendo el escenario ficticio por la telemetría, marcas de tiempo y arquitectura reales de tu propio incidente. Mantén la lista de comprobación de verificación para que las tareas preventivas de ingeniería se auditen adecuadamente.