Day in the Life of a Cloud Engineer

Te han ofrecido una entrevista para un puesto de Cloud Engineer y no sabes qué preguntar porque no tienes claro cómo es el día a día real. Lo que verás en las ofertas de empleo es una lista de tecnologías, no una descripción de cómo se reparte tu tiempo. Voy a contarlo sin adornos.

Este perfil es un día normal de un Cloud Engineer de nivel medio, con unos tres o cinco años de experiencia. No hay guardias heroicas ni lanzamientos épicos. Hay reuniones, trabajo de foco y cierta cantidad de interrupciones que casi nadie menciona antes de firmar.

Cómo se reparte el tiempo de verdad#

En la mayoría de equipos, el tiempo se parte en tres bloques desiguales.

Reuniones. Cerca de dos o tres horas al día en un equipo maduro. Daily de quince minutos, una o dos reuniones de diseño o planificación a la semana, alguna llamada con desarrollo o con seguridad. Si tu empresa tiene muchas reuniones, este número sube rápido.

Trabajo de foco. Dos o tres horas de concentración real, normalmente por la mañana temprano. Es donde se escribe Terraform, se depuran pipelines o se lee documentación. Todo el mundo dice que quiere más tiempo de este tipo. Pocas empresas lo protegen.

Interrupciones. El resto. Revisar alertas, responder en Slack, revisar pull requests, atender a alguien que tiene un despliegue atascado. Es trabajo necesario, pero disperso, y cansa más de lo que parece.

Si acabas de entrar, el reparto cambia. Al principio hay más tiempo de lectura y menos de ejecución. Eso no es perder el tiempo. Es aprender dónde están las minas.

La mañana: alertas, código y una daily corta#

El día suele empezar revisando qué pasó durante la noche. No es lo mismo mirar un panel de CloudWatch a las nueve de la mañana que recibir un SMS a las tres. Este perfil trabaja con alertas que se revisan por la mañana, no con guardias nocturnas. Las guardias existen en muchas empresas, pero no en todas, y es algo que debes preguntar en la entrevista.

Después llega la daily. Quince minutos, de pie o sentado, lo importante es que sea corta. Hablas de lo que hiciste ayer, lo que haces hoy y si algo te bloquea. Si tu daily dura cuarenta minutos, el problema no es la daily. Es el equipo.

Luego toca trabajo de foco. Aquí es donde se escribe código de infraestructura.

Un ejemplo concreto. Imagina que tienes que añadir una base de datos gestionada a un entorno de staging. No abres la consola y creas una base de datos a mano. Escribes Terraform, defines el módulo, revisas el plan y lo envías a revisión. Si alguien la crea a mano, mañana tendrás un recurso que nadie puede reproducir.

Herramientas que se usan cada día#

No necesitas saberlas todas antes de entrar. Necesitas entender para qué sirve cada una.

• Terraform o Bicep para describir la infraestructura como código.
• La consola de tu nube, ya sea AWS, Azure o GCP, para diagnosticar, no para crear.
• Git y tu plataforma de revisión, GitHub, GitLab o Azure Repos.
• Un pipeline de CI/CD que ejecuta tus plantillas y tus pruebas.
• Un sistema de monitorización y alertas, tipo CloudWatch, Azure Monitor o Grafana.
• Un gestor de secretos, porque las claves no se guardan en el repositorio.
• Slack o Teams, y ahí se va más tiempo del que querrías.

Lo que sorprende a los recién llegados es cuánto tiempo se pasa leyendo. Documentación, pull requests ajenos, logs. La mitad del trabajo es entender qué está roto antes de tocar nada.

El mediodía: revisión de cambios y bloqueos#

A media mañana llega la parte más social del trabajo. Revisas pull requests de tus compañeros, respondes dudas, miras un pipeline que ha fallado por un motivo absurdo.

La revisión de código de infraestructura merece atención. Un cambio pequeño en Terraform puede apagar una base de datos en producción si alguien mete la mano donde no debe. Por eso las revisiones son lentas a propósito. Si tu equipo aprueba cambios de infraestructura sin mirarlos, tienes un problema serio y probablemente no es tuyo.

Aquí aparece el primer punto de presión real. Cuando un despliegue se atasca y hay gente esperando, la tentación de saltarse la revisión es fuerte. No lo hagas. Un incidente por un cambio a medias cuesta más tiempo del que ahorras.

La tarde: diseño, documentación y alguna sorpresa#

Por la tarde suele haber menos interrupciones, aunque no siempre. Es buen momento para diseñar algo con calma, escribir documentación o investigar una tecnología nueva que el equipo va a adoptar.

