Portfolio Projects for DevOps Engineer

Tienes tres certificados de cloud, un homelab que lleva meses funcionando, y aún así no pasas del primer filtro. No es el certificado lo que falla. Falta evidencia de que sabes operar, no solo aprobar.

Un certificado dice que estudiaste. Un proyecto bien presentado dice que tomaste decisiones, rompiste cosas, las arreglaste y puedes explicar por qué. Eso es lo que busca quien revisa tu candidatura para un puesto de DevOps.

Qué mira realmente quien revisa tu perfil#

Nadie revisa tu portfolio línea por línea. Reciben cuarenta candidaturas para un puesto, miran tu GitHub diez segundos y deciden si siguen. En esos diez segundos buscan tres cosas.

Primero, si los proyectos corren sin que nadie tenga que preguntarte cómo. Segundo, si hay contexto: qué problema resolvías, con qué limitaciones, qué alternativas descartaste. Tercero, si las decisiones tienen criterio, no solo el tutorial de turno copiado.

Lo que casi nadie mira: cuántas tecnologías pusiste en el README. Una lista de veinte herramientas sin contexto activa la señal de alarma de "junior que acumula keywords". Menos herramientas, más razonamiento.

Proyecto 1: pipeline de despliegue con rollback automático#

Monta una aplicación pequeña, una API de tareas o un clon simple, y llévala a producción con un pipeline completo. Pero el valor no está en el despliegue. Está en el fallo controlado.

Implementa health checks que detengan el rollout si la nueva versión responde mal, y un mecanismo de rollback que vuelva a la versión anterior sin intervención manual. Documenta una vez que el rollback falló o tardó demasiado, y qué cambiaste después.

Ejemplo de cómo se ve en un CV, antes y después:

• Antes: "Pipeline CI/CD con GitHub Actions y Kubernetes".
• Después: "Pipeline de despliegue para API en Kubernetes con health checks y rollback automático; reduje el tiempo de recuperación tras un despliegue defectuoso de 25 minutos a menos de 3, tras dos iteraciones sobre el proceso de detección".

La segunda versión tiene una decisión, un problema y un resultado. La primera solo tiene herramientas.

Proyecto 2: observabilidad con alertas que no molestan#

Todo el mundo monta un dashboard con CPU y memoria. Poco gente se pregunta si las alertas sirven para algo. El proyecto interesante es el sistema de alertas que responde a fallos reales y no despierta a nadie por tonterías.

Configura métricas, logs y trazas, y define alertas sobre síntomas que un usuario notaría, como tasa de errores o latencia, en vez de solo uso de recursos. Después simula un fallo: un servicio que responde lento, una base de datos que se cae, y comprueba si la alerta llega y si el diagnóstico es posible con los datos que recoges.

Lo que demuestra esto: que entiendes que la observabilidad existe para reducir el tiempo hasta entender qué pasa, no para llenar paneles bonitos.

Proyecto 3: infraestructura como código con drift real#

Todo portafolio tiene un repo de Terraform. El tuyo debe demostrar qué pasa cuando la realidad cambia sin que nadie lo pida. Escribe la infraestructura con Terraform o Pulumi, versiona el estado, y añade detección de drift con un job programado.

Luego provoca el drift a propósito: cambia algo desde la consola, deja que el job lo detecte y documenta cómo lo resolviste. Menciona también el manejo de secretos y el estado remoto, porque es donde suelen aparecer los errores caros.

Este proyecto comunica algo directo: sabes que la infraestructura viva se desvía del código y tienes un plan para eso.

Cómo presentarlo en GitHub#

El README es la parte que la mayoría deja para el final y casi nadie escribe bien. Empieza con dos frases: qué problema resuelve el proyecto y cómo se ejecuta. Nada de "este proyecto es un ejemplo de...".

Incluye un diagrama simple, uno basta, con los componentes y las flechas de flujo. Añade una sección de decisiones donde expliques qué descartaste y por qué, porque eso separa a quien implementó de quien siguió pasos. Cierra con qué falló durante el desarrollo y qué harías distinto.

Si quieres ver cómo se estructuran proyectos con ese nivel de detalle, en el blog hay ejemplos comentados que puedes usar como referencia.

Errores que convierten un proyecto en un tutorial#

