Mi hoja de ruta de aprendizaje IT a 5 años: de sysadmin a ingeniero de infraestructura

🌐 También en: English · Deutsch · Français

Linux. Windows. Redes. Seguridad. Observabilidad. Automatización. Cloud. Kubernetes. IA.

Pero, sobre todo:

🧠 Aprender a entender los sistemas, no solo a manejarlos.

Últimamente he pensado bastante en hacia dónde quiero llevar mis conocimientos de IT en los próximos años.

Mi trayectoria profesional ya me da una base bastante amplia:

• 🐧 Administración de sistemas Linux
• 📊 Monitorización
• 🚨 Gestión técnica de eventos
• 📝 Gestión de logs
• 🌐 Redes
• 🔐 Seguridad

En lo profesional, mi foco actual gira cada vez más en torno a Graylog y la gestión de logs.

Fuera del trabajo, también me interesan mucho:

• Windows Server
• Active Directory
• Docker
• Kubernetes
• Git
• Automatización
• Sistemas operativos
• IA

Además tengo un homelab bastante apañado, con tres servidores físicos y dos PC de torre.

Así que la pregunta no es realmente:

«¿Qué tecnología debería aprender ahora?»

La pregunta mucho más interesante es:

«¿Qué tipo de ingeniero quiero ser dentro de cinco años?»

🎯 El objetivo

Mi objetivo a largo plazo no es convertirme en quien más comandos se sabe.

Tampoco es coleccionar certificaciones como si fueran Pokémon.

Y desde luego no es aprender cada tecnología nueva que aparece en Hacker News cada martes. 😄

Quiero convertirme en alguien capaz de:

• entender infraestructuras complejas
• diseñar infraestructura
• operar infraestructura
• diagnosticar problemas de infraestructura
• automatizar infraestructura
• proteger infraestructura
• monitorizar infraestructura
• entender dependencias
• analizar fallos
• tomar decisiones de arquitectura
• evaluar opciones tecnológicas
• usar la IA de forma eficaz como herramienta de ingeniería

Dicho de otro modo:

🏗️ Ingeniería de infraestructura

con una base sólida en Linux, Windows, redes, seguridad, observabilidad, automatización, cloud y tecnologías cloud-native.

🧠 Lo más importante: cómo quiero aprender

Esta es la base de toda la hoja de ruta.

Mi forma de aprender se aleja a propósito de la pura memorización.

La infraestructura moderna es sencillamente demasiado compleja como para memorizar cada comando, cada parámetro de API y cada opción de configuración.

Y, siendo sinceros:

man systemctl
man kubectl
Get-Help
documentation
Google
ChatGPT
Claude

...exist for a reason. 😎

Así que quiero subir un nivel de abstracción.

❌ El enfoque antiguo

Problem
   ↓
Remember command
   ↓
Run command
   ↓
Hope

✅ El enfoque que quiero desarrollar

Problem
   ↓
Define the problem
   ↓
Understand the architecture
   ↓
Identify components
   ↓
Understand dependencies
   ↓
Collect evidence
   ↓
Form hypotheses
   ↓
Test hypotheses
   ↓
Find root cause
   ↓
Design solution
   ↓
Automate
   ↓
Document

El comando en sí pasa a ser solo una parte del proceso.

El comando es la herramienta. La comprensión es la habilidad.

📐 Mi modelo de aprendizaje: la regla 20/30/30/20

Para los grandes temas de esta hoja de ruta, busco más o menos este reparto:

No es una fórmula matemática rígida.

Es un recordatorio de dónde debe estar el énfasis.

Si termino un tema sabiéndome 200 comandos pero sin poder explicar cómo funciona el sistema, probablemente he aprendido lo que no era.

🔬 El ciclo de aprendizaje

Cada tecnología importante debe pasar por el mismo ciclo.

1️⃣ Entender

¿Qué es esta tecnología?

2️⃣ Modelar

¿Cómo está diseñada su arquitectura?

3️⃣ Construir

Desplegarla en el homelab.

4️⃣ Observar

Monitorizar e inspeccionar su comportamiento.

5️⃣ Romper

Provocar fallos a propósito.

6️⃣ Diagnosticar

Encontrar la causa de forma sistemática.

7️⃣ Automatizar

Convertir el trabajo repetitivo en código.

8️⃣ Documentar

Crear documentación de arquitectura y runbooks.

9️⃣ Explicar

Ser capaz de explicar el sistema a otro ingeniero.

🔟 Validar

Una certificación, una prueba práctica o un proyecto real como control final.

⏱️ Mi presupuesto de tiempo semanal realista

No quiero que esta hoja de ruta se convierta en otro trabajo a jornada completa.

Una media realista es:

Objetivo: unas 5–8 horas a la semana.

Antes de una certificación, puede aumentar temporalmente.

En épocas de mucho lío, puede bajar.

Lo importante es la constancia a largo plazo.

🗺️ LA HOJA DE RUTA A CINCO AÑOS

2026
 │
 ├── Linux
 ├── Graylog
 ├── Git
 └── Ansible
       │
       ▼
2027
 │
 ├── Advanced Linux
 ├── Windows Server
 ├── Active Directory
 ├── Security
 └── Infrastructure Architecture
       │
       ▼
2028
 │
 ├── Terraform / OpenTofu
 ├── Infrastructure as Code
 ├── Kubernetes
 └── GitOps
       │
       ▼
2029
 │
 ├── Azure
 ├── Entra ID
 ├── Hybrid Cloud
 ├── Multi-RZ
 └── Disaster Recovery
       │
       ▼
2030
 │
 ├── Observability
 ├── OpenTelemetry
 ├── Platform Engineering
 ├── AI
 └── AIOps

🐧 AÑO 1 — Linux, Graylog, Git y automatización

📅 Periodo: septiembre de 2026 – agosto de 2027

Objetivo principal: construir una base extremadamente sólida en sistemas y automatización.

Esfuerzo estimado: 5–8 horas/semana.

🐧 Fase 1 — Linux avanzado / ingeniería de sistemas

Duración: unos 6–9 meses

Objetivo: 120–180 horas

Temas que quiero dominar

• arquitectura de Linux
• proceso de arranque
• systemd
• procesos e hilos
• señales
• planificación de CPU
• gestión de memoria
• memoria virtual
• sistemas de archivos
• LVM
• RAID
• ZFS
• redes
• DNS
• SSH
• permisos
• ACL
• journald
• logging
• análisis de rendimiento
• fundamentos del kernel
• bastionado de seguridad

Especialmente importante

Quiero entender por qué Linux se comporta como se comporta.

Por ejemplo:

¿Por qué va lento el servidor?

En lugar de lanzar comandos al azar de inmediato, quiero aprender a distinguir:

CPU?
RAM?
I/O?
Network?
Filesystem?
Process?
Kernel?
Application?
Dependency?
Configuration?

Hito de certificación

🎓 LFCS — Linux Foundation Certified System Administrator.

Alternativa:

🎓 RHCSA, sobre todo si el ecosistema Red Hat gana peso en mi trabajo.

Meta final

Dame un servidor Linux roto y encontraré la causa raíz de forma sistemática.

📊 Fase 2 — Graylog y gestión de logs

Duración: continua durante todo el año 1

Prioridad: MUY ALTA

Es mi especialización profesional actual.

Temas

• arquitectura de Graylog
• nodos de Graylog
• Data Nodes
• OpenSearch
• shards
• réplicas
• index sets
• streams
• pipelines
• parsers
• procesamiento
• retención
• journal
• Fluent Bit
• syslog
• GELF
• Fluent Forward
• relays
• HA
• planificación de capacidad
• rendimiento
• logging de seguridad
• detección de eventos

Arquitectura objetivo

Thousands of Servers
        │
        ▼
Agents / Syslog
        │
        ▼
Relay Tier
        │
        ▼
Graylog
        │
        ▼
OpenSearch
        │
        ▼
Hot / Cold Storage

Quiero ser capaz de calcular

• ingesta diaria
• necesidades de almacenamiento
• sobrecarga por replicación
• retención
• almacenamiento caliente
• almacenamiento frío
• dimensionamiento del clúster
• escenarios de fallo

Hito profesional

Ser capaz de diseñar y defender una arquitectura de logging centralizado lista para producción.

🌱 Fase 3 — Git y Ansible

Duración: 4–6 meses

Git

• repositorios
• ramas
• merge
• rebase
• tags
• pull requests
• GitLab
• fundamentos de CI/CD

Ansible

• inventario
• roles
• collections
• variables
• plantillas
• Jinja2
• Vault
• handlers
• idempotencia
• pruebas
• AWX

Objetivo

Manual configuration
       ↓
Ansible
       ↓
Git
       ↓
Version-controlled infrastructure
       ↓
Repeatable infrastructure

Quiero llegar al punto de pensar:

«Si tengo que configurar esto a mano dos veces, lo estoy haciendo mal.»

🪟 AÑO 2 — Windows Server, Active Directory y arquitectura

📅 Periodo: septiembre de 2027 – agosto de 2028

Objetivo principal: pasar de la administración Linux a la infraestructura empresarial.

🪟 Fase 4 — Windows Server

Duración: 4–6 meses

Temas

• arquitectura de Windows Server
• roles y características
• PowerShell
• redes en Windows
• almacenamiento en Windows
• clústeres de Windows
• registros de eventos de Windows
• WinRM
• servicios
• análisis de rendimiento
• seguridad

🔐 Fase 5 — Active Directory

Duración: 5–7 meses

Temas

• AD DS
• bosque
• dominio
• diseño de OU
• controladores de dominio
• roles FSMO
• replicación de AD
• Sites and Services
• DNS
• directivas de grupo
• Kerberos
• LDAP
• SPN
• cuentas de servicio
• gMSA
• AD CS
• PKI
• seguridad de AD

Conexión importante con Linux

                 Active Directory
                        │
             ┌──────────┼──────────┐
             │          │          │
            DNS      Kerberos     LDAP
             │          │          │
             └──────────┼──────────┘
                        │
              ┌─────────┴─────────┐
              │                   │
           Windows              Linux
              │                   │
             GPO             SSSD / PAM
          PowerShell          Kerberos
             WinRM               LDAP

El objetivo no es convertirme en administrador de Windows en lugar de administrador de Linux.

El objetivo es entender ambos mundos y las interfaces entre ellos.

Hito de certificación

🎓 Itinerario de certificación de Microsoft Windows Server / Hybrid Administration.

El examen concreto lo elegiré al empezar la fase, porque Microsoft actualiza su catálogo de certificaciones con frecuencia.

🏗️ Fase 6 — Arquitectura de infraestructura

Duración: 6–12 meses

Es una de las fases más importantes de toda la hoja de ruta.

Temas

• patrones de arquitectura
• jerarquía
• dependencias entre servicios
• dominios de fallo
• HA
• redundancia
• balanceo de carga
• arquitectura de almacenamiento
• arquitectura de red
• multi-CPD
• recuperación ante desastres
• RPO
• RTO
• planificación de capacidad
• escalabilidad
• arquitectura de copias de seguridad
• arquitectura de seguridad
• documentación

Gran proyecto

Diseñar una infraestructura empresarial ficticia para:

• 5.000 servidores
• Linux + Windows
• dos centros de datos
• logging centralizado
• monitorización centralizada
• servicios de identidad
• monitorización de seguridad
• copias de seguridad
• HA
• DR

Entregables:

• diagramas de arquitectura
• diseño de red
• mapa de dependencias
• concepto de HA
• concepto de DR
• cálculo de capacidad
• concepto de seguridad
• concepto de monitorización
• concepto de logging

Este ejercicio es deliberadamente más grande que un proyecto normal de homelab.

El objetivo es aprender a pensar como un arquitecto de infraestructura.

☁️ AÑO 3 — Infrastructure as Code y Kubernetes

📅 Periodo: septiembre de 2028 – agosto de 2029

🏗️ Fase 7 — Terraform / OpenTofu

Duración: 4–6 meses

Temas

• providers
• recursos
• state
• módulos
• variables
• outputs
• remote state
• secretos
• CI/CD
• ciclo de vida de la infraestructura

Objetivo

Git
 ↓
Infrastructure as Code
 ↓
Provisioning
 ↓
Ansible
 ↓
Configuration
 ↓
Monitoring
 ↓
Logging

Quiero entender con claridad la diferencia entre:

• aprovisionamiento
• gestión de configuración
• orquestación
• despliegue de aplicaciones

☸️ Fase 8 — Kubernetes

Duración: 8–12 meses

Prioridad: ALTA

Temas

• control plane
• API Server
• etcd
• scheduler
• controladores
• kubelet
• container runtime
• redes
• DNS
• Services
• Ingress
• almacenamiento
• PVC
• RBAC
• Secrets
• Helm
• Operators
• GitOps
• Flux
• seguridad
• resolución de problemas

Hitos de certificación

🎓 CKA — administración de Kubernetes.

Más adelante:

🎓 CKS — seguridad en Kubernetes.

La CKS me atrae especialmente porque combina Kubernetes con mi experiencia previa en seguridad.

☁️ AÑO 4 — Azure, nube híbrida y multi-CPD

📅 Periodo: septiembre de 2029 – agosto de 2030

☁️ Fase 9 — Azure

Duración: 6–9 meses

Temas

• arquitectura de Azure
• VNets
• subredes
• enrutamiento
• NSG
• balanceo de carga
• VM
• almacenamiento
• identidad
• seguridad
• monitorización
• logging
• gobernanza
• disponibilidad
• DR

Hito de certificación

🎓 AZ-104 — Azure Administrator Associate

Encaja bien en la hoja de ruta porque combina cómputo, almacenamiento, redes, identidad y administración en Azure.

🔑 Fase 10 — Entra ID e identidad híbrida

Duración: 3–5 meses

On-Prem AD
    │
    │ Hybrid Identity
    ▼
Microsoft Entra ID
    │
    ▼
Azure
```

Temas:

• • arquitectura de identidad

• • autenticación

• • autorización

• • federación

• • identidad híbrida

• • acceso condicional

• • RBAC

• • identidades de servicio

• • seguridad

🏢 Fase 11 — Multi-CPD / arquitectura de centros de datos

Duración: 4–6 meses

Esta fase combina muchos de los temas anteriores.

                    Global Services
                           │
             ┌─────────────┴─────────────┐
             │                           │
            DC1                         DC2
             │                           │
      ┌──────┼──────┐             ┌──────┼──────┐
      │      │      │             │      │      │
   Compute Network Storage      Compute Network Storage
      │                           │
      └──────────────┬────────────┘
                     │
                 Services
                     │
          Monitoring / Logging / IAM

Temas

• dominios de fallo
• redundancia de sedes
• balanceo de carga
• replicación
• copias de seguridad
• RPO
• RTO
• DR
• split brain
• quórum
• particionamiento de red
• dependencias entre servicios
• planificación de capacidad

Aquí es donde el trabajo de arquitectura anterior se vuelve práctico.

📡 AÑO 5 — Observabilidad, platform engineering e IA

📅 Periodo: septiembre de 2030 – agosto de 2031

📊 Fase 12 — Observabilidad moderna

Duración: 4–6 meses

                 Observability
                      │
          ┌───────────┼───────────┐
          │           │           │
       Metrics       Logs       Traces
          │           │           │
     Prometheus     Graylog   OpenTelemetry
          │           │           │
          └───────────┼───────────┘
                      │
                    Grafana

Temas

• métricas
• logs
• trazas
• correlación
• sistemas distribuidos
• Prometheus
• Grafana
• Graylog
• OpenTelemetry
• alertas
• análisis de incidentes

El objetivo es pasar de:

«El servidor está en rojo.»

a:

«El servicio de cara al cliente se degradó porque la dependencia X sufrió latencia después de que el componente Y agotara el recurso Z.»

🤖 Fase 13 — IA y AIOps

Duración: continua

Temas

• LLM
• prompt engineering
• API de IA
• RAG
• embeddings
• bases de datos vectoriales
• LLM locales
• agentes de IA
• MCP
• diagnóstico asistido por IA
• documentación asistida por IA
• automatización asistida por IA
• correlación de incidentes
• AIOps

Ejemplo

Monitoring Alert
       │
       ▼
Context Collection
       │
       ▼
AI Analysis
       │
       ▼
Possible Causes
       │
       ▼
Diagnostic Tests
       │
       ▼
Human Validation
       │
       ▼
Automation

La IA debería hacerme más rápido.

No debería volverme un vago intelectual.

🏠 El homelab: mi entorno de entrenamiento práctico

El homelab es una parte importante de la hoja de ruta, pero a propósito tiene menos prioridad que los propios objetivos de aprendizaje.

El plan de aprendizaje va primero.

El homelab existe para convertir la teoría en experiencia práctica.

Mi hardware:

• 🖥️ 3 servidores físicos
• 🖥️ 2 PC de torre

Es más que suficiente para montar un laboratorio de infraestructura sorprendentemente capaz.

🧪 Regla n.º 1 del homelab

No te limites a ejecutar servicios. Construye escenarios.

En lugar de:

«Tengo un clúster de Kubernetes.»

quiero:

«He montado un clúster de Kubernetes, he tumbado un nodo a propósito, he observado el fallo, he analizado el comportamiento y he documentado la recuperación.»

Es una experiencia de aprendizaje completamente distinta.

🖥️ Uso del homelab por fase de aprendizaje

💥 El programa «Rómpelo a propósito»

Una de las partes más importantes del homelab será provocar fallos deliberadamente.

Ejemplos:

• romper el DNS
• llenar un sistema de archivos
• detener servicios críticos
• romper certificados
• cortar la conectividad de red
• simular fallos de almacenamiento
• tumbar nodos de Kubernetes
• romper el RBAC
• romper la replicación de Active Directory
• romper la ingesta de Graylog
• generar un volumen de logs excesivo
• introducir latencia
• simular pérdida de paquetes

Después:

Failure
  ↓
Symptoms
  ↓
Evidence
  ↓
Hypotheses
  ↓
Tests
  ↓
Root Cause
  ↓
Fix
  ↓
Prevention
  ↓
Documentation

Aquí es donde espero que ocurra buena parte del aprendizaje real.

📚 El homelab debe producir documentación

Todo proyecto serio debería dejar algo tras de sí.

homelab/
│
├── ansible/
├── terraform/
├── opentofu/
├── kubernetes/
├── monitoring/
├── logging/
├── security/
├── networking/
│
├── architecture/
│   ├── network.md
│   ├── storage.md
│   ├── logging.md
│   ├── kubernetes.md
│   └── disaster-recovery.md
│
└── incidents/
    ├── dns-failure.md
    ├── storage-failure.md
    ├── ad-failure.md
    └── kubernetes-node-failure.md

Así el homelab se convierte en un portfolio práctico de trabajo de ingeniería.

🤖 La IA como parte del proceso de aprendizaje

ChatGPT y Claude formarán parte del flujo de trabajo durante los cinco años.

Pero el flujo de trabajo importa.

Mal flujo de trabajo

Problem
 ↓
Ask AI
 ↓
Copy solution
 ↓
Done

Mejor flujo de trabajo

Problem
 ↓
My own hypothesis
 ↓
AI challenge
 ↓
Alternative hypotheses
 ↓
Diagnostic tests
 ↓
Evidence
 ↓
My decision
 ↓
Implementation
 ↓
Validation

Algunas de las preguntas que quiero hacer con regularidad:

«¿Qué se me escapa?»

«¿Cuáles son tres causas raíz plausibles?»

«¿Qué prueba permitiría distinguir estas hipótesis?»

«Revisa con ojo crítico tu respuesta anterior.»

«¿Qué suposiciones estás haciendo?»

Así la IA se convierte en un sparring técnico en lugar de un generador de comandos.

🏆 Estrategia de certificación

Las certificaciones son útiles, pero deben validar la hoja de ruta, no dictarla.

La regla es sencilla:

Nada de certificaciones solo porque existen.

Una certificación debería:

• cubrir una laguna real de conocimiento
• aportar estructura
• validar habilidades prácticas
• ser útil profesionalmente

Si no, probablemente el propio proyecto vale más.

📈 Los niveles de capacidad

También quiero medir el progreso por capacidades y no solo por certificados.

Nivel 1 — Operador

Sé seguir la documentación y operar el sistema.

Nivel 2 — Administrador

Entiendo la configuración y sé resolver los problemas habituales.

Nivel 3 — Ingeniero

Entiendo la arquitectura, las dependencias y los modos de fallo.

Nivel 4 — Diseñador

Sé diseñar el sistema y justificar las decisiones de arquitectura.

Nivel 5 — Arquitecto

Sé diseñar sistemas complejos que abarcan varias tecnologías y dominios de fallo.

En esencia, la hoja de ruta a cinco años consiste en pasar de:

Operator
   ↓
Administrator
   ↓
Engineer
   ↓
Designer
   ↓
Architect

🧠 Lo que quiero saber hacer dentro de cinco años

Imagina que alguien me plantea este problema:

«Operamos varios miles de sistemas Windows y Linux repartidos en varios centros de datos. Necesitamos identidad, monitorización, logging, seguridad y automatización centralizados, alta disponibilidad y recuperación ante desastres. Diseña la plataforma.»

Quiero ser capaz de razonar sobre:

• Linux
• Windows
• Active Directory
• DNS
• redes
• seguridad
• almacenamiento
• logging
• monitorización
• observabilidad
• Kubernetes
• cloud
• identidad
• automatización
• HA
• DR
• capacidad
• dependencias
• dominios de fallo

Y, sobre todo:

Quiero entender por qué la arquitectura es como es.

🚀 La filosofía final

Siempre habrá otra tecnología.

Otra versión de Kubernetes.

Otra plataforma cloud.

Otra distribución de Linux.

Otro sistema de monitorización.

Otro framework de IA.

Otra certificación.

Y otro comando que habré olvidado mañana por la mañana.

Y no pasa nada.

Las tecnologías cambian.

Los principios de ingeniería cambian mucho más despacio.

Los sistemas siguen teniendo:

• dependencias
• interfaces
• modos de fallo
• fronteras de seguridad
• límites de capacidad
• requisitos de disponibilidad
• flujos de datos
• restricciones operativas

Ahí es donde quiero invertir mi esfuerzo de aprendizaje.

🐧 Menos memorizar comandos.

🏗️ Más arquitectura.

🔍 Más resolución de problemas.

🤖 Más automatización.

☁️ Más pensamiento de infraestructura.

🧠 Más comprensión.

Y sí…

Seguiré teniendo abiertos a la vez un terminal, una chuleta, la documentación, ChatGPT y Claude.

Porque:

Ser un buen ingeniero de infraestructura no significa acordarse de todo.

Significa saber qué importa, saber cómo encontrar el resto y saber comprobar si la respuesta es realmente correcta.

😎 Ahora, a construirlo. Y, de vez en cuando, a romperlo.