Roadmap DevOps para principiantes: la guia completa (2026)

Pase tres meses “aprendiendo DevOps” viendo playlists de YouTube en desorden. Terraform un dia, Kubernetes al siguiente, un tutorial random de Jenkins el domingo por la manana. Tenia marcadores en siete carpetas, labs a medio terminar en tres proveedores cloud distintos, y la creciente sospecha de que no estaba avanzando en absoluto.

Tenia razon. No estaba progresando. Estaba coleccionando temas como cromos — muchos, pero ninguno completo.

El problema no era el esfuerzo. Era el orden. DevOps tiene una cadena de dependencias, y yo la estaba ignorando por completo. No puedes aprender Kubernetes de forma significativa sin entender contenedores. Los contenedores son confusos si no conoces Linux. Los pipelines de CI/CD no tienen sentido si nunca has usado Git en serio. Todo se construye sobre algo mas, y los roadmaps que encuentras online o ignoran ese hecho o lo entierran bajo cincuenta tecnologias dispuestas en un diagrama que da miedo.

Asi que aqui esta el roadmap que me hubiera gustado recibir. Nueve fases, en orden, con estimaciones de tiempo honestas y orientacion clara sobre que ignorar.

Por que DevOps vale la inversion

Antes de invertir meses en esto, la pregunta obvia: vale la pena?

Respuesta corta — si, y no solo por los salarios (aunque esos no hacen dano). Las habilidades DevOps te hacen fundamentalmente mas util. Dejas de ser la persona que escribe codigo y lo lanza por encima del muro. Te conviertes en la persona que entiende como el software se construye, se prueba, se despliega y se mantiene vivo en produccion.

En cada equipo en el que he trabajado, la persona que entendia tanto el codigo como el pipeline tenia una influencia desproporcionada. No por un titulo. Porque podia depurar problemas que cruzaban fronteras que nadie mas queria tocar.

El campo sigue creciendo. La adopcion del cloud no se esta frenando. Las empresas que migraron a la nube hace cinco anos ahora intentan optimizar lo que construyeron a toda prisa. Necesitan personas que entiendan infraestructura, automatizacion y fiabilidad — no solo uno de esos aspectos, sino las conexiones entre ellos.

El Roadmap: nueve fases, en orden

Fase 1: Fundamentos de Linux (3-4 semanas)

Todo en DevOps corre sobre Linux. Contenedores, servidores, runners de CI, instancias cloud — Linux debajo, casi siempre.

Necesitas la linea de comandos. No dominio total, pero comodidad real. Navegar el sistema de archivos, editar archivos con nano o vim, gestionar procesos, leer logs, entender permisos de archivos, escribir scripts de shell basicos. Cuando algo se rompe a las 2 de la manana, nadie abre una interfaz grafica.

Consigue una VM de Ubuntu o usa WSL en Windows. Rompe cosas ahi dentro. Instala paquetes, configura servicios, mata procesos que no deberias haber matado, averigua que salio mal. Esa incomodidad es el aprendizaje.

Estimacion: 3-4 semanas a 30-45 minutos por dia.

Fase 2: Git y control de versiones (1-2 semanas)

Git no es solo “guardar tu codigo.” En DevOps, Git es el disparador de todo. Un push a main lanza un build. Un PR mergeado despliega en staging. Los patrones GitOps usan Git como unica fuente de verdad para estados completos de infraestructura.

Aprende branching, merging, rebasing, resolucion de conflictos. Entiende que es realmente un pull request — no la interfaz de GitHub, sino el flujo de trabajo que representa. Aprende a leer un git log y descifrar que paso.

No necesitas memorizar cada flag. Necesitas entender el modelo — los commits son snapshots, las branches son punteros, los merges combinan historiales. Una vez que el modelo hace clic, los comandos siguen solos.

Estimacion: 1-2 semanas.

Fase 3: Fundamentos de redes (2-3 semanas)

Me salte redes al principio. Error monumental. La mitad del debugging en DevOps es debugging de redes.

Necesitas: direccionamiento IP y subredes, TCP vs UDP, resolucion DNS, HTTP/HTTPS y como funciona TLS a grandes rasgos, puertos y firewalls, load balancers (que hacen, no como construir uno).

Cuando un pod no puede alcanzar una base de datos, cuando un despliegue funciona en local pero da timeout en staging, cuando un health check falla sin razon aparente — casi siempre es red. Cada hora que inviertas aqui paga dividendos durante anos.

Estimacion: 2-3 semanas.

Fase 4: Pipelines de CI/CD (3-4 semanas)

Aqui es donde DevOps empieza a sentirse como DevOps. Integracion Continua y Entrega Continua — automatizar el camino del commit al software en ejecucion.

