Adrian RomoAdrian Romo
Todos los textos
Nota de arquitectura 3 min de lectura

La red es la capa que documenté al final

Mi homelab cuenta con un IPAM, métricas de cada punto de acceso y un archivo de configuración para la red que está completamente lleno de marcadores de posición, con una advertencia al inicio que lo admite.

Mi homelab está documentado hasta un grado irrazonable. Cada host tiene una página. Cada servicio con estado tiene un procedimiento de restauración probado. Hay un grafo de relaciones, un almacén de hechos y una verificación automatizada que se queja cuando la documentación se desvía de la realidad.

La red — la base sobre la que corre todo — tiene un archivo de configuración cuyos contenidos son marcadores de posición, y una advertencia en la parte superior que lo indica.

Lo que realmente existe

La instrumentación está bien. Hay un sistema IPAM corriendo con su propia base de datos, workers y respaldos. Hay un poller que extrae métricas del router y puntos de acceso hacia Prometheus, dashboards en Grafana, probes blackbox, monitoreo de uptime y enrutamiento de alertas. Un par de servidores DNS con failover automatizado. Un reverse proxy cuyas rutas son inventariadas por un colector.

Así que la red está observada. No está descrita. Son cosas diferentes, y durante mucho tiempo las había confundido.

Por qué esta capa y no otra

Porque documento lo que se rompe, y la red casi nunca se rompe.

Las capas de aplicación fallan semanalmente, de formas pequeñas y recuperables, cada una generando una corrección y una nota. Eso es un volante de documentación: fallas frecuentes y de bajo impacto generan escritura. La red falla casi nunca — y cuando lo hace, se lleva todo consigo, que es precisamente el momento en que no tienes capacidad para escribir nada.

El resultado es una relación inversa entre la importancia de una capa y qué tan bien la he descrito. La capa más crítica genera la menor cantidad de escritura, porque es la más confiable. Eso no es un fallo personal, sino una propiedad estructural del aprendizaje por incidentes, y vale la pena saber que tu documentación es más densa donde tus problemas fueron menores.

Lo más útil en ese archivo es la advertencia

El archivo de red está lleno de marcadores de posición. Lo que también tiene, en la parte superior, es un banner explícito que dice que cada valor es un marcador de posición y debe confirmarse contra el router y el hypervisor antes de que alguien lo crea.

Ese banner hace más trabajo que la mayoría de mi documentación real.

Un archivo lleno de valores que parecen plausibles pero sin procedencia es activamente peligroso — alguien lo lee, cree en una subred y planea un cambio basado en un número que nadie verificó. El mismo archivo que anuncia su propia falta de confiabilidad es seguro, porque no puede confundirse con evidencia. Es una brecha conocida en lugar de una mentira desconocida.

Tengo todo un sistema construido alrededor del principio de que una afirmación que no puede citar su fuente debe ser bloqueada en lugar de matizada. Ese banner es la misma regla, aplicada a mano, antes de que construyera la maquinaria. Lo más barato y honesto que puede hacer un documento es decirte que aún no confíes en él.

El apagón que prueba el punto

La única vez que la red se cayó, tiró todo el homelab a las dos menos cuarto de la mañana. Culpe al reverse proxy, luego a la capa de prevención de intrusiones, luego al servicio de single sign-on. La causa raíz fue un puerto caído en el switch, y todo lo que sospeché fue un síntoma de eso.

Nunca he escrito una página de red. Sí escribí un postmortem de esa noche, y es lo que más se ha leído sobre mi propia red — lo que te dice exactamente qué recompensa el volante.

Escrito por

Adrian Romo

Ingeniero Backend Senior que diseña APIs escalables en Python, arquitecturas sobre AWS Lambda, sistemas de voz e integraciones empresariales.

Continúa

¿A dónde sigues?

Explora más textos técnicos, revisa los casos de estudio o escríbeme directo.