Lo que mi homelab me enseña como CIO técnico

Llevo décadas trasteando con tecnología. Mucho antes de llamarlo homelab ya estaba probando cosas en casa, rompiendo configuraciones, montando equipos, cambiando piezas, aprendiendo con errores y preguntándome qué pasaba por debajo.

Eso sigue igual. Lo que sí ha cambiado es la perspectiva.

Hay días en los que entro en el laboratorio con una idea muy clara y termino desmontando otra completamente distinta. Muchas veces empiezo intentando aprender una tecnología y termino aprendiendo algo sobre cómo tomar mejores decisiones. Eso es lo que hace que merezca la pena seguir trasteando.

Hoy soy CIO. Y cuando miro mi homelab ya no veo solo “el laboratorio del informático”. Veo un espacio donde poner a prueba decisiones, descubrir los límites de una tecnología y decidir si realmente merece un sitio en mi forma de trabajar.

Este artículo no va de explicar qué es un homelab ni de recomendar hardware. Eso ya lo conté en Mi homelab: el laboratorio de un CIO. Aquí quiero hablar de otra cosa: de lo que mi homelab me enseña como CIO técnico cuando tengo que decidir, priorizar, asumir riesgos y seguir tomando buenas decisiones.

Porque muchas decisiones que tomas en un homelab se parecen bastante a las decisiones de empresa. Cambian la escala, el presupuesto y las consecuencias, pero la forma de razonar no es tan distinta.

No es un juguete: es un laboratorio de decisiones

Un homelab puede parecer un conjunto de máquinas, contenedores, cables, automatizaciones y servicios funcionando en casa. Pero para mí es algo más.

Es un sitio donde puedes tomar decisiones pequeñas que se parecen mucho a decisiones grandes.

Qué monto. Qué no monto. Qué expongo. Qué dejo solo en local. Qué automatizo. Qué documento. Qué respaldo. Qué actualizo solo. Qué prefiero tocar manualmente. Qué dependencia acepto. Qué riesgo no merece la pena.

En la empresa esas preguntas tienen más impacto, más personas afectadas, más presupuesto y más responsabilidad. En casa las consecuencias son menores, pero el razonamiento se entrena igual.

Y eso es lo interesante. El homelab no me sirve solo para aprender una herramienta. Me sirve para entrenar una forma de pensar. Mi laboratorio no existe para acumular tecnología. Existe para ayudarme a tomar mejores decisiones cuando esas tecnologías dejan de estar en mi laboratorio y pasan a formar parte del trabajo de otros.

La misma ecuación, con menos ceros

En una empresa decides entre cloud, on-premise, SaaS, infraestructura propia, proveedores, servicios gestionados o modelos híbridos. Valoras coste, control, seguridad, disponibilidad, dependencia, mantenimiento y capacidad del equipo.

En casa haces algo parecido, aunque con menos ceros.

Decides si algo lo alojas tú o lo dejas en un servicio externo. Si te compensa mantenerlo. Si necesitas alta disponibilidad o basta con poder restaurarlo. Si merece la pena automatizarlo. Si el tiempo que te va a consumir compensa lo que te aporta.

La escala cambia, pero la pregunta de fondo es la misma: ¿qué problema estoy resolviendo y qué coste operativo estoy aceptando?

Con los años he descubierto que esa acaba siendo la pregunta importante, tanto en casa como en la empresa.

La trampa de montar tecnología porque sí

Cuando empiezas con un homelab es fácil caer en la acumulación.

A mí también me pasó. Durante una época montaba servicios simplemente porque quería entenderlos. Algunos se quedaron. Otros desaparecieron pocas semanas después. Con el tiempo entendí que un laboratorio no consiste en tener más servicios, sino en aprender algo útil de cada uno.

Montas un servicio porque lo has visto en un vídeo. Luego otro porque aparece en una lista de “imprescindibles”. Después un dashboard para verlo todo. Luego otro dashboard para vigilar el dashboard. Alertas, métricas, contenedores, automatizaciones, integraciones, pruebas temporales que se quedan viviendo para siempre.

Y un día te das cuenta de algo incómodo: estás haciendo en casa lo mismo que muchas veces criticamos en la empresa.

Tecnología por la tecnología.

