Mapa de dependencias

Un mapa de dependencias parte del proceso y baja por capas: la aplicación que lo sirve, la base de datos y el directorio de cuentas que usa, la red, la energía, los proveedores externos y las personas con el conocimiento para operarlo. Lo que se omite de ese mapa es lo que sorprende el día del incidente.

Una dependencia puede ser directa (la aplicación usa la base de datos) o indirecta (la aplicación usa algo que usa la red). La caída de un componente alcanza a todos los que dependen de él, directa o indirectamente.

Contar quién depende de cada componente es la primera lectura de un mapa. El que acumula más dependientes directos es el que más procesos arrastra si falla, y por eso se recupera primero y se protege mejor.

Abre dependencias y cuenta, por cada valor de depende_de, cuántos servicios distintos aparecen a su izquierda.

Un punto único de falla es un componente sin respaldo del que depende algo que importa. Mirar solo cuántos dependientes directos tiene un componente puede engañar: un componente de red, con pocos dependientes directos, puede estar bajo todos los demás y alcanzar a todo por la vía indirecta.

Abre redundancia y busca el que no tiene respaldo.

Para contar el alcance de una caída se sigue la cadena hacia arriba: se toman los servicios que dependen directamente del componente caído y, después, los que dependen de esos. Se cuenta cada servicio una sola vez.

Abre dependencias y sigue las filas de prs-db01 hacia la izquierda. Cuenta solo los servicios de aplicación (los que empiezan por prs- y no son la propia base de datos ni el controlador de dominio).

Encontrar el punto único de falla no lo arregla. Las opciones son poner un respaldo, aceptar el riesgo con la firma de quien es responsable de él o preparar una alternativa para operar sin el componente mientras se repone. Lo que no se puede hacer es dejarlo anotado sin dueño ni decisión, porque el mapa entonces no cambia nada.