Cómo construí un sistema de automatización que el equipo podía auditar sin depender de mí
El momento de claridad sobre el problema llegó cuando el director comercial me preguntó, con una mezcla de curiosidad y preocupación, qué pasaría con los flujos de automatización si yo no estuviera disponible durante 2 semanas. Era una pregunta legítima sobre la resiliencia del sistema que yo había construido. Mi respuesta honesta en ese momento era que varios de los flujos críticos dependían de configuraciones que solo yo entendía completamente, que la documentación era parcial y que si algo fallaba mientras yo no estaba, el equipo técnico necesitaría entre 4 y 8 horas para diagnosticar y corregir un problema que yo podría resolver en 30 minutos.
El problema no era de competencia del equipo técnico. Era de arquitectura del sistema: había construido la automatización de forma que funcionaba bien cuando yo la gestionaba y que era opaca para cualquier otra persona. Los flujos en Make tenían nombres que seguían mi lógica de nomenclatura personal. La documentación de cada flujo existía en mi mente con mayor detalle que en cualquier documento formal. Las dependencias entre flujos no estaban mapeadas en ningún lugar. Era el tipo de sistema donde el conocimiento de operación vivía en una persona y el sistema vivía en la infraestructura.
Dediqué 3 semanas a construir la capa de documentación y auditabilidad que el sistema necesitaba. Primero, un diagrama de arquitectura que mostraba todos los flujos activos, sus triggers, sus fuentes de datos y sus acciones, y las dependencias entre ellos. Segundo, una ficha técnica de una página para cada flujo con: descripción de qué hace y por qué existe, qué datos procesa, cómo falla y qué hacer cuando falla, y cómo verificar que está funcionando correctamente. Tercero, un dashboard de monitoreo en Make que mostraba en tiempo real el estado de cada flujo activo y que enviaba alertas cuando alguno fallaba.
Hice el test más importante cuando terminé: pedí al director de operaciones que no tenía experiencia en automatización que siguiera la documentación para diagnosticar un problema simulado en uno de los flujos. Lo logró en 28 minutos con la documentación disponible. Sin la documentación, habría necesitado llamarme. Ese test fue el criterio de éxito del proyecto de documentación: no que la documentación fuera técnicamente completa, sino que una persona competente pero sin experiencia en la plataforma específica pudiera operar el sistema en una situación de emergencia.
El sistema de automatización bien documentado y auditable no es solo más fácil de mantener. Es más fácil de mejorar porque cualquier miembro del equipo puede proponer mejoras con suficiente contexto sobre cómo funciona actualmente. Es más fácil de escalar porque los nuevos flujos que se agregan siguen una arquitectura coherente que todos entienden. Y es más robusto frente a la salida de cualquier persona porque el conocimiento de operación está en la documentación, no en la memoria de quien lo construyó. La automatización que vive en la cabeza de quien la construyó es un activo frágil. La que vive en la documentación del equipo es una ventaja duradera.