Herramientas que parecen importantes pero no resuelven nada. Proyectos que se justifican porque son nuevos, no porque eliminen un problema. Arquitecturas demasiado grandes para necesidades pequeñas.

Cuanto más tiempo llevo montando cosas, menos necesidad tengo de montar tecnología porque sí. Hoy disfruto mucho más eliminando un servicio innecesario que instalando uno nuevo.

Más de una vez he terminado desmontando una solución técnicamente brillante porque el coste de mantenerla no compensaba. Ahí entendí que una tecnología no termina de evaluarse el día que consigues instalarla. Se evalúa durante los meses o los años en los que tienes que convivir con ella.

Mi homelab me ha enseñado a desconfiar de esa tentación.

Ahora intento aplicar una regla sencilla: si algo no resuelve un problema real, no me enseña algo valioso o no mejora un proceso que uso de verdad, no entra. Y si entra, tiene que tener un motivo.

No siempre lo cumplo perfecto, pero cada vez lo tengo más claro: el criterio técnico empieza muchas veces diciendo “esto no hace falta”.

El coste oculto no es el hardware, es el mantenimiento

Comprar o montar algo suele ser la parte fácil.

Lo difícil viene después.

Actualizar. Revisar logs. Entender por qué algo ha dejado de funcionar. Migrar datos. Corregir permisos. Limpiar volúmenes. Revisar backups. Cambiar una variable de entorno que ya ni recordabas. Buscar por qué una automatización que llevaba meses funcionando ha decidido fallar justo cuando menos te apetecía mirarla.

Eso es el coste real.

En la empresa pasa igual. Muchas decisiones se venden por el coste de implantación, pero el problema aparece en el coste de operación. Quién lo mantiene. Quién lo entiende. Quién lo documenta. Quién responde cuando falla. Quién sabe restaurarlo. Quién asume la deuda técnica que deja.

Mi homelab me recuerda constantemente que todo servicio tiene una factura oculta. A veces es dinero. A veces es tiempo. A veces es ruido mental.

Por eso valoro cada vez más las soluciones simples. No las simples por pobres, sino las simples porque se entienden, se mantienen y se recuperan mejor.

Me pasó, por ejemplo, con el proxy inverso. Durante un tiempo usaba Traefik. Funcionaba bien, pero en mi contexto la sencillez era más importante que tener todas las opciones posibles. Cambié a Caddy y el mantenimiento se redujo de forma notable. Fue una decisión pequeña, pero me recordó algo que aplico también en la empresa: la mejor herramienta no siempre es la más potente. Muchas veces es la que menos carga operativa deja.

Probar algo no es lo mismo que entenderlo

Una cosa es instalar una herramienta y verla arrancar. Otra muy distinta es entender qué implica mantenerla.

Esto lo aprendes rápido en un homelab.

Un contenedor puede levantarse en dos minutos. Pero luego tienes que saber dónde guarda los datos, cómo se actualiza, qué pasa si cambia una versión, qué permisos necesita, cómo se restaura, qué expone, qué logs genera y cómo se comporta cuando algo va mal.

Me pasó con Docker. Al principio era solo una forma de probar servicios sin ensuciar el sistema. Con el tiempo se convirtió en mi forma natural de desplegar: limpio, predecible, reproducible. Y eso cambió mi forma de desplegar y mantener software.

Algo parecido me ocurrió con la automatización del hogar. Instalar Home Assistant no era mi objetivo. Lo monté para entender cómo funcionan las integraciones, los sensores, las automatizaciones condicionales y la fiabilidad de un sistema que coordina dispositivos de distintos fabricantes. Terminé comprendiendo mejor conceptos que luego he aplicado en entornos más serios.

Y, sobre todo, aprendí que una automatización solo merece la pena cuando puedes confiar en ella incluso el día que algo falla.

Muchas automatizaciones que hoy funcionan desde hace meses empezaron fallando varias veces. Precisamente por eso terminé confiando en ellas. Cuando entiendes por qué algo falla y cómo recuperarlo, también entiendes mucho mejor cuándo merece la pena automatizarlo.

Eso cambia mucho la forma de mirar la tecnología.

Cuando un proveedor te enseña una solución muy pulida, ya no miras solo la demo. Empiezas a hacer otras preguntas: qué dependencia crea, cómo se integra, cómo se recupera, qué pasa si sube el precio, cómo sales de ahí, qué datos toca, qué visibilidad tienes y cuánto conocimiento pierdes si delegas demasiado.

