Todo equipo de ingeniería tiene el mismo ritual post-incidente. El incidente ocurre. Alguien escribe un resumen rápido en Slack. Alguien más promete actualizar el runbook. Se programa un post-mortem. Dos semanas después, el runbook aún no se ha actualizado, el documento de post-mortem está a medio terminar, y la próxima vez que ocurre el mismo incidente, el ingeniero de guardia vuelve a resolverlo desde cero.
El problema no es la pereza. Es que escribir documentación después de un incidente estresante es lo último que alguien quiere hacer, y compite con el trabajo de funcionalidades del siguiente sprint. La deuda de documentación se acumula hasta que los runbooks están tan desactualizados que nadie confía en ellos.
El workflow de Incident Response
El paquete de inicio de Ingeniería incluye un workflow llamado Incident Response. Toma los datos crudos del incidente — cronología, síntomas, acciones tomadas, causa raíz — y produce tres outputs en una sola pasada.
-
Informe de Incidente — Un informe post-incidente estructurado con: resumen del incidente, cronología de eventos, evaluación de impacto (usuarios afectados, duración, severidad), análisis de causa raíz, factores contribuyentes y acciones inmediatas tomadas. El formato es consistente entre incidentes, lo que hace posible el reconocimiento de patrones a lo largo de meses de informes.
-
Actualización de Runbook — La IA toma los detalles del incidente y genera adiciones o actualizaciones al runbook relevante. Si el incidente reveló un nuevo modo de fallo, escribe pasos de detección, comandos de diagnóstico y procedimientos de remediación. Si es un modo de fallo conocido con una variante nueva, actualiza la sección existente. El output está estructurado como contenido listo para runbook, no un resumen narrativo.
-
Revisión del Líder de Ingeniería (Puerta de Aprobación) — Antes de publicar nada, el workflow se pausa para revisión. El líder de ingeniería verifica la precisión de la cronología, valida el análisis de causa raíz y aprueba las adiciones al runbook. Esta puerta es crítica — los runbooks generados por IA necesitan un humano que estuvo ahí para confirmar que los procedimientos son correctos.
-
Generación de Post-Mortem — Después de la aprobación, la IA genera un documento completo de post-mortem: qué pasó, por qué pasó, qué impidió una resolución más rápida, y elementos de acción para prevenir la recurrencia. Cada elemento de acción tiene un responsable sugerido y prioridad.
Por qué importa la consistencia en los documentos de incidentes
Cuando los informes de incidentes siguen diferentes formatos, no puede compararlos. No puede preguntar “¿cuántos incidentes P1 este trimestre fueron causados por problemas de base de datos?” a menos que cada informe use la misma escala de severidad y categorización. No puede rastrear si los tiempos de remediación están mejorando a menos que cada informe incluya los mismos campos de temporización.
La recipe de Incident Report aplica un esquema consistente. Cada informe tiene las mismas secciones, las mismas categorías de severidad, los mismos campos de temporización. Con el tiempo, esto se convierte en un conjunto de datos estructurado que puede consultar, no solo una carpeta de documentos.
Qué sigue haciendo el ingeniero
El workflow necesita input preciso. El ingeniero proporciona:
- Qué pasó — Cronología de eventos, síntomas observados, alertas disparadas
- Qué hizo — Pasos de diagnóstico tomados, comandos ejecutados, correcciones aplicadas
- Qué lo causó — Causa raíz y factores contribuyentes
La IA no investiga el incidente — lo documenta. La investigación, la depuración, la corrección — esa es la experiencia del ingeniero. El trabajo de la IA es convertir esa experiencia en documentación bien estructurada que el próximo ingeniero de guardia pueda realmente usar.
Las actualizaciones de runbook son particularmente valiosas aquí. Un ingeniero que acaba de pasar dos horas depurando un problema de producción sabe exactamente qué pasos seguir la próxima vez. Normalmente ese conocimiento se queda en su cabeza o en un hilo de Slack. El workflow lo captura en una sección de runbook con comandos específicos y puntos de decisión.
El workflow de Feature Launch
El paquete de Ingeniería también incluye un workflow de Feature Launch que maneja la otra brecha de documentación: las comunicaciones de lanzamiento.
- Escribir entradas de changelog a partir del historial de commits y descripciones de PR
- Generar notas de lanzamiento orientadas al usuario con el nivel de detalle correcto
- Actualizar la documentación de API si los endpoints cambiaron
- Empaquetar todo para revisión
Y el workflow de Sprint Cycle automatiza la documentación de planificación y retrospectiva: generar objetivos de sprint a partir de elementos del backlog, crear planes de documentación para nuevas funcionalidades y estructurar notas de retrospectiva en mejoras accionables.
El paquete completo de Ingeniería
El paquete de inicio de Ingeniería incluye dos workflows adicionales junto con Incident Response:
- Feature Launch — Notas de lanzamiento, changelog y actualizaciones de documentación en una sola pasada
- Sprint Cycle — Automatización de planificación, documentación y retrospectiva
Las recipes independientes — tech spec writer, API documentation generator, code review feedback, architecture decision records — funcionan individualmente o como bloques de construcción para workflows de ingeniería personalizados.