Empieza con GitHub Actions. Es gratis, esta integrado donde tu codigo ya vive, y la sintaxis YAML es accesible. Construye un pipeline que ejecute tests en cada push. Luego anade un paso que construya un artefacto. Luego anade despliegue a un entorno de staging.

Los conceptos importan mas que la herramienta. Pipelines, stages, jobs, artefactos, variables de entorno, gestion de secretos. Una vez que entiendes todo esto en GitHub Actions, traducir a GitLab CI, Jenkins o CircleCI es mayormente sintaxis.

Estimacion: 3-4 semanas.

Fase 5: Contenedores y Docker (3-4 semanas)

Los contenedores cambiaron todo sobre como se entrega el software. En vez de “funciona en mi maquina,” empaquetas la maquina con la aplicacion.

Aprende a escribir Dockerfiles. Construye imagenes. Ejecuta contenedores. Entiende layers, cache, multi-stage builds. Aprende docker-compose para setups locales multi-servicio. Entiende la diferencia entre una imagen y un contenedor — suena trivial pero la confusion provoca errores reales.

Luego conecta esto con la Fase 4. Construye un pipeline que cree una imagen Docker, la suba a un registry, y la despliegue en algun lugar. Ese es un flujo de trabajo real. Eso es lo que las empresas hacen de verdad.

Estimacion: 3-4 semanas.

Fase 6: Infrastructure as Code (4-5 semanas)

Hacer clic por las consolas de AWS para crear recursos esta bien para aprender. Es terrible para produccion. Infrastructure as Code significa que defines tus servidores, bases de datos, redes y todo lo demas en archivos que se pueden versionar, revisar y reproducir.

Terraform es el estandar. Aprende la sintaxis HCL, providers, resources, gestion del state, modulos. Empieza simple — aprovisiona una instancia EC2 con un security group. Luego escala hasta un VPC con subredes, un load balancer de aplicacion y un auto-scaling group.

El cambio mental importa mas que la sintaxis. Dejas de pensar “voy a configurar este servidor” y empiezas a pensar “voy a describir el estado deseado y dejar que la herramienta converja.” Ese cambio es fundacional. Si has estado aprendiendo cloud computing desde cero, Terraform es donde esos conceptos se vuelven tangibles.

Estimacion: 4-5 semanas.

Fase 7: Monitoreo y observabilidad (2-3 semanas)

Desplegar software es la mitad del trabajo. Saber si esta sano es la otra mitad.

Aprende los tres pilares: metricas (Prometheus/Grafana), logs (ELK o Loki), y trazas (Jaeger o similar). No necesitas experiencia profunda en cada herramienta. Necesitas entender por que mirarias metricas vs logs vs trazas para diferentes problemas.

Configura Prometheus y Grafana para una aplicacion pequena. Crea dashboards. Configura alertas. Vive ese primer momento en que una alerta se dispara a una hora rara y puedes diagnosticar el problema desde un dashboard en vez de hacer SSH a servidores al azar. Esa sensacion sola justifica el esfuerzo.

Estimacion: 2-3 semanas.

Fase 8: Plataforma cloud (4-6 semanas)

Elige una. AWS, GCP o Azure. No intentes aprender las tres a la vez — yo cometi ese error y es la via rapida hacia el conocimiento superficial en todo.

AWS tiene la mayor cuota de mercado y mas ofertas de empleo. GCP tiene probablemente la mejor experiencia para desarrolladores. Azure domina en empresas grandes. Cualquiera es una eleccion valida. Simplemente elige una y ve a fondo.

Concentrate en los servicios esenciales: computo (EC2/VMs), almacenamiento (S3/blobs), redes (VPCs, subredes, security groups), IAM, y bases de datos gestionadas. Saca una certificacion basica si quieres un aprendizaje estructurado — te obliga a cubrir areas que tendrias tendencia a saltarte.

Estimacion: 4-6 semanas.

Fase 9: Kubernetes (5-7 semanas)

Kubernetes viene al final por una razon. Asume que conoces Linux, redes, contenedores y cloud. Sin esas bases, Kubernetes es solo archivos YAML confusos y mensajes de error misteriosos.

Empieza con los conceptos: pods, deployments, services, ingress, namespaces, ConfigMaps, secrets. Usa Minikube o kind en local. Despliega una aplicacion simple. Escalala. Rompela. Arreglala.

Luego aprende el lado operacional: resource limits, health checks, rolling updates, RBAC. Aqui es donde todas las fases anteriores convergen. Tus habilidades en Linux depuran pods. Tu conocimiento de redes explica por que los services no se conectan. Tu experiencia en IaC te permite aprovisionar el cluster en si.

Estimacion: 5-7 semanas.

Que ignorar como principiante

Esto es tan importante como lo que hay que aprender. Decir no a las distracciones brillantes es la mitad de la batalla.