No se trata de rechazar servicios gestionados. Muchas veces tienen todo el sentido del mundo.

Se trata de no comprar magia.

Construir un laboratorio de IA local también me ayudó con eso. Antes de decidir qué modelos merecían realmente la pena, los probé, los medí, los comparé y entendí sus límites. No fue un ejercicio teórico: fue instalar, ejecutar, fallar, ajustar y decidir con datos reales. Ese proceso no pretendía convertirme en especialista en IA. Lo que buscaba era entender dónde aportaba valor, cuáles eran sus límites y qué problemas resolvía realmente antes de incorporarla a mi forma de trabajar. No necesitaba saberlo todo. Necesitaba tener criterio para decidir cuándo utilizarla y cuándo no.

Cloud sí, pero sin dependencia ciega

No soy anti-nube. Sería absurdo.

La nube aporta elasticidad, servicios gestionados, disponibilidad, rapidez de despliegue, integración y capacidades que en muchos casos no tiene sentido replicar por tu cuenta.

Pero una cosa es usar cloud con criterio y otra depender de él sin entender qué estás entregando a cambio.

El homelab me ayuda precisamente en eso. No porque pretenda sustituir una nube pública con un equipo en casa. Eso no tiene sentido. Me ayuda porque me recuerda qué hay debajo de muchos servicios que a veces damos por hechos.

Cuando has levantado tú mismo un servicio, has peleado con certificados, DNS, backups, almacenamiento, permisos, actualizaciones y monitorización, entiendes mejor qué te está ahorrando un proveedor.

Y también entiendes mejor qué dependencia te está creando.

Esa diferencia es importante. Como CIO no se trata de hacerlo todo tú. Se trata de saber qué estás delegando, por qué lo haces y qué margen te queda si las condiciones cambian.

Seguridad que se prueba, no seguridad de PowerPoint

La seguridad se entiende de otra manera cuando la pruebas en sistemas reales.

Leer una guía de hardening está bien. Aplicarla y quedarte fuera de una máquina por tocar mal una regla de firewall enseña bastante más.

Diseñar segmentación de red sobre papel es una cosa. Separar dispositivos, aplicar reglas, romper una integración y tener que entender por qué algo ya no habla con algo es otra.

Decir que tienes backups es fácil. Restaurar de verdad y descubrir que faltaba un volumen, una ruta, una variable o una dependencia te cambia la forma de documentar.

Montar una VPN parece sencillo hasta que piensas qué clientes tienen acceso, qué rutas pasan por ahí, cómo revocas un dispositivo perdido y qué servicios internos estás dejando al alcance.

Con el filtrado DNS pasa algo parecido. Hasta que no ves los logs de tu propia red, no eres consciente de cuánto hablan algunos dispositivos cuando nadie les está mirando.

El homelab te permite vivir esas cosas sin convertirlas en un incidente corporativo.

Y eso vale mucho.

Monitorizar no es llenar pantallas de gráficos

Yo también pasé por esa fase: montar paneles, métricas, gráficas y alertas pensando que así tenía el sistema bajo control.

Pero monitorizar no es tener muchas pantallas. Es saber qué necesitas saber.

Si un servicio cae, quiero enterarme. Si un certificado va a caducar, quiero saberlo. Si un disco se llena, quiero verlo antes de que rompa algo. Si un servicio empieza a consumir más memoria de lo normal, quiero tener una pista. Si una copia de seguridad falla, quiero una alerta clara.

Lo demás puede ser ruido.

Ese aprendizaje también sirve en la empresa. Muchas organizaciones no tienen falta de herramientas. Tienen falta de señales útiles. Miden mucho, pero no siempre miden lo que ayuda a decidir.

El homelab te enseña rápido que una buena alerta es la que te permite actuar. Las demás solo te entrenan para ignorarlas.

Documentar para tu yo del futuro

Cuando montas algo, crees que te vas a acordar.

No te vas a acordar.

A los seis meses vuelves a tocar un servicio y ya no recuerdas por qué elegiste ese puerto, dónde estaba el volumen, qué variable era obligatoria, qué dependencia rompía la actualización o qué comando usaste para restaurar.

