Roadmap de habilidades de DevOps engineer para 2026

DevOps en 2026 es platform engineering más SRE más la reputación residual de “la persona de CI/CD” que algunas empresas todavía conservan. Este roadmap cubre el stack moderno — Kubernetes, Terraform, observabilidad, SLOs, secrets — y un plan de 12 meses para convertirse en un DevOps/platform engineer contratable.

Muchas empresas dejaron de llamar al puesto “DevOps” y ahora lo llaman “platform engineer”, “SRE” o “infrastructure engineer”. El trabajo se solapa mucho. Si sabe operar un cluster de Kubernetes, escribir Terraform que no filtre credenciales, entregar CI/CD que a los desarrolladores realmente les guste y responder a un aviso a las 3 de la madrugada sin empeorarlo, encontrará un puesto bajo al menos uno de esos títulos.

Quién es un DevOps engineer en 2026

Un DevOps/platform engineer es dueño del camino del código a producción. En concreto:

• Diseña y mantiene pipelines de CI/CD que los desarrolladores pueden usar sin abrir tickets.
• Es dueño de la infraestructura cloud como código — Terraform/Pulumi, con PRs revisables y un state store que no pierde datos.
• Opera el cluster de Kubernetes de producción (o su equivalente serverless) y está de on-call para él.
• Es dueño de la observabilidad: métricas, logs, traces, alertas, runbooks, error budgets.
• Gestiona secrets, IAM, network policies y las partes aburridas de seguridad que nadie más se ofrece a hacer.

DevOps junior: escribe un GitHub Action, depura un pipeline. Mid-level: es dueño de la infra de un servicio de extremo a extremo, incluyendo sus dashboards. Senior: diseña la plataforma sobre la que construyen varios equipos, define los SLOs, impulsa el proceso de incident review.

Stack core — qué aprender de verdad

Soft skills y pensamiento de sistemas

• Empatía con el desarrollador. La plataforma que construye es para otros ingenieros. Si tienen que abrir tickets para usarla, construyó la plataforma equivocada.
• Disciplina de postmortem sin culpa. Las caídas son sistémicas. Lidere con el ejemplo: asuma su parte del fallo, céntrese en arreglos sistémicos.
• Conciencia de costes. Las facturas de cloud se descontrolan rápido. Un DevOps engineer senior recorta un 20–30% de la factura a los pocos meses de incorporarse en la mayoría de las empresas.
• Lo aburrido es bueno. La infraestructura aburrida es infraestructura fiable. Resista la tentación de usar la herramienta más nueva.
• La documentación como hábito. Runbooks, diagramas de arquitectura, decision records. El ingeniero que documenta es dueño de la capa.

Plan sugerido de 3 / 6 / 12 meses

Meses 1–3: Linux + Docker + fundamentos cloud

• Sentirse cómodo en la línea de comandos. Monte un homelab o una cuenta cloud de free-tier.
• Aprender Docker como es debido: multi-stage builds, redes, volúmenes, Compose.
• Elegir un cloud. Desplegar un servicio pequeño manualmente. Aprender IAM, VPC y networking básico.

Meses 4–6: Kubernetes + IaC

• Operar un cluster de Kubernetes (k3s, kind o gestionado). Desplegar una app real con ingress, secrets y persistent volumes.
• Aprender Terraform. Gestionar su cluster, su DNS y su secrets store con código.
• Montar un pipeline de CI/CD (GitHub Actions o GitLab CI) que construya, teste y despliegue a su cluster.
• Leer “The Phoenix Project” y el “Google SRE Book” (gratis online).

Meses 7–12: observabilidad, SRE, entrevistas

• Cablear Prometheus + Grafana + Loki + Alertmanager en su cluster. Construir un dashboard real.
• Definir un SLO para su app y un error budget. Ejecutar un experimento de chaos que lo agote.
• Practicar diseño de sistemas de DevOps: diseñar una plataforma de CI/CD, diseñar un pipeline de logging, diseñar un despliegue multi-región.
• Postular con un portafolio que incluya un repo de GitHub con IaC completa, CI/CD y capturas de dashboards.

