Hay una conversación que ocurre en casi todos los equipos de Cloud Operations, y casi nunca ocurre en una reunión formal.
Ocurre en el pasillo, en un mensaje directo, o en el hilo de Slack donde alguien pregunta algo y otra persona responde de memoria:
"Oye, ¿Cómo se llama la convención de nombres que usamos para los buckets en staging?"
"Creo que era ambiente-equipo-servicio… o era equipo-ambiente-servicio. Pregúntale a "Fulano" que él lo definió."
""Fulano" ya no está en el equipo."
"Ah. Entonces revisa el documento en la wiki."
"Lo revisé. Tiene dos versiones distintas y ninguna tiene fecha."
Bienvenido al problema que nadie agenda en el sprint pero todos viven en el día a día.
1. Las políticas nacen como documentos — y tiene todo el sentido
Cuando un equipo define cómo va a operar su infraestructura, lo natural es escribirlo. Una wiki, un repositorio de documentación, un PDF en una carpeta compartida. La herramienta no importa — el acto de escribirlo sí.
En ese momento, el documento es verdad. Refleja decisiones reales tomadas por personas que entendían el contexto. Es útil, es consultado, es mantenido.
El problema no es el documento. El problema es lo que pasa después.
2. La infra evoluciona. El repositorio también. El documento, no siempre.
La nube no es estática. Los proveedores deprecan servicios, cambian nombres de recursos, agregan opciones que antes no existían y eliminan otras que ya no tienen sentido. Lo que era la forma correcta de hacer algo hace dieciocho meses puede ser hoy la forma incorrecta, la forma cara, o simplemente la forma que ya no funciona.
El código de IaC lo siente primero. Un módulo de Terraform que funcionaba perfectamente empieza a lanzar warnings de deprecación. Un recurso que se creaba con un bloque específico ahora requiere una configuración diferente. El proveedor cambió su API y el provider de Terraform lo refleja en la siguiente versión.
El equipo actualiza el código. Abre un PR, lo revisa, lo mergea. La infra sigue funcionando.
Pero el documento que describía cómo funciona ese módulo — la wiki que explica la arquitectura, el runbook que detalla los pasos — ese no tiene un pipeline de CI/CD que lo valide. No tiene tests. No tiene nadie asignado como responsable de mantenerlo sincronizado con la realidad.
Y así, en silencio, sin que nadie lo decida explícitamente, el documento empieza a describir una infra que ya no existe.
3. El día a día no deja espacio para verificar
Aquí es donde hay que ser honestos.
Todos sabemos que deberíamos revisar periódicamente si la documentación sigue siendo válida. Todos sabemos que deberíamos tener una tarea recurrente en el backlog que diga "auditar documentación de infraestructura" o algo similar.
Pero también todos sabemos lo que pasa con esa tarea.
En el mejor caso, existe en algún tablero, tiene una etiqueta de "deuda técnica", y lleva meses sin que nadie la toque porque siempre hay algo más urgente. En el peor caso, nunca se creó porque en el momento en que alguien iba a crearla llegó una alerta, un cliente, un deploy urgente, o simplemente el fin del día.
El problema no es falta de disciplina. Es que verificar documentación no tiene una alerta asociada. Nadie recibe un PagerDuty a las 3am porque el runbook de recuperación de base de datos tiene pasos que ya no aplican. Ese problema solo aparece cuando alguien necesita ejecutar ese runbook en una situación de estrés alto — que es exactamente el peor momento para descubrir que está desactualizado.
El día a día en Cloud Operations es reactivo por naturaleza. Las tareas de mantenimiento preventivo de documentación compiten con incidentes reales, y los incidentes siempre ganan.
4. El chisme del pasillo se vuelve la palabra de Dios
Y entonces ocurre algo que todos hemos vivido pero pocos escriben: el conocimiento operacional migra de los documentos a las personas.
No como una decisión. Como una consecuencia natural de que preguntar es más rápido que leer, y leer es más rápido que verificar si lo que dice el documento sigue siendo verdad.
"¿Cuánto tiempo tarda en propagarse un cambio de DNS en este ambiente?"
La respuesta no está en ningún documento actualizado. Está en la cabeza de alguien que lo midió hace seis meses y lo recuerda con relativa precisión.
"¿Qué pasa si el job de backup falla silenciosamente?"
Hay un runbook. Pero la persona que lo escribió ya no está, y quien lo está ejecutando prefiere preguntarle al colega que "sabe de eso" antes que leer cuatro páginas que pueden o no reflejar la configuración actual.
El problema con esta dinámica no es que sea ineficiente — a veces es la forma más rápida de resolver algo. El problema es que el conocimiento que vive en personas se va con las personas. Y cuando la persona que "sabe de eso" cambia de proyecto, toma vacaciones, o simplemente no está disponible a las 2am de un domingo, el equipo opera sobre supuestos que nadie puede validar.
5. A veces la respuesta es parar y empezar de nuevo
Hay una conclusión que la industria tarda en aceptar porque suena a derrota, pero que los equipos con experiencia real reconocen como madurez:
A veces el documento no se puede actualizar. A veces hay que escribir uno nuevo.
No como admisión de fracaso. Como reconocimiento de que la realidad cambió tanto que el documento existente genera más confusión que claridad — y más cuando las lecciones aprendidas son de momento — porque mezcla lo que era verdad con lo que es verdad ahora, y ya no es fácil distinguir entre ambos.
Un punto y aparte. Una nueva documentación que parte de lo que realmente existe hoy, no de lo que existía cuando alguien tuvo tiempo de escribir por última vez.
Y más importante que eso: una conversación honesta sobre dónde debería vivir esa documentación para que no vuelva a quedar obsoleta sin que nadie lo note.
La respuesta que más me ha convencido después de años en Cloud Operations no es una wiki mejor, ni un proceso de revisión más estricto, ni más disciplina de equipo.
Es mover la gobernanza del documento al sistema.
Las políticas que viven en código — que se validan en cada deploy, que el mismo sistema que despliega infraestructura ejecuta antes de actuar — no pueden quedar desactualizadas en silencio. Si la política cambia, el código cambia. Si el código cambia, hay un PR, hay una revisión, hay un registro.
El runbook que nadie lee no falla silenciosamente. La política que vive en el pipeline falla ruidosamente, en el momento correcto, antes de que el daño ocurra.
Eso no resuelve todo. La documentación narrativa — el contexto, el razonamiento detrás de las decisiones, la historia de por qué las cosas son como son — sigue siendo necesaria y sigue siendo humana.
Pero las reglas operacionales, los guardrails, las convenciones que determinan qué está permitido y qué no: esas merecen vivir donde el sistema pueda ejecutarlas, no donde alguien tenga que recordar leerlas.
En el siguiente post voy a mostrar cómo se ve eso en la práctica — qué significa exactamente mover una política de un documento a un sistema, y qué cambia cuando lo haces.
Si esto resonó con algo que has vivido en tu equipo, cuéntalo en los comentarios. Estas anécdotas son más comunes de lo que aparecen en las conferencias.
Top comments (0)