¿Cómo dar el salto a ingeniería DevOps desde otro sector?

El punto de partida honesto

DevOps no es un puesto de nivel inicial, ni realmente una disciplina en la que puedas certificarte como lo harías, por ejemplo, en contabilidad. No hay colegio profesional, ni título protegido, ni examen que abra la puerta por sí solo. Eso es tanto la buena como la mala noticia. Buena, porque nadie puede cerrarte el paso sobre el papel. Mala, porque no hay un temario fijo que completar y ya está —tienes que construir un cuerpo de evidencia práctica tú mismo, y el responsable de contratación debe estar convencido de que es real.

La mayoría de quienes se incorporan a DevOps vienen de una de dos direcciones: del desarrollo de software (escribir código, trabajar en un equipo que publica con regularidad, aprender sobre pipelines de despliegue en el camino) o de administración de sistemas e infraestructura (gestionar servidores, redes y más tarde cuentas en la nube, y aprender código y automatización en el camino). Si vienes de otro sitio completamente distinto —soporte técnico, QA sin automatización, un puesto no técnico— el cambio es posible pero lleva más tiempo, y deberías planificarlo con honestidad en lugar de suponer que seis meses bastarán.

Qué se transfiere realmente

Sé específico contigo mismo sobre cuáles de estas cosas ya tienes, porque el optimismo vago no sobrevive a una entrevista.

• Fundamentos de Linux. Si puedes moverte por una shell, gestionar usuarios y permisos, leer logs y entender procesos y servicios (systemd, en la mayoría de entornos actuales), esa es una base real y transferible. La mayor parte del trabajo DevOps ocurre en Linux, incluso cuando la interfaz es una consola en la nube.
• Scripting. Bash y Python son los dos lenguajes que verás más a menudo —Bash para pegamento y automatización rápida, Python para cualquier cosa con más lógica (o Go, en algunas empresas de herramientas de infraestructura). Si has escrito scripts para automatizar una tarea repetitiva en cualquier trabajo, esa experiencia cuenta, aunque el trabajo en sí no fuera técnico.
• Control de versiones. Git, usado correctamente —ramas, pull requests, resolver conflictos— no solo "he usado GitHub para descargar algo". Esto es conocimiento asumido, no un punto de venta, así que domínalo antes de aplicar.
• Conceptos básicos de redes. DNS, HTTP, balanceadores de carga, firewalls a nivel conceptual. No necesitas una certificación de redes, pero sí debes poder explicar por qué una petición podría fallar entre un balanceador de carga y un servicio backend.
• Trabajar en un entorno con consecuencias en producción. Si has dado soporte a un sistema en vivo, estado en un turno de guardia o lidiado con una caída bajo presión de tiempo en cualquier puesto técnico, esa experiencia está más cerca de la realidad DevOps que mucho estudio teórico.
• Exposición a la nube de cualquier tipo. Incluso uso básico de AWS, Azure o GCP —desplegar un proyecto personal, gestionar almacenamiento y cómputo para un hobby— vale más de lo que podría parecer, porque gran parte del trabajo ahora ocurre dentro de una de esas tres plataformas.

Qué no se transfiere, por muy senior que fueras en tu campo anterior: experiencia en gestión de proyectos, un genérico "se me da bien la tecnología," y haber usado una herramienta como consumidor en lugar de haberla configurado o automatizado. Un responsable de contratación leyendo un CV de DevOps puede distinguir entre alguien que ejecutó terraform apply sobre infraestructura que escribió y alguien que vio a otra persona hacerlo.

La ruta de certificaciones y cualificaciones

No hay licencia ni colegio profesional que controle el acceso a esta ocupación, pero sí hay un conjunto reconocido de certificaciones de proveedores que tienen peso real con los responsables de contratación, porque al menos prueban que has hecho los laboratorios.

• Certificaciones de plataformas cloud — AWS Certified DevOps Engineer – Professional, el Azure DevOps Engineer Expert de Microsoft, o el Professional Cloud DevOps Engineer de Google. Estas son lo más cercano a una cualificación reconocida en este campo. No son fáciles, y asumen que ya tienes experiencia práctica con la plataforma, no solo material de estudio —los exámenes incluyen preguntas de escenarios que son difíciles de aprobar solo con teoría.
• Certified Kubernetes Administrator (CKA), de la Cloud Native Computing Foundation. Kubernetes aparece en una gran proporción de ofertas de empleo DevOps ahora, y el CKA es una de las pocas certificaciones en este espacio que es realmente práctica —administras un clúster real durante el examen, no es de opción múltiple.
• HashiCorp Certified: Terraform Associate. La infraestructura como código es casi universal en este puesto ahora, y Terraform es la herramienta que la mayoría de anuncios nombran específicamente.

