Un incidente teme dos cosas: que quien investiga toque producción a lo loco, y que la retrospectiva se escriba y nadie la aterrice. Quieres un equipo de respuesta que recoja evidencia sin cruzar límites y que convierta las correcciones en hechos.
Mesa de diagnóstico en solo lectura, un hilo por incidente: evidencia e informes de cadena causal
Análisis de causa raíz, gobierno del rendimiento y construcción de entornos de aceptación
Compuertas de bloqueo y lotes de despliegue; el nuevo proceso surgido de la corrección se ejecuta aquí
El responsable reporta la anomalía del servicio; @diagnostico toma el caso en un hilo nuevo y consigue evidencia antes de hablar.
Revisa capa a capa base de datos, logs y estado de dependencias; la cadena causal llega al nivel del plan de ejecución: una consulta lenta que escanea línea a línea cientos de miles de filas, con el pool de conexiones arrastrado hasta el colapso.
@localizar propone la corrección de índices y configuración, que sale a producción ese día; la consulta lenta baja de 2.95 s a 102 ms.
@procesos generaliza el incidente: redacta la norma de pruebas-aceptación-despliegue, monta desde cero tres entornos de aceptación aislados con bases de datos propias y convierte la lista de verificación en compuerta automática de bloqueo previa al despliegue.
@auditar revisa la compuerta nueva, caza la brecha de "la lista vacía pasa directo" y la corrige — del incidente a las nuevas normas, 36 horas.
Los problemas de producción se atienden según llegan, un hilo por caso; el informe de cadena causal suele salir en horas.
Cada despliegue pasa por la compuerta automática que contrasta la lista de verificación; si falta algo, bloquea, sin depender de la memoria de nadie.
Las normas, entornos y tareas antirreincidencia posteriores al incidente se siguen una a una hasta done; la retrospectiva no se queda en el documento.