Documentar es la tarea que todo el mundo retrasa. Un diagrama actualizado y tres párrafos claros ahorran horas dentro de un mes. Nadie te lo agradece en el momento. Se agradece cuando alguien nuevo entra y no tiene que preguntarte cada cosa.

La sorpresa más común para los recién llegados es que casi nada es tan técnico como esperaban. Buena parte del trabajo es negociar plazos, explicar por qué algo lleva tiempo y convencer a alguien de que no va a necesitar esa configuración especial que vio en un tutorial.

Puntos de presión que casi nadie menciona#

Hay días tranquilos. Hay días que no lo son. Estos son los momentos que más pesan.

Un incidente en producción manda el resto del trabajo a la basura. Dejas lo que estabas haciendo y te sientes con el equipo hasta que se resuelve. Puede durar media hora o media tarde.

Los cambios que salen mal en viernes. Es un cliché, pero sigue pasando. Si puedes evitar desplegar el viernes por la tarde, evítalo.

La presión de la migración. Cuando tu empresa decide moverse a la nube o cambiar de proveedor, hay meses de trabajo con fechas que se van moviendo y expectativas que no cuadran.

Y un tema que incomoda: la sensación de que nunca sabes lo suficiente. La nube cambia rápido, los servicios se renombran, aparecen cosas nuevas cada trimestre. Si te bloquea esa sensación, no durarás mucho. Si te da igual y sigues aprendiendo a tu ritmo, irá bien.

Qué cambia entre junior y senior#

La diferencia no es principalmente técnica. Un junior y un senior pueden escribir el mismo módulo de Terraform. Lo que cambia es el criterio.

Un Cloud Engineer junior ejecuta tareas definidas. Arregla un pipeline, añade un recurso, corrige una alerta. Necesita que alguien revise su trabajo y le diga si va bien. Es normal y está bien.

Un Cloud Engineer senior decide qué no hacer. Anticipa problemas, propone simplificar, dice que algo no merece la pena. También dedica tiempo a que otros aprendan, porque si todo pasa por ti, el equipo no escala.

En la práctica, un senior pasa más tiempo en reuniones y menos escribiendo código. A algunos les gusta. A otros les frustra y prefieren quedarse en un perfil técnico sin gestionar personas. Las dos opciones existen.

Lo que preguntar antes de aceptar un puesto#

Antes de decir que sí, aclara estas cosas. Te ahorrarás disgustos.

• ¿Hay guardias? ¿Con qué frecuencia y con compensación?
• ¿Cuánto tiempo se dedica a trabajo nuevo frente a mantener lo que ya existe?
• ¿Cómo se gestionan los incidentes y quién decide cuándo se despliega?
• ¿Cuánta gente hay en el equipo y cuánto tiempo llevan?
• ¿Se usa infraestructura como código o hay recursos creados a mano?
• ¿Qué nube y qué servicios concretos se usan, no solo el nombre del proveedor?

Si quieres comparar requisitos reales entre ofertas, puedes leer ofertas abiertas en el buscador de empleo y usar el decodificador de ofertas para entender qué pide cada empresa de verdad. Después, pasa tu currículum por el verificador de compatibilidad con ATS y revisa más guías sobre entrevistas y tecnología en nuestro blog.

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ánto gana un Cloud Engineer?

Depende del país, la experiencia y si trabajas en remoto para una empresa extranjera. En España y Latinoamérica los sueldos varían mucho entre una empresa local y una multinacional, y en Estados Unidos son bastante más altos. Consulta fuentes oficiales o portales de empleo actualizados antes de tomar una decisión.

¿Se necesita saber programar?

Sí, aunque no hace falta ser desarrollador. Necesitas leer código, escribir scripts y entender cómo funcionan los pipelines. Python y Bash son los más útiles, y Terraform se aprende sobre la marcha.

¿Es un trabajo con mucha presión?

Tiene picos. La mayor parte del tiempo es trabajo normal, pero cuando algo se rompe en producción el día cambia. Si te estresa la idea de que alguien dependa de ti, piénsalo antes de entrar.

¿Se puede trabajar en remoto?

En muchos casos sí, sobre todo en empresas de tecnología. Hay organizaciones que piden presencia por temas de seguridad o por la zona horaria del equipo. Pregunta por la política concreta antes de la entrevista final.

¿Qué camino hay para pasar de junior a senior?

Dos o tres años de experiencia bien aprovechados, más criterio para decidir y comunicar. Ayuda mucho haber participado en un incidente grande, haber migrado algo de verdad y haber enseñado a otros. Los certificados ayudan a pasar filtros, pero no sustituyen a la experiencia.