El error más común es el repo que sigue paso a paso un curso conocido, con los mismos nombres, la misma app y la misma arquitectura. Quien lleva años en el sector reconoce esos repos a la primera.

Otros fallos frecuentes:

• README que solo lista tecnologías sin explicar el problema que resolvías.
• Todo funcionando a la primera, sin registro de errores ni iteraciones, porque nadie cree que un proyecto salga limpio.
• Cinco proyectos pequeños casi idénticos en vez de dos con profundidad real.
• Capturas de dashboards sin contexto sobre qué decisión permitían tomar.
• Dependencias sin versionar o secretos subidos al repo, que descartan tu candidatura al instante.
• Proyectos sin forma de ejecutarse en local o sin instrucciones claras de despliegue.

Cómo ponerlo en el CV#

El CV no debe listar los proyectos como títulos sueltos. Cada uno necesita una línea con contexto, acción y resultado, usando verbos concretos y cifras cuando las tengas. Si no tienes cifras reales, describe el alcance: número de servicios, entornos o despliegues semanales.

Ejemplo completo de entrada de CV:

"Infraestructura como código para entorno de staging y producción (Terraform, estado remoto en S3, detección de drift diaria). Identifiqué y corregí 4 desviaciones no autorizadas en dos meses, reduciendo configuraciones manuales fuera de control."

Cuida el formato si vas a pasar el CV por filtros automáticos. Puedes comprobar cómo lo lee un sistema con nuestra herramienta gratuita de revisión ATS y ajustar el texto antes de enviarlo. También conviene leer la oferta con atención y traducir sus requisitos a lenguaje concreto con el decodificador de ofertas de empleo, para usar las palabras que el equipo espera ver.

Cómo hablar de los proyectos en entrevista#

Cuando te pregunten por un proyecto, no empieces por la tecnología. Empieza por el problema, el contexto y la restricción que te obligó a decidir. La herramienta es lo último que deben escuchar.

Un guion que funciona: "Teníamos despliegues manuales que fallaban una de cada cinco veces y nadie sabía por qué hasta horas después. Monté health checks y rollback automático, y tras dos iteraciones sobre la detección de fallos, pasamos de 25 minutos de recuperación a menos de 3."

Espera preguntas sobre lo que salió mal. Si dices que todo funcionó a la primera, pierdes credibilidad. Prepara un ejemplo concreto de un error tuyo, qué impacto tuvo y cómo lo resolviste, sin culpar a nadie.

También prepara la pregunta de por qué elegiste esa herramienta y no otra. Una respuesta honesta sobre trade-offs convence más que una lista de ventajas.

Dónde buscar referencias y oportunidades#

Mira puestos reales de DevOps para entender qué tecnologías se piden hoy y adaptar tus proyectos a esa demanda, sin perseguir cada moda. Puedes explorar ofertas actualizadas en el buscador de empleo y comparar requisitos entre empresas.

Y si quieres seguir ampliando el portafolio con ideas que no sean el proyecto número veinte de Kubernetes básico, en el blog encontrarás artículos sobre problemas reales de infraestructura que puedes convertir en tu siguiente proyecto.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuántos proyectos necesito en el portafolio?

Dos o tres con profundidad valen más que ocho superficiales. Dedica tiempo a que cada uno tenga contexto, decisiones y un registro claro de lo que falló.

¿Sirven los proyectos de homelab como portafolio?

Sí, si los tratas como producción real: documentación, monitorización, backups y un registro de incidentes. Un homelab sin estructura se lee como afición, no como experiencia operativa.

¿Debo poner los certificados en el CV si tengo proyectos?

Sí, pero en una sección aparte y sin destacarlos por encima de la experiencia. Los certificados abren puertas al filtro inicial; los proyectos sostienen la conversación técnica.

¿Qué hago si no tengo experiencia laboral en DevOps?

Construye proyectos que imiten problemas reales de empresa, como despliegues con rollback, alertas útiles o detección de drift. Explica en el README el contexto que simulaste y por qué elegiste ese enfoque.

¿Cuánto código debe tener cada proyecto para que cuente?

No hay un número mágico, pero un proyecto que se explica en tres archivos rara vez demuestra criterio. Lo que importa es que haya decisiones documentadas, no líneas de código.