Hay un ejercicio incómodo que recomiendo a cualquiera que lidere tecnología, aunque casi nadie lo hace hasta que es tarde: sentarse, en frío, sin la presión de un incidente, y tratar de escribir la lista completa de cosas de las que depende que mi sistema siga funcionando mañana a la mañana. No la lista que está en el diagrama de arquitectura, esa la conocemos todos. La otra. La de verdad. La que incluye ese servicio que nadie recuerda haber configurado, esa cuenta que creó alguien que ya no trabaja acá, ese certificado que se renueva solo —¿se renueva solo?—, esa integración con un proveedor que nunca nos dio problemas y que justamente por eso dejamos de mirar. Cada vez que hice ese ejercicio, o que acompañé a un equipo a hacerlo, aparecieron cosas que nos dejaron incómodos. Y esa incomodidad, créanme, es mucho más barata cuando llega un martes cualquiera por elección propia que cuando llega un sábado a las tres de la mañana, sin avisar, en forma de caída.
Una idea que dejé picando hace unos meses#
Hace unos meses, escribiendo sobre la caída global asociada a CrowdStrike, mencioné al pasar una idea que se me quedó dando vueltas y que merece un post entero: la de las dependencias invisibles. Dije ahí que toda organización tiene dependencias visibles, esas que cualquiera reconoce, y otras invisibles, que son las peligrosas porque solo aparecen cuando fallan. Lo dejé planteado en un párrafo y seguí con otros temas. Pero la idea no me soltó, y con los meses me convencí de que ahí, en esa distinción aparentemente obvia, está una de las claves menos atendidas de la resiliencia tecnológica.
Porque cuando hablamos de resiliencia solemos saltar directo a las soluciones: redundancia, backups, multi-región, planes de contingencia, monitoreo. Todo eso es importante, no lo discuto. Pero hay un paso anterior, mucho más humilde y mucho menos glamoroso, que casi siempre nos salteamos: saber de qué dependemos. Y resulta que ese paso, que parece trivial, es el más difícil de todos. No porque sea técnicamente complejo, sino porque exige una honestidad que la operación diaria no nos deja tener. Estamos tan ocupados haciendo funcionar las cosas que rara vez nos detenemos a preguntar qué, exactamente, las hace funcionar.
El diagrama miente, y no por mala intención#
Si le pedimos a casi cualquier equipo el diagrama de arquitectura de su sistema, nos van a mostrar algo razonable: la aplicación, la base de datos, el balanceador, la nube donde corre todo, quizás un par de servicios externos, el sistema de pagos, el de correo. Es un buen punto de partida. El problema es que ese diagrama describe el sistema como nos gustaría que fuera, o como era cuando alguien se sentó a dibujarlo, no como es hoy de verdad.
Porque los sistemas reales no se quedan quietos. Crecen, se parchan, se integran con cosas nuevas, acumulan workarounds. Cada vez que alguien resolvió un problema rápido un viernes a la tarde, cada vez que se sumó una herramienta para tapar un agujero, cada vez que se conectó un servicio nuevo “provisoriamente”, se agregó una dependencia que probablemente no llegó al diagrama. Y así, con el tiempo, la distancia entre el diagrama y la realidad se vuelve enorme. El diagrama muestra diez cajas; el sistema real depende de cuarenta cosas, y treinta de ellas no están dibujadas en ningún lado. No es mala intención ni negligencia: es la entropía natural de cualquier sistema que vive y se usa. Pero esa distancia es, precisamente, donde se esconden los problemas.
Anatomía de lo invisible#
Vale la pena detenerse en qué tipo de cosas suelen quedar fuera del radar, porque reconocerlas es el primer paso para hacerlas visibles. Están las dependencias de infraestructura silenciosa: el servicio de DNS que resuelve todos nuestros nombres, los certificados que cifran nuestras comunicaciones, las claves y secretos que permiten que un sistema le hable a otro, las cuentas de servicio que ejecutan tareas en segundo plano. Nada de eso se ve en el día a día, todo eso funciona en silencio, y cualquiera de esas piezas, si falla, puede tumbar cosas que parecían no tener relación con ella.
Después están las dependencias humanas y de conocimiento, que son tal vez las más subestimadas. Ese proceso que solo entiende una persona del equipo. Ese script crítico que escribió alguien que ya no está y que nadie se anima a tocar. Esa configuración que “siempre estuvo así” y que nadie sabe bien por qué. El conocimiento tribal es una dependencia tan real como un servidor, con el agravante de que no figura en ningún inventario y se va caminando el día que esa persona renuncia. He visto sistemas enteros sostenidos por la memoria de una sola persona, y no es una imagen tranquilizadora.
Y están las dependencias de terceros que dimos por sentadas. El proveedor de pagos, claro, ese lo tenemos presente. Pero también el servicio de envío de correos, la herramienta de analytics que cargamos en cada página, el CDN, la librería de código abierto que actualizamos sin leer, la API de un tercero que usamos para una función chiquita pero que está en el camino crítico de algo importante. Cada integración que sumamos por comodidad es una dependencia nueva, y la comodidad tiene la mala costumbre de hacernos olvidar que esa pieza existe hasta que un día deja de responder.
Por qué lo invisible es lo más peligroso#
Acá hay una asimetría cruel que conviene entender. Las dependencias visibles, justamente por ser visibles, suelen estar más cuidadas. Sabemos que la base de datos es crítica, así que le ponemos réplicas, backups, monitoreo, alertas. Sabemos que la nube es central, así que pensamos en regiones, en disponibilidad, en planes. Lo que conocemos, lo protegemos. El peligro real no está casi nunca en lo que sabemos que es crítico; está en lo que no sabíamos que lo era.
Pensémoslo así: un incidente en una dependencia conocida nos encuentra, al menos en parte, preparados. Tenemos un procedimiento, una alternativa, alguien que sabe qué hacer. Un incidente en una dependencia invisible nos encuentra desnudos. No solo falla algo; falla algo que ni siquiera sabíamos que estaba ahí, y entonces el primer tramo del incidente —a veces el más largo— se nos va en entender qué está pasando. Esa fase de “¿pero por qué se cayó esto si no tocamos nada?” es el costo puro de la invisibilidad. El tiempo que perdemos descubriendo la dependencia es tiempo en que el sistema está caído y nosotros, a ciegas. Lo que no conocemos no nos da la cortesía de avisarnos antes de romperse.
El momento en que lo invisible se vuelve visible#
Cualquiera que haya estado en el medio de un incidente serio conoce ese momento, y no se olvida. Algo se cayó. Las alertas suenan, o peor, no suenan y nos enteramos porque un cliente avisa. El equipo se junta, físico o virtual, y empieza la cacería. Y en los incidentes que involucran una dependencia invisible, la cacería tiene una textura particular: no es “sabemos qué se rompió, vamos a arreglarlo”, es “no entendemos qué está pasando”. Esa diferencia, que parece sutil, es la que estira los incidentes de minutos a horas.
Lo viví más de una vez, y el patrón se repite. Revisamos lo obvio, lo que está en el diagrama, lo que sabemos que es crítico. Todo parece estar bien. La base de datos responde, la aplicación está arriba, la nube no reporta nada. Y sin embargo el sistema no funciona. Pasan los minutos, sube la presión, alguien de negocio pregunta cuánto falta, y nosotros seguimos sin entender. Hasta que en algún momento, casi por casualidad, alguien tira una hipótesis sobre algo que ni figuraba en nuestra cabeza como parte del sistema: un certificado que venció, un servicio de un proveedor que cambió algo sin avisar, una cuenta que perdió permisos, un límite que se alcanzó en silencio. Y ahí está, la dependencia invisible, mostrándose por fin, después de habernos hecho perder un tiempo precioso simplemente porque no sabíamos que existía.
Lo más frustrante de esos incidentes no es el daño técnico, que muchas veces se arregla rápido una vez que entendemos. Lo más frustrante es la sensación de haber estado a ciegas en nuestra propia casa, de no conocer el sistema que se supone que manejamos. Y es una frustración honesta, porque tiene razón: no lo conocíamos del todo. Cada uno de esos incidentes es, en el fondo, una clase magistral, carísima y a destiempo, sobre una dependencia que podríamos haber mapeado tranquilos un mes antes. El incidente no nos enseña nada que no pudiéramos haber descubierto solos. Solo nos cobra mucho más caro la lección, y nos la da en el peor momento. Por eso insisto tanto con el ejercicio en frío: no es teoría de manual, es el intento de adelantarnos a esa madrugada en que el sistema nos enseña, a los golpes, lo que nunca nos sentamos a aprender por las buenas.
Quiero proponer algo concreto, porque toda esta reflexión corre el riesgo de quedar en la queja si no aterriza en una acción. El ejercicio es simple de enunciar y revelador de hacer: tomar un servicio crítico del negocio —uno solo, el más importante— y preguntarse, con terquedad, qué necesita para funcionar. Y por cada respuesta, volver a preguntar: ¿y eso de qué depende? Es un por qué de niño insistente, aplicado a la infraestructura.
Supongamos que el servicio crítico es “los clientes pueden iniciar sesión y operar”. Bien. Eso necesita la aplicación corriendo, que necesita la nube, que está clara. Pero también necesita la base de datos, que necesita su almacenamiento y sus credenciales. Necesita resolver nombres, o sea DNS. Necesita certificados válidos, o el navegador rechaza la conexión. Si el login usa un proveedor externo de identidad, necesita que ese proveedor esté arriba. Si manda un correo o un mensaje de verificación, necesita el servicio de envío. Si hay un balanceador, una cola, un caché, cada uno suma su propia cadena. Y de golpe, eso que en el diagrama eran tres cajas, en la realidad es una telaraña de quince o veinte piezas, varias de las cuales nadie había nombrado nunca en voz alta.
Lo interesante del ejercicio no es la lista final, aunque la lista final ya vale el esfuerzo. Lo interesante es lo que pasa mientras lo hacemos: las discusiones que aparecen, los “che, ¿y esto quién lo configuró?”, los silencios incómodos cuando nadie sabe responder de qué depende algo. Esos silencios son oro. Cada silencio es una dependencia invisible que acaba de empezar a volverse visible. Y no hace falta una herramienta cara ni un proyecto de seis meses para empezar: alcanza con una pizarra, un par de personas que conozcan distintas partes del sistema, y la disciplina de no conformarse con la primera respuesta.
No todas las dependencias pesan igual#
Un riesgo de este ejercicio es que, una vez que empezamos a ver dependencias por todos lados, nos abrume. Si todo depende de todo, ¿por dónde empezamos? Acá entra una pregunta que ayuda a ordenar: por cada dependencia que encontramos, ¿qué pasa si falla? No todas las respuestas son iguales. Hay dependencias cuya caída detiene todo el negocio, y hay otras cuya caída apenas degrada una función secundaria que puede esperar. Tratarlas igual sería tan ingenuo como ignorarlas.
La pregunta del “qué pasa si falla” tiene varias capas que conviene separar. Una cosa es cuánto duele que falle —si frena el negocio entero o solo una parte—. Otra es qué tan probable es que falle, que no siempre va de la mano con lo anterior. Y una tercera, que solemos olvidar, es si nos daríamos cuenta de que falló: hay dependencias que cuando se rompen avisan a los gritos, y otras que fallan en silencio y solo descubrimos el problema mucho después, cuando el daño ya se acumuló. Una dependencia que duele mucho, falla seguido y encima falla en silencio es una bomba de tiempo. Una que duele poco, casi nunca falla y avisa cuando lo hace, puede esperar. Entre esos dos extremos está casi todo, y el trabajo de criterio es ubicar cada pieza en ese mapa. La resiliencia no consiste en blindar absolutamente todo —sería carísimo e imposible—, sino en saber qué blindar primero.
La dependencia más invisible suele ser la confianza#
Quiero detenerme en un tipo particular de dependencia invisible, porque es la que más me preocupa y la que peor mapeamos: la confianza. Cuando usamos un proveedor que nunca nos falló, dejamos de verlo como una dependencia y empezamos a tratarlo como parte del paisaje, como si fuera el aire. Cuanto mejor funciona algo, más invisible se vuelve, y más nos olvidamos de que podría dejar de funcionar. La paradoja es brutal: las dependencias más confiables son, por eso mismo, las que peor monitoreamos, porque su misma confiabilidad nos invita a dejar de prestarles atención.
Esto vale para proveedores, pero también para piezas internas. Ese servicio que escribió un equipo hace cinco años y que nunca, jamás, dio un problema. Justamente porque nunca falló, nadie lo documentó bien, nadie lo monitorea de cerca, nadie sabría qué hacer si un día se cae. Su historial impecable se convirtió, sin que nadie lo decidiera, en una excusa para ignorarlo. Y el día que falle —porque todo falla alguna vez— vamos a descubrir que no teníamos ni idea de cómo funcionaba por dentro. La confiabilidad histórica no es una garantía futura; es, a lo sumo, una invitación peligrosa a la complacencia. Confiar en un proveedor o en un componente está bien. Dejar de gestionarlo porque confiamos, no.
Mapear no es un proyecto, es una práctica#
Si hay algo que aprendí, es que este tipo de mapeo no funciona como un proyecto con principio y fin. No sirve hacer un documento perfecto de dependencias en marzo y archivarlo, porque para junio ya está desactualizado: el sistema siguió creciendo, se sumaron integraciones, se cambió un proveedor, alguien conectó algo nuevo. Un mapa de dependencias congelado es casi tan engañoso como no tener ninguno, porque nos da una falsa sensación de que sabemos, cuando en realidad sabemos cómo eran las cosas hace tres meses.
Lo que sí funciona es convertirlo en una práctica viva, en un hábito. Que cada vez que sumamos una integración nueva, la pregunta “¿qué dependencia nueva estamos creando y qué pasa si falla?” sea parte natural de la conversación, no un trámite. Que revisar el mapa cada tanto sea una rutina, como revisar los backups. Que cuando alguien se va del equipo, una de las preguntas sea “¿qué dependencias vivían en su cabeza?”. No es glamoroso, lo sé. No hay una herramienta que lo resuelva con un clic, aunque varias ayudan. Es, sobre todo, una cuestión de cultura: la diferencia entre un equipo que sabe de qué depende y uno que lo va a descubrir de la peor manera está mucho menos en las herramientas que en el hábito de preguntárselo.
Lo que el mapa nos devuelve#
Vale la pena decir que este ejercicio, más allá de prepararnos para incidentes, tiene un beneficio que aparece antes de cualquier caída. Mapear de qué dependemos nos obliga a entender nuestro propio sistema con una profundidad que la operación diaria no exige. Y entender mejor lo que tenemos casi siempre mejora las decisiones que tomamos hacia adelante.
Un equipo que conoce sus dependencias decide distinto. Piensa dos veces antes de sumar la integración número treinta y uno. Negocia mejor con sus proveedores, porque sabe exactamente qué tan atado está. Detecta antes la concentración de riesgo, esa situación incómoda en que demasiadas cosas críticas dependen de una misma pieza. Documenta lo que importa porque sabe qué importa. El mapa de dependencias no es solo un seguro contra el desastre; es también una herramienta de diseño, una forma de ver el sistema con honestidad que termina influyendo en cómo lo hacemos crecer. A veces, el solo hecho de hacer visible una dependencia ya cambia la decisión de mantenerla.
La incomodidad como aliada#
Voy a volver al principio, a esa incomodidad del ejercicio en frío. Porque creo que ahí está el verdadero obstáculo, y no es técnico. El problema no es que mapear dependencias sea difícil de hacer; el problema es que es incómodo de enfrentar. Sentarse a descubrir que dependemos de cosas que no controlamos, que no entendemos del todo, que viven en la cabeza de una sola persona o en un servicio que nadie mira, no es una experiencia agradable. Es mucho más cómodo seguir operando con la ilusión de que todo está bajo control, mirando el diagrama lindo en vez de la telaraña real.
Pero esa incomodidad es exactamente la señal de que el ejercicio está funcionando. Cada cosa que nos incomoda descubrir es una cosa que ya estaba ahí, latente, esperando el peor momento para mostrarse. Hacerla visible no crea el problema: el problema ya existía. Lo único que hacemos al mapear es elegir descubrirlo nosotros, en nuestros términos, un día tranquilo, en lugar de que nos lo descubra un incidente en el peor momento posible. La incomodidad de saber siempre va a ser más barata que la sorpresa de no saber.
Me quedo, entonces, con la invitación a hacer ese ejercicio incómodo, y con una pregunta que cada uno puede llevarse a su propio sistema. Si tuvieran que escribir ahora mismo, de memoria, la lista completa de cosas de las que depende su servicio más crítico, ¿cuán larga sería esa lista, y cuánto de lo que de verdad la sostiene quedaría afuera por la simple razón de que nunca, hasta hoy, se molestó en fallar? Porque las dependencias que no sabíamos que teníamos no dejan de existir por no conocerlas. Solo esperan, pacientes, el día en que ya no podamos seguir ignorándolas.