Mapa de dependencias: en dos horas descubrir qué realmente puede hundir el negocio

En la mayoría de las empresas, el esquema de la infraestructura existe en dos versiones. La primera —presentacional y bonita: clústeres, réplicas, balanceadores, flechas entre ellos. La segunda —la real, en la cabeza de un ingeniero— y es notablemente más compleja.

El problema de ambas es que describen la técnica, no el negocio. Se ve dónde están los servidores, pero no se ve qué detiene realmente las ventas. Y la falla que paraliza las ventas casi nunca parece dramática en el diagrama: no es un clúster caído, sino un certificado caducado, un servicio externo inaccesible o una cuenta a la que se perdió el acceso.

Un mapa de dependencias es una forma de ver el sistema con los ojos del negocio. Se dibuja en una única sesión de dos horas y casi siempre revela dos o tres puntos de falla de los que en la empresa no se había pensado.

A quién llamar

Solo ingenieros no bastan, y ese es el principal error. Los ingenieros saben cómo está construida la sistema; no siempre saben qué pasa con el dinero cuando falla.

Reúne a cuatro personas: un especialista técnico, un representante de soporte, alguien de ventas u operaciones y la persona que toma decisiones presupuestarias. El soporte es invaluable: es quien primero sabe qué se rompió y recuerda todas las averías pasadas con detalles que no aparecen en ningún informe. Ventas sabe qué fallos los clientes perdonan y cuáles no.

Dos horas y una pizarra son suficientes. La herramienta es secundaria: sirve una pizarra online, y para la primera vez —una hoja de papel.

Cómo dibujar: siguiendo la ruta de la solicitud

No empieces por enumerar servidores —así obtendrás un inventario, no un mapa. Ve por la ruta del cliente, de arriba abajo, preguntando en cada paso “¿y luego qué?”.

1. Punto de entrada. ¿Dónde está registrado el dominio y a nombre de quién? ¿En qué proveedor se gestionan los registros DNS? ¿Quién puede cambiarlos físicamente a las tres de la madrugada?

2. Transporte. ¿Cómo llega la solicitud a tu infraestructura? ¿Hay una red de entrega de contenido, protección contra ataques, quién emite y renueva los certificados TLS?

3. Punto de recepción. ¿Qué balanceador o servidor web recibe la solicitud? ¿Es uno o hay varios?

4. Aplicación. ¿Qué servicios procesan la solicitud? ¿Dónde está la estática —en el disco local del servidor o en un almacenamiento de objetos?

5. Datos. ¿Dónde está la base de datos, la caché, las colas? Si la caché no está disponible, ¿la aplicación funciona más lento o deja de funcionar por completo?

6. Servicios externos. Pasarela de pagos, envío de mensajes, CRM, servicio de mensajería, servicio cartográfico, servicio de autorización. Cada llamada hacia fuera es infraestructura ajena sobre la que no tienes control.

7. Sistemas de soporte. Monitorización, copias de seguridad, sistema de despliegue, almacén de contraseñas. Su fallo no es visible de inmediato para el cliente, pero te deja sin posibilidad de reaccionar.

Segundo mapa: dependencias administrativas

El mapa técnico no es suficiente. Dibuja en paralelo un segundo mapa —más corto y más desagradable. En él no hay servidores, sino permisos, cuentas y credenciales:

• A nombre de quién está registrado el dominio y a qué correo llegan las notificaciones de renovación.
• Qué tarjeta bancaria está vinculada a la cuenta del proveedor en la nube y cuándo caduca.
• Quién es el propietario de la organización en el panel del proveedor —es decir, quién puede ser el único en restaurar el acceso a los demás.
• Dónde se almacenan claves y contraseñas y qué ocurriría si ese servicio no estuviera disponible.
• A qué teléfono llega el segundo factor para cuentas críticas.
• Quién recibe las notificaciones de caducidad de certificados TLS y licencias.

Este mapa suele resultar más peligroso que el técnico. Un servidor se repara en una hora, pero recuperar el control de un dominio registrado a nombre de un empleado que se marchó puede llevar semanas —y durante todo ese tiempo no se puede hacer nada.

Ejercicio «marca en rojo»

Cuando ambos mapas estén dibujados, haz una pregunta por cada nodo: ¿qué pasará con el negocio si este elemento desaparece justo ahora?

Marca en rojo aquello cuyo fallo detendría de inmediato la entrada de ingresos. En amarillo —lo que empeora el funcionamiento pero permite continuar. En verde —lo que, si falta, nadie notará desde fuera durante un día.

Discutid en voz alta. Las discrepancias en las valoraciones son lo más valioso que aporta esta revisión: cuando el ingeniero está seguro de que un servicio es secundario, y el soporte sabe que si falla en una hora llegan cuarenta incidencias, has encontrado no un problema técnico, sino una brecha en la comprensión del sistema.

Lo que suele aparecer casi siempre

Dominio y correo a nombre de un empleado que ya no trabaja. El dominio está registrado con la dirección personal de alguien que se fue hace dos años y las notificaciones de renovación van a ninguna parte. Mientras todo funciona, pasa desapercibido. El día de la avería se descubre que no hay nadie que pueda cambiar un registro DNS.

Llamada síncrona a un servicio externo sin límite de tiempo. Al tramitar un pedido, la aplicación llama a un CRM externo y espera la respuesta. Normalmente la respuesta tarda 100 milisegundos. El día en que el CRM tiene problemas y responde en 30 segundos, todos los manejadores libres de tu aplicación quedan ocupados esperando —y el sitio deja de responder por completo, aunque tu infraestructura esté totalmente operativa. Se soluciona limitando el tiempo de espera, desactivando llamadas no imprescindibles durante su degradación y pasando todo lo que pueda posponerse a procesamiento asíncrono.

La caché como punto de fallo inadvertido. Las sesiones de usuarios están en Redis para escalar, pero Redis se ejecuta en una sola instancia. Su fallo significa que nadie puede iniciar sesión, aunque la base de datos funcione correctamente.

Un único canal de notificaciones. La monitorización envía alertas al mensajero corporativo que está desplegado en la misma infraestructura que el producto. En una gran avería no recibirás notificaciones sobre ella.

Un certificado que nadie renueva. La renovación automática está configurada, pero un día falla, y se entera uno el mismo día en que los navegadores empiezan a mostrar advertencias de conexión insegura.

Qué hacer a continuación

El mapa no es un fin en sí mismo. Sirve para tomar tres decisiones.

Primero: eliminar lo que se arregla barato. Transferir el dominio a la empresa, añadir un segundo canal de notificaciones, poner límite de tiempo a las llamadas externas, asignar un propietario a cada cuenta crítica. Son días de trabajo, no presupuestos, y eliminan la mitad de los riesgos encontrados.

Segundo: definir prioridades de redundancia. No todo lo rojo debe redundarse igual —primero se calcula el coste del fallo. Sobre esto hay un análisis aparte: criticidad de componentes.

Tercero: dejar de considerar el mapa como una acción puntual. Queda obsoleto en un trimestre: aparecen integraciones, cambian proveedores, se van personas. Un ritmo razonable es revisarlo cada trimestre y siempre después de cada cambio importante en la arquitectura. Quince minutos suelen bastar para verificarlo si el mapa ya existe.

Empieza con tres componentes en una hoja de papel. Un mapa incompleto dibujado hoy es más útil que un esquema exhaustivo que se hará algún día.

La capa externa del mapa —dominio, DNS, correo, certificados— se comprueba automáticamente en un par de minutos. Lo demás lo revisamos juntos si necesitas una mirada externa.