Ninguna de estas reemplaza un portafolio. Los empleadores que contratan ingenieros DevOps generalmente quieren ver trabajo, no solo credenciales —un perfil de GitHub con código de infraestructura real, un laboratorio casero documentado, una entrada de blog explicando cómo construiste un pipeline CI/CD para un proyecto personal. Si solo puedes hacer una cosa antes de empezar a aplicar, construye algo que puedas mostrar y explicar en detalle, luego obtén la certificación que lo complementa.

Qué debe superar tu candidatura

Una candidatura DevOps de cambio de carrera enfrenta una objeción específica y recurrente: el lector asume que eres un generalista que vio algunos tutoriales, no alguien en quien se puede confiar con infraestructura de producción y un turno de guardia. Tienes que responder esa objeción directamente, porque el CV solo no lo hará.

El primer problema suele ser la forma del CV. Si tu título de trabajo más reciente no tiene nada que ver con infraestructura, ingeniería o software, un reclutador que escanea rápidamente pasará de largo antes de llegar al párrafo donde explicas tu proyecto Terraform. Pon la evidencia relevante —las herramientas, el proyecto, la certificación— en el primer tercio de la página, no enterrada bajo un historial laboral cronológico que empieza con títulos irrelevantes.

El segundo problema es profundidad versus amplitud. Quienes cambian de carrera a menudo listan cada herramienta que tocaron una vez (Docker, Jenkins, Ansible, Prometheus, Grafana, Kubernetes) sin poder ir dos preguntas a fondo en ninguna. Los entrevistadores en este campo preguntan "explícame qué pasa cuando este pipeline se ejecuta" o "qué comprobarías primero si este despliegue fallara a las 2 de la madrugada" —preguntas que separan a quienes configuraron algo una vez de quienes lo entienden. Escoge menos herramientas y conócelas bien en lugar de listar todo lo que hayas mirado por encima.

El tercer problema es la historia. Necesitas una respuesta coherente a "por qué DevOps, por qué ahora," y debe ser sobre el trabajo, no sobre escapar de tu campo anterior. "Yo era quien automatizaba todo lo que mi equipo hacía manualmente" es una respuesta real. "Quiero un cambio y DevOps paga bien" es cierto para mucha gente pero no sobrevive a una entrevista.

Cuánto tarda esto realmente

No hay cifra publicada fiable sobre cuánto tarda un cambio de carrera a DevOps, y desconfía de quien cite una, porque depende enormemente de tu punto de partida. Lo que se puede decir con honestidad:

Si ya eres desarrollador de software, moverte lateralmente a un puesto DevOps o de ingeniería de plataformas es realistamente cuestión de meses —estás ampliando habilidades que ya tienes, y muchas empresas contratan desarrolladores específicamente para estos puestos porque pueden programar.

Si eres administrador de sistemas o ingeniero de redes moviéndote a DevOps cloud-native, el cronograma depende principalmente de cuánto scripting e infraestructura como código ya haces. Algunos hacen este cambio en menos de un año; otros tardan más porque el cambio de gestionar servidores físicos o virtuales a gestionar todo como código es un cambio genuino en cómo piensas sobre el trabajo, no solo un nuevo conjunto de herramientas.

Si vienes de un campo no técnico, sé realista: esto es comúnmente un proyecto de uno a dos años, no el resultado de un bootcamp de fin de semana, si estás construyendo desde casi cero —aprender Linux, un lenguaje de scripting, fundamentos de cloud y un portafolio, mientras probablemente trabajas en tu empleo actual. Existen bootcamps y cursos cortos y algunas personas sí consiguen trabajo tras ellos, pero el mercado de puestos "DevOps" etiquetados como junior es escaso; la mayoría de ofertas de empleo usando ese título esperan algo de experiencia previa en infraestructura o desarrollo, porque el puesto está aguas abajo de ambas disciplinas en lugar de ser un punto de entrada principiante a cualquiera de ellas.

Qué hacer a continuación

Averigua con honestidad a cuál de los dos puntos de partida estás más cerca —desarrollador o infraestructura— y construye deliberadamente la mitad que falta: los desarrolladores necesitan Linux, redes e infraestructura como código; los administradores de sistemas necesitan profundidad en scripting y experiencia con pipelines CI/CD. Construye un proyecto real del que puedas hablar en detalle, haz la certificación que lo complementa y reescribe tu CV para que la evidencia relevante esté en el primer tercio de la página, no en el último. Cuando estés listo para aplicar, jobmarket.pro lee cada anuncio contra tu perfil real y te dice, antes de enviar nada, dónde encajas genuinamente y dónde no.