Preguntas de entrevista para Ingeniero DevOps

Respuesta modelo

Para mí DevOps no es un puesto de herramientas, sino la responsabilidad sobre el flujo que va del commit a la producción. Un administrador de sistemas garantiza que la máquina funcione; un ingeniero de nube diseña cómo se estructuran los servicios de la plataforma. Mi trabajo consiste en que ese camino sea automático, repetible y medible: pipeline, infraestructura descrita como código, despliegue sin intervención manual y observabilidad que avise antes de que llame el cliente. En mi último puesto lo concretaba así: si un desarrollador necesitaba pedirme algo para desplegar, era una tarea pendiente de automatización en mi backlog.

Respuesta modelo

La última fue para un monorepo Java con 14 equipos. Definí cuatro etapas: validación rápida (lint, compilación incremental y tests unitarios en menos de cinco minutos), calidad y seguridad (SonarQube, escaneo de dependencias y de imagen con Trivy como puertas bloqueantes), publicación del artefacto firmado en Nexus y, por último, despliegue GitOps mediante un cambio en el repositorio de manifiestos que Argo CD reconcilia. Lo que más impacto tuvo fue el paralelismo por módulo y una caché de dependencias bien invalidada: el build pasó de 47 a 9 minutos con 1.200 ejecuciones semanales. También añadí una regla que descarta ejecuciones antiguas de la misma rama, porque el 20 % del cómputo se iba en construir commits ya superados.

Respuesta modelo

Estado remoto con bloqueo, nunca en local, y separación por entorno y por dominio funcional para que el radio de impacto de un apply sea pequeño. Los cambios entran por merge request con plan automático publicado en el propio hilo de revisión, y el apply solo lo ejecuta la pipeline, nunca una persona desde su portátil. Para lo compartido publico módulos versionados en un registro interno: los equipos fijan una versión y actualizan cuando les conviene, así una mejora mía no rompe su entorno el mismo día. Reviso la deriva con una ejecución programada de plan que abre una incidencia si detecta cambios fuera del código. En mi anterior empresa esa práctica sacó a la luz once recursos creados a mano durante una noche de incidencia.

Respuesta modelo

Las cuatro métricas DORA como base. Frecuencia de despliegue y lead time for changes me dicen si el flujo va rápido; tasa de fallo en cambios y tiempo medio de restauración, si va seguro. Las miro juntas, porque subir la frecuencia mientras crece la tasa de fallo no es una mejora. En mi último proyecto pasamos de dos despliegues mensuales a cuarenta semanales y, en paralelo, la tasa de fallo bajó del 18 % al 4,5 % gracias a la reversión automática. Añado dos indicadores propios: el tiempo desde que un equipo nuevo abre un repositorio hasta su primer despliegue en producción, y el número de páginas nocturnas al mes, que para mí es el mejor termómetro de la salud real del sistema.

Respuesta modelo

He estado en rotaciones de cinco y seis personas, una semana de cada cinco, con retén telefónico. Cuando entré en el último equipo llegaban catorce avisos nocturnos al mes y buena parte no requería ninguna acción. Hice tres cosas: clasificar un mes de alertas para separar las accionables de las informativas, definir SLO con los responsables de producto y sustituir los umbrales fijos por alertas de consumo de presupuesto de error, y llevar todo lo no accionable a un panel de revisión semanal en lugar de al teléfono. Pasamos de 180 reglas a 31 y de catorce páginas nocturnas a dos. Cada alerta que queda tiene runbook con el primer paso concreto; si no lo tiene, no despierta a nadie.

Respuesta modelo

Tratando la plataforma como un producto interno con usuarios que pueden decir que no. Antes de imponer nada me siento con dos o tres equipos y observo cómo despliegan hoy; casi siempre el atajo que usan revela una fricción real. Después ofrezco un camino guiado que sea más cómodo que el atajo: plantilla que genera repositorio, pipeline, panel y alertas por defecto, con documentación breve y un taller de una hora. Con ese enfoque, nueve de cada diez equipos adoptaron el portal interno en seis meses sin ninguna directiva de dirección. Cuando algo no se adopta, asumo que el problema es mi diseño, no la resistencia del equipo.

Primero confirmo que el artefacto es idéntico comparando el digest de la imagen, no la etiqueta, porque una etiqueta móvil es la causa más frecuente de este síntoma. Después comparo la configuración efectiva: variables de entorno, secretos, ConfigMaps y límites de recursos, con un diff entre ambos entornos. A continuación miro las diferencias de plataforma: versión del clúster, políticas de red, cuotas y clases de almacenamiento. Si nada aparece, reviso las dependencias externas, que casi nunca son iguales en los dos entornos, y los eventos del pod junto con el motivo real del reinicio. Como medida de fondo, propongo que preproducción se genere con el mismo código de Terraform y los mismos manifiestos parametrizados, porque este problema es siempre un síntoma de deriva entre entornos.

En rolling update se sustituyen las réplicas progresivamente: es el modo por defecto de Kubernetes, barato y adecuado cuando la aplicación tolera convivencia de versiones. En blue/green se mantienen dos entornos completos y se cambia el tráfico de golpe: cuesta el doble en recursos, pero la reversión es inmediata, por lo que lo uso en sistemas con ventanas críticas, como facturación a fin de mes. En canary se envía un porcentaje pequeño de tráfico a la versión nueva y se promociona según métricas: es el que prefiero para servicios con mucho tráfico, porque permite decidir con datos reales. La condición imprescindible en los tres casos es la compatibilidad del esquema de base de datos hacia atrás; sin migraciones expansivas y en dos fases, ninguna estrategia de despliegue le salvará de una reversión imposible.

Ningún secreto en el repositorio ni en variables de CI escritas a mano. Uso un gestor central, en mi caso HashiCorp Vault, con autenticación de la propia pipeline mediante identidad efímera (OIDC), de modo que no exista una credencial de larga duración que robar. En el clúster los secretos se inyectan en tiempo de ejecución con un operador, no se versionan en Git; si se usa GitOps, los cifro con SOPS o con secretos sellados. Aplico rotación automática en las credenciales de base de datos, con vida corta, y registro de acceso auditable. En una migración de 60 servicios el mayor trabajo no fue técnico, sino inventariar dónde estaban realmente las credenciales: aparecieron en ficheros de configuración, en un panel de un CI antiguo y en un canal de chat.

No aplico. Leo el motivo del reemplazo en el plan, que indica qué atributo lo fuerza; suele ser un cambio en un campo inmutable o un nombre que ha variado. Si el cambio es necesario, planteo una migración por fases: creo el recurso nuevo, migro los datos y retiro el antiguo en un cambio posterior. Si el recurso ya existe pero está fuera del estado, uso importación o un bloque moved en lugar de dejar que se recree. Y protejo lo crítico con prevent_destroy y copias de seguridad verificadas. La regla que sigo y que enseño al equipo es simple: cualquier plan que contenga una destrucción se revisa entre dos personas antes de aprobarse.

Un SLO expresa el nivel de servicio que los usuarios pueden esperar en un periodo, por ejemplo que el 99,9 % de las peticiones se sirvan por debajo de 300 ms en 30 días. De ahí sale el presupuesto de error, que es el margen de fallo admisible: en ese caso, unos 43 minutos al mes. Las alertas las construyo sobre la velocidad de consumo de ese presupuesto, con dos ventanas, una corta y otra larga, para distinguir un incidente grave de un deterioro lento. Así se avisa por teléfono solo cuando el ritmo de consumo pone en riesgo el objetivo, y lo demás se revisa en horario laboral. La conversación importante no es técnica: hay que acordar el SLO con el responsable de producto, porque es él quien decide si un mes con el presupuesto agotado justifica parar nuevas funcionalidades.

Empiezo midiendo, no optimizando: saco el desglose por etapa de las últimas doscientas ejecuciones y busco dónde está realmente el tiempo. En mi experiencia hay cuatro causas que cubren casi todo: descarga repetida de dependencias por caché mal invalidada, ejecución secuencial de pruebas que podrían ir en paralelo, imágenes base enormes que se reconstruyen entero en cada commit y pruebas de integración lentas colocadas antes de la retroalimentación rápida. Reorganizo el flujo para que en cinco minutos el desarrollador sepa si su cambio es viable, y dejo lo pesado en una etapa posterior o nocturna. Después vigilo también la fiabilidad: una pipeline rápida pero con pruebas intermitentes destruye la confianza igual que una lenta, así que aíslo y arreglo los tests inestables antes de seguir optimizando.

Lo primero es mitigar, no diagnosticar. Confirmo el alcance en el panel de SLO y en los registros, y compruebo si ha habido un despliegue o un cambio de configuración en las últimas horas; si lo hay, revierto de inmediato, porque revertir es más rápido que entender. En paralelo abro el canal de incidencia, comunico el impacto en lenguaje de negocio y aviso al responsable de guardia del área de pagos, que es quien puede decidir sobre el modo degradado. Si la reversión no resuelve, aplico las medidas del runbook: aislar la instancia afectada, activar el circuito de contención y limitar el tráfico si procede. Solo cuando el servicio está estable pasamos al análisis de causa raíz, y al día siguiente escribo el post-mortem con la línea temporal y las acciones correctoras, sin señalar a nadie.

No convierto la conversación en un pulso. Pregunto qué está bloqueando exactamente y miro el hallazgo concreto: no es lo mismo una vulnerabilidad crítica explotable en una dependencia expuesta que un aviso en una biblioteca de pruebas. Si el riesgo es asumible, aplico una excepción documentada con caducidad y con la persona responsable identificada, nunca una desactivación permanente. Si el riesgo es real, ofrezco alternativas: actualizar la dependencia, desplegar con la funcionalidad afectada tras un feature flag o salir con alcance reducido. Y después llevo el caso a la retrospectiva, porque una puerta que todo el mundo quiere saltarse suele estar mal calibrada; en un caso así reduje los falsos positivos de un escáner en dos tercios y las peticiones de excepción desaparecieron.

Durante las tres primeras semanas no cambio nada: acompaño dos despliegues completos, documento el procedimiento real tal y como se hace y mido cuánto dura cada paso y dónde falla. Con esos datos priorizo por dolor, no por elegancia. Primero automatizo la construcción y la publicación del artefacto, que es la parte de menor riesgo y da confianza; después llevo el despliegue de preproducción a la pipeline para que todos vean que funciona. En paralelo empiezo a codificar la infraestructura por importación, entorno a entorno, sin recrear nada. Hacia el día sesenta propongo el primer despliegue a producción automatizado en horario laboral, con reversión probada previamente. Mi objetivo a noventa días no es tener todo automatizado, sino que nadie tenga que trabajar un viernes por la noche y que exista una línea base medida para demostrar el progreso.

Antes de tocar nada necesito visibilidad de coste por equipo y por servicio, con etiquetado consistente; sin eso, cualquier recorte es a ciegas. Suelo encontrar tres bolsas rápidas: entornos de preproducción encendidos las 168 horas de la semana cuando se usan 45, recursos sobredimensionados frente a su consumo real y almacenamiento y registros con retención infinita. Apagar entornos fuera de horario y ajustar peticiones de CPU y memoria con datos de consumo suele dar entre un 20 % y un 25 % sin impacto en producción. También reviso el coste de la propia CI, que se dispara con runners ociosos y con ejecuciones redundantes. Presento cada medida con su ahorro estimado y su riesgo, y dejo claro qué no recomiendo tocar: la redundancia de producción y las copias de seguridad no son una partida de ahorro.