Lo que dice el papel y lo que dice producción
Quien hereda un sistema suele recibir algo de documentación: un diagrama, unas notas, quizá un documento de diseño de hace años. Lo que casi nunca recibe es la parte que importa: las tareas programadas que nadie recuerda, las dependencias entre sistemas que no aparecen en ningún dibujo, los accesos que se dieron "temporalmente" y siguen ahí.
Cambiar algo sin conocer esa parte es la forma más rápida de provocar un incidente.
La parte sumergida
Lo que suele aparecer al hacer un levantamiento:
- Tareas programadas que mueven datos o limpian tablas cada noche.
- Dependencias implícitas: un servicio que llama a otro por una dirección escrita en una configuración.
- Accesos y credenciales sin dueño ni caducidad.
- Recursos huérfanos que siguen costando dinero.
- Configuraciones hechas a mano que no están en ningún código.
Cómo se hace
- Inventario desde la fuente real, no desde la documentación: las APIs del proveedor, la configuración de red, los registros de acceso y la facturación dicen lo que existe.
- Mapa de dependencias: quién habla con quién, observando el tráfico y la configuración, no preguntando.
- Comparación con lo documentado: cada diferencia se anota. Es la lista más valiosa del ejercicio.
- Lista de bloqueos, con tamaño: qué impide cambiar o migrar cada parte, y cuánto esfuerzo supone resolverlo.
- Documento vivo: el resultado se deja como documentación como código, para que el levantamiento no haya que repetirlo.
Lo que no hay que hacer durante el levantamiento
Arreglar cosas. Es tentador, pero cada cambio durante el levantamiento mueve el terreno que se está midiendo. Primero se entiende todo; después se decide qué tocar, en qué orden y con qué riesgo.
Cómo lo aplicamos: Arquitectura Cloud.