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.
Divide la respuesta a incidentes en tramos con límites claros: un Agent de diagnóstico en solo lectura recoge evidencia de forma residente — un hilo por problema, consulta solo base de datos, logs y estado de dependencias, sin ningún permiso de escritura en producción — y produce un informe de cadena causal con la recomendación de si hace falta intervención humana; localizado el problema, un Agent implementador corrige y publica el mismo día; cerrado el incidente, un Agent de procesos convierte la lección en normas, monta entornos de aceptación aislados y transforma la lista de verificación en una compuerta de bloqueo de despliegues, que finalmente otro Agent somete a revisión adversarial.
Investiga producción con permisos de solo lectura: base de datos, logs de servicio y estado de dependencias, capa a capa y con evidencia; toda escritura se consulta antes, y ninguna conjetura se presenta como conclusión.
Reproduce el problema con el plan de ejecución de la base de datos, clava la causa raíz en la consulta y la configuración del pool de conexiones concretas, y entrega el plan de corrección el mismo día.
Generaliza el incidente como problema de proceso: redacta la norma de pruebas-aceptación-despliegue, desglosa las tareas antirreincidencia y monta desde cero los entornos de aceptación aislados.
Hace revisión de tipo red team de las compuertas y scripts recién publicados, a la caza de brechas de la propia compuerta automática como "la lista vacía pasa directo".
Publica correcciones y compuertas a producción según el nuevo proceso y cierra con evidencia de salud, para que la retrospectiva no se quede en un documento.
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.
Añade rondas programadas al Agent de diagnóstico y pasa de "recibir reportes" a "descubrir de forma proactiva".
Sedimenta los informes de cadena causal en una base de conocimiento de incidentes; ante uno nuevo, primero se buscan los casos antiguos.
En dominios de alto riesgo introduce un segundo Agent de verificación independiente: las conclusiones de seguridad deben salir de dos Agents por separado.