La documentación no es burocracia. Es una forma de reducir sufrimiento futuro.

En casa puede ser un Markdown, una nota, un repositorio privado o una carpeta con procedimientos. En la empresa será una wiki, una base de conocimiento, un procedimiento formal o documentación de arquitectura.

La escala cambia, pero la necesidad es la misma.

Documentar no es escribir por escribir. Es dejar rastro de decisiones, de dependencias y de formas de recuperación.

Y eso, cuando algo falla, marca la diferencia.

El homelab como simulador de incidentes

Un homelab se rompe.

Y eso es parte de su valor.

Una actualización rompe un contenedor. Un volumen se llena. Un certificado caduca. Una automatización deja de ejecutarse. Un cambio de red deja sin acceso a un servicio. Un backup no restaura como esperabas.

La primera reacción suele ser frustración. La segunda, si tienes algo de método, es aprender.

Mirar logs. Aislar causas. Volver atrás. Restaurar. Documentar. Corregir. Mejorar.

Eso es gestión de incidentes en pequeño.

En la empresa las consecuencias son otras, pero la actitud importa igual. No entrar en pánico. Entender el alcance. Priorizar. Recuperar servicio. Aprender después.

El homelab te entrena en eso sin tener a media organización esperando al otro lado.

He roto configuraciones muchas veces. Algunas a propósito, otras por error. En ambos casos he aprendido algo: cómo recuperarlas. Y esa experiencia, aunque parezca menor, es de las que más valor tienen cuando en la empresa alguien dice que algo no se puede restaurar.

Lo que cambia cuando hablas con proveedores

Una de las cosas que más valoro de seguir tocando tecnología es que cambia la conversación con proveedores.

Cuando has montado, roto y mantenido servicios por tu cuenta, escuchas una presentación comercial de otra manera.

No te quedas solo con las promesas. Preguntas por integración, reversibilidad, exportación de datos, costes ocultos, dependencias, soporte, seguridad, límites, escalado, monitorización, backup, recuperación y salida.

No porque vayas a hacerlo todo tú.

Sino porque entiendes lo suficiente como para saber dónde puede doler.

Eso no sustituye un piloto serio, una prueba de concepto formal o un análisis de riesgos. Pero te hace llegar a esa conversación con mejores preguntas.

Y muchas veces, en tecnología, las buenas decisiones empiezan por hacer mejores preguntas.

He comprobado muchas veces que una buena decisión rara vez empieza con una respuesta brillante. Normalmente empieza cuando alguien hace la pregunta que todavía nadie había planteado.

No perder el contacto con la tecnología real

Un CIO no tiene que configurar cada switch, escribir cada script o revisar cada log. Ese no es su papel principal.

Pero sí debería entender lo que implica una decisión técnica.

Entender lo que duele una migración. Lo que significa una ventana de mantenimiento. Lo que pasa cuando una actualización rompe una dependencia. Lo que implica exponer un servicio a Internet. Lo que cuesta recuperar un backup. Lo que un equipo técnico quiere decir cuando dice: “Esto no es tan sencillo”.

El homelab es una forma de no perder ese contacto.

No te hace automáticamente mejor CIO. Pero te recuerda algo importante: la tecnología no se lidera bien si se deja de entender.

Y al final, ¿merece la pena?

Mi homelab no existe para tener más servidores.

Existe para aprender y tomar mejores decisiones cuando los servidores son de otros.

Mi laboratorio no existe para demostrar que una tecnología funciona. Existe para descubrir cómo falla. Solo cuando entiendo cómo se rompe, cómo se recupera y qué dependencias introduce, empiezo a confiar realmente en ella.

Las tecnologías cambiarán. Llegarán herramientas nuevas, arquitecturas distintas y formas diferentes de hacer las cosas. Lo importante no es intentar conocerlas todas. Lo importante es mantener la curiosidad suficiente para entender qué problema resuelven, cuándo merecen la pena y cuándo no.

Al final, las herramientas cambiarán una y otra vez. Lo que intento mantener vivo desde hace años no son los servidores, los contenedores o las automatizaciones. Es la forma de pensar con la que intento decidir mejor. Porque esa forma de pensar sigue siendo útil mucho después de que la tecnología haya cambiado.