Proyectos paralelos para construir

• Una plataforma GitOps completa en un repo. Terraform para el cluster, ArgoCD para las apps, el stack de Prometheus para observabilidad. Demuestra todo en conjunto.
• Un layout de IaC multi-entorno. Dev/staging/prod con división por workspace o directorio, detección de drift, plan-on-PR. Muestra estructura del mundo real.
• Un operator de Kubernetes (pequeño). Escriba un controller para un custom resource. Demuestra profundidad más allá del kubectl de superficie.
• Un writeup de optimización de costes. Tome una factura real o simulada y muestre los pasos para recortarla un 30%. FinOps es cada vez más parte del puesto.

SLOs, error budgets y cordura en el on-call

Las prácticas SRE que separan a los DevOps engineers senior de los ingenieros “que construyen pipelines” provienen de un cambio mental: no se puede maximizar la fiabilidad y la velocidad de funcionalidades simultáneamente, así que hay que hacer el trade-off explícito.

• Elija un SLI por servicio. Disponibilidad para una API. Latencia de extremo a extremo para un flujo de usuario crítico. Tasa de éxito de jobs para un worker. Elija uno que se mapee a la experiencia del usuario, no a métricas internas.
• Fije el SLO en el nivel correcto. 99,9% suena razonable hasta que se da cuenta de que son 43 minutos de presupuesto de downtime al mes. 99,99% son 4 minutos al mes, y a ese nivel no se puede desplegar cada semana.
• Use el error budget. Si tiene 30 minutos de presupuesto de downtime este trimestre, gaste 20 en despliegues arriesgados. Si lo agota, congele los despliegues de funcionalidades hasta la siguiente ventana.
• Los runbooks ganan a los héroes. Cada alerta enlaza a un runbook con los tres primeros comandos de diagnóstico. El ingeniero de on-call que nunca ha tocado este servicio no debería tener que avisar al experto a las 3 de la madrugada.
• Avise lo accionable, no lo informativo. Una alerta que no requiere acción humana no debería avisar. Muévala a un dashboard, a un informe semanal, o elimínela. La fatiga de pager es el asesino silencioso de la calidad del on-call.
• Postmortems sin culpa. Los action items se centran en el sistema, no en la persona. “El ingeniero X desplegó sin staging” no es una causa raíz; “el pipeline permitió desplegar a prod sin staging en verde” sí lo es.
• Game days. Programe uno por trimestre, rompa algo a propósito en staging, ejecute el incidente. La habilidad de incident command se degrada rápido sin práctica.

En las entrevistas senior, la pregunta rara vez es “¿sabe K8s?”. Es “cuénteme el último incidente de producción que gestionó”. Tenga lista la cronología, los pasos de diagnóstico, el arreglo inmediato y el cambio sistémico.

Cómo conseguir el puesto de DevOps

• Keywords del currículum. Kubernetes, Terraform, AWS o GCP, herramienta de CI/CD, Prometheus, Grafana, OpenTelemetry, Helm, GitHub Actions, ArgoCD si aplica.
• Un repo con todo cableado. El artefacto de mayor señal — una plataforma desplegable y documentada.
• Rondas de entrevista: troubleshooting de Linux/networking, diseño de sistemas (construir un pipeline de CI/CD u observabilidad), conductual con historias de on-call, a veces un take-home (escribir un módulo de Terraform).
• La ronda de troubleshooting. A menudo en vivo: “aquí hay un deployment de Kubernetes roto, arréglelo”. Practique con clusters rotos a propósito.
• La historia de on-call. Tenga 4–5 historias de incidentes listas. Qué se rompió, cómo lo encontró, qué cambió, qué arreglo sistémico siguió.

FAQ