Ignora las estrategias multi-cloud. Aprende un cloud a fondo. Multi-cloud es una decision organizacional, no una habilidad de principiante.

Ignora el service mesh (Istio, Linkerd). Importante para sistemas a gran escala. Completamente innecesario cuando estas aprendiendo. Sabras cuando lo necesites.

Ignora el tooling complejo de GitOps (ArgoCD, Flux). Aprende los conceptos primero. Las herramientas tienen mas sentido despues de hacer despliegues manuales y sentir el dolor que resuelven.

Ignora escribir Helm charts complejos desde cero. Usa charts existentes para entender el patron. Escribir charts complejos es una habilidad de nivel intermedio, no un punto de partida.

Ignora el tuning de rendimiento y la optimizacion de costos. Haz que las cosas funcionen primero. Optimiza despues. La optimizacion prematura es la raiz de todo mal, y eso aplica tambien a las rutas de aprendizaje.

Estimaciones de tiempo realistas

Sumando todo: el roadmap completo son aproximadamente 27-39 semanas. Digamos de seis a nueve meses si estas aprendiendo junto a un trabajo a tiempo completo, dedicando 30-45 minutos la mayoria de los dias.

No es rapido. Pero es honesto. Cualquiera que te prometa “DevOps en 30 dias” te esta vendiendo un speedrun por un campo que requiere profundidad. Puedes absolutamente conseguir tu primer puesto relacionado con DevOps antes de terminar cada fase — la mayoria empieza a postular alrededor de la Fase 6 o 7 — pero el roadmap completo construye competencia genuina.

El truco es la consistencia sobre la intensidad. Un habito de aprendizaje de 15 minutos al dia te llevara mas lejos que los maratones de fin de semana que se apagan en marzo. Sesiones cortas, todos los dias, apilando conocimiento sobre el de ayer. Asi es como el roadmap funciona en la practica.

El bucle Descubrir-Practicar-Evaluar

Para cada fase, sugiero un bucle simple de tres pasos.

Descubrir. Leer documentacion, ver un tutorial enfocado, estudiar un concepto. Mantenerlo corto — 15 a 20 minutos de input.

Practicar. Aplicar inmediatamente lo que acabas de aprender. Levantar un recurso, escribir un archivo de configuracion, construir un pipeline. Manos a la obra, en un entorno real, no un examen de opcion multiple.

Evaluar. Ponerte a prueba. Puedes explicar lo que acabas de hacer sin mirar tus notas? Puedes hacerlo de nuevo de memoria? Donde te atascaste? Ese es el foco de tu proxima sesion.

Este bucle te mantiene honesto. Es facil ver tutoriales y sentir que estas aprendiendo. El paso de evaluacion te obliga a confrontar lo que realmente retuviste versus lo que simplemente paso frente a tus ojos.

FAQ

Necesito un titulo en informatica para aprender DevOps?

No. Mi formacion es en un campo completamente diferente. Lo que necesitas es comodidad con la linea de comandos, disposicion para romper cosas, y la paciencia para leer mensajes de error con atencion. Un titulo en informatica te da bases que ayudan, pero son bases que puedes construir por tu cuenta. La mayoria de los mejores ingenieros DevOps que conozco son autodidactas o vienen de campos adyacentes.

Deberia aprender DevOps o cloud computing primero?

Se solapan bastante, pero yo sugeriria empezar con el roadmap de DevOps hasta la Fase 7 antes de profundizar en cloud. La razon es practica: Linux, Git, redes, CI/CD, contenedores, IaC y monitoreo son habilidades cloud-agnosticas que se transfieren a todas partes. El conocimiento especifico de cloud es la capa que construyes encima. Dicho esto, naturalmente acumularas bases de cloud por el camino — no es una frontera rigida.

Como practico sin gastar dinero en recursos cloud?

La mayoria de las primeras fases son gratis. Las VMs de Linux son gratis. Git es gratis. GitHub Actions tiene un tier gratuito generoso. Docker corre en local. Para cloud y Kubernetes, usa cuentas de tier gratuito (AWS y GCP ofrecen ambos), y siempre configura alertas de facturacion. Puedes aprender una cantidad impresionante dentro de los limites del tier gratuito si eres disciplinado limpiando recursos.

DevOps es solo para desarrolladores backend?

Ya no. Los desarrolladores frontend se benefician de entender CI/CD y contenedores. Los ingenieros de QA necesitan cada vez mas conocimiento de pipelines. Incluso los product managers que entienden los flujos de despliegue toman mejores decisiones sobre la planificacion de releases. DevOps es menos un titulo de puesto y mas un conjunto de practicas — cualquier persona que toque el proceso de entrega de software se beneficia de entenderlo.

Listo para empezar tu camino de aprendizaje DevOps? Unete al acceso anticipado —>