Ingeniero DevOps Preguntas de entrevista & Respuestas

Respuesta modelo

El clúster principal de base de datos sufrió una conmutación por error durante las horas pico por un problema de espacio en disco que nuestro sistema de monitoreo no detectó. La conmutación funcionó, pero la réplica llevaba 30 segundos de retraso, lo que provocó inconsistencias en los datos visibles para los usuarios. Lideré la respuesta al incidente: aislé el problema en 10 minutos, coordiné con el equipo de ingeniería para identificar a los usuarios afectados en 20 minutos y emití una comunicación a los clientes en 45 minutos. El tiempo de inactividad total fue de 8 minutos. En el postmortem, implementé tres cambios: añadí alertas de espacio en disco con umbral al 80%, creé un runbook para escenarios de conmutación de base de datos y configuré pruebas semanales de ingeniería del caos para los mecanismos de failover. También migramos a replicación síncrona para las tablas críticas. Durante los 12 meses siguientes, no tuvimos ninguna conmutación de base de datos no planificada.

Respuesta modelo

El equipo de desarrollo desplegaba manualmente vía SSH y se resistía a los despliegues automatizados porque 'necesitamos control'. En lugar de imponer el cambio, empecé por sus propios problemas. Medí que los despliegues manuales tardaban 45 minutos de media, tenían una tasa de fallos del 15% y siempre ocurrían los viernes a las 5 PM. Construí un pipeline CI/CD que replicaba sus pasos manuales exactos, lo ejecuté en paralelo durante 2 semanas y demostré que los despliegues automatizados tardaban 3 minutos con una tasa de fallos del 1%. Dejé que el desarrollador más escéptico ejecutara el primer despliegue automatizado a producción. Cuando funcionó a la perfección, se convirtió en el mayor defensor del pipeline. En un mes, el equipo desplegaba 3 veces al día en lugar de una vez por semana. La clave fue hacer que el cambio se sintiera seguro, no forzar el cumplimiento.

Respuesta modelo

Analicé nuestro gasto en AWS y descubrí que pagábamos 28.000 $ al mes por recursos que funcionaban 24/7 pero solo eran necesarios en horario laboral (entornos de desarrollo, clústeres de staging, procesamiento por lotes). Implementé un sistema de programación automatizado con AWS Lambda y CloudWatch Events que escalaba los entornos de no producción a cero por las noches y los fines de semana. También redimensioné las instancias de producción usando 3 meses de métricas de CloudWatch: estábamos ejecutando instancias m5.2xlarge que nunca superaban el 30% de CPU. Cambiar a m5.large con autoescalado ahorró otros 8.000 $ al mes. Moví los datos de S3 con poco acceso a Glacier, ahorrando 3.000 $ al mes. Ahorro total: 18.000 $ al mes (216.000 $ anuales) sin ningún impacto en el rendimiento. Configuré un panel de revisión mensual de costes que se convirtió en una práctica estándar.

Respuesta modelo

Los desarrolladores tardaban una media de 90 minutos en configurar su entorno de desarrollo local, y la desviación de configuraciones causaba bugs del tipo 'funciona en mi máquina' cada semana. Contenericé toda la pila de desarrollo con Docker Compose: base de datos, cola de mensajes, caché y todos los microservicios. Escribí un único comando 'make dev' que descargaba las últimas imágenes, inicializaba la base de datos y arrancaba todos los servicios. El tiempo de configuración bajó de 90 minutos a 5 minutos. También construí un sistema de hooks pre-commit que ejecutaba linting, comprobación de tipos y pruebas unitarias de forma local, detectando el 80% de los fallos de CI antes del push. Las puntuaciones de satisfacción de los desarrolladores en 'herramientas e infraestructura' subieron de 2,8 a 4,3 sobre 5. La conclusión clave: la productividad del desarrollador es un problema de infraestructura.

Respuesta modelo

Las máquinas virtuales virtualizan el hardware: cada VM ejecuta su propio kernel de sistema operativo, gestionado por un hipervisor. Los contenedores virtualizan el sistema operativo: comparten el kernel del host y se aíslan a nivel de proceso usando namespaces y cgroups. Los contenedores son más ligeros (MB frente a GB), arrancan más rápido (segundos frente a minutos) y se empaquetan con mayor densidad en un host. Elijo contenedores para microservicios, aplicaciones sin estado y todo lo que necesite escalar rápidamente. Elijo VMs cuando necesito un aislamiento completo del sistema operativo (entornos multitenant con requisitos de seguridad estrictos), necesito ejecutar sistemas operativos distintos en el mismo host, o ejecuto software que requiere modificaciones del kernel. En la práctica, la mayoría de las cargas de trabajo modernas están contenidas. Las aplicaciones heredadas, ciertos requisitos de cumplimiento normativo (entornos PCI-DSS que exigen aislamiento a nivel de VM) y las cargas de trabajo Windows pueden seguir siendo más adecuadas para VMs.

Respuesta modelo

Lo construiría en capas. El bucle interno (por servicio): cada microservicio tiene su propio pipeline activado por commits en su directorio. Ejecuta linting, pruebas unitarias, construye una imagen de contenedor con una etiqueta basada en el contenido (SHA de git), la sube al registro y despliega en un entorno de desarrollo. La capa de integración: tras pasar sus propias pruebas, se ejecutan pruebas de integración contra un entorno de staging compartido con todos los servicios. Usaría pruebas de contrato con Pact para detectar problemas de compatibilidad entre servicios sin necesidad de tenerlos todos en marcha. La capa de despliegue: usaría GitOps con ArgoCD. Fusionar en la rama de despliegue actualiza un repositorio de manifiestos, y ArgoCD sincroniza el estado del clúster. Los rollbacks son un simple git revert. Para mayor seguridad: despliegues canary con rollback automático basado en umbrales de tasa de errores, ventanas de despliegue con bloqueos automáticos en periodos de alto tráfico y una puerta de aprobación manual para producción los primeros meses hasta ganar confianza.

Respuesta modelo

La infraestructura como código consiste en definir tu infraestructura (servidores, redes, bases de datos, balanceadores de carga) en archivos de configuración declarativos, en lugar de hacer clic en consolas o ejecutar scripts puntuales. Herramientas como Terraform, CloudFormation y Pulumi lo hacen posible. Su importancia radica en tres razones. Primera, reproducibilidad: puedo levantar un entorno idéntico en cualquier región ejecutando el mismo código. Se acabó el 'creemos que staging coincide con producción'. Segunda, control de versiones: los cambios de infraestructura pasan por la misma revisión de código, aprobación y registro de auditoría que el código de aplicación. Puedo ver quién cambió qué, cuándo y por qué, y revertir si es necesario. Tercera, automatización: los cambios de infraestructura pueden ser probados, validados y aplicados por pipelines CI/CD, eliminando errores manuales. En la práctica, uso Terraform con estado remoto en S3, bloqueo de estado con DynamoDB y módulos para componentes reutilizables. Cada cambio de infraestructura pasa por un pull request con la salida de terraform plan para su revisión.

Respuesta modelo

Sigo los tres pilares: métricas, logs y trazas. Las métricas (Prometheus + Grafana) me dan la salud agregada del sistema: CPU, memoria, tasa de solicitudes, tasa de errores, percentiles de latencia. Configuro alertas sobre síntomas (alta tasa de errores, latencia elevada), no sobre causas (CPU alta), porque los síntomas indican que los usuarios están afectados. Los logs (ELK o Loki) proporcionan contexto detallado de eventos para la depuración. Exijo logging estructurado (JSON) con IDs de correlación para poder rastrear una solicitud a través de los servicios. Las trazas (Jaeger o Tempo) me muestran el camino completo de una solicitud por el sistema, revelando qué servicio es lento y por qué. Más allá de los tres pilares, construyo paneles de nivel de negocio: pedidos por minuto, registros por hora, tasa de éxito de pagos. Son lo primero que reviso durante un incidente porque responden a '¿están afectados los usuarios?' antes de profundizar en las métricas de infraestructura. También implemento SLOs con presupuestos de error: esto transforma el monitoreo de '¿está algo roto?' a '¿estamos cumpliendo nuestros compromisos de fiabilidad?'

Respuesta modelo

A corto plazo: habilitaría el Cluster Autoscaler de Kubernetes para añadir nodos automáticamente cuando los pods no puedan programarse. Verificaría que el pool de nodos tiene margen para escalar y que las políticas del autoscaler son razonables (escalar rápido hacia arriba, lento hacia abajo). También comprobaría si los recursos existentes están sobreasignados: es habitual que los pods soliciten el doble de los recursos que realmente usan. Redimensionar las solicitudes de recursos en función del uso real podría liberar entre un 30% y un 40% de capacidad sin añadir nodos. A medio plazo: implementaría el Horizontal Pod Autoscaler (HPA) en todas las cargas de trabajo con objetivos adecuados de CPU y memoria, y consideraría el Vertical Pod Autoscaler (VPA) para cargas con patrones de recursos impredecibles. También movería las cargas de trabajo por lotes a instancias spot o preemptibles. A largo plazo: analizaría los patrones de tráfico e implementaría escalado predictivo. Si sabemos que las horas pico son de 9 a 11 AM, escalar 15 minutos antes en lugar de reaccionar a la demanda. También evaluaría si algunas cargas deberían migrar a serverless (Lambda/Cloud Run) para eliminar por completo la carga de planificación de capacidad.

Respuesta modelo

Primero, resolvería el problema inmediato: revertir el cambio de configuración y restaurar el servicio. Después realizaría un postmortem sin culpables: el foco está en el sistema que permitió que esto ocurriera, no en la persona que hizo el cambio. Mis medidas preventivas: primera, todos los cambios de configuración pasan por el mismo pipeline CI/CD que el código (pull request, revisión, validación automatizada y despliegue escalonado), sin pushes directos a la configuración de producción. Segunda, implementar validación de configuración en el pipeline: comprobación de esquema, aplicación en seco y pruebas de integración contra un entorno de staging. Tercera, rollout progresivo para los cambios de configuración: aplicar al 5% de las instancias, monitorear la tasa de errores durante 10 minutos y luego avanzar al 25%, 50%, 100%. Cuarta, disparadores de rollback automático: si la tasa de errores supera el nivel base en 2 veces dentro de los 5 minutos posteriores a un cambio de configuración, revertir automáticamente. El objetivo es hacer que el camino seguro sea el camino fácil: debería ser más difícil hacer push de configuración directamente que pasar por el pipeline.

Respuesta modelo

Nunca haría una reescritura big-bang: fracasa sistemáticamente. En su lugar, usaría el patrón strangler fig: extraer servicios de forma incremental mientras el monolito sigue sirviendo tráfico. Paso 1: identificar los límites de servicio usando diseño guiado por el dominio. Mapear los dominios del monolito, la propiedad de los datos y las dependencias. Empezar con el servicio menos acoplado y de mayor valor. Paso 2: construir el nuevo servicio junto al monolito, enrutando el tráfico hacia él a través de un API gateway. El monolito y el nuevo servicio comparten inicialmente la base de datos. Paso 3: una vez estable el servicio, migrar sus datos a su propia base de datos y eliminar la dependencia compartida. Paso 4: repetir para el siguiente servicio. Esperaría que la migración completa tome entre 12 y 18 meses para un monolito de tamaño mediano. Principios clave: cada servicio extraído debe ser desplegable y testeable de forma independiente, el sistema debe funcionar en el estado híbrido (algunos servicios extraídos, otros aún en el monolito) y añadiría monitoreo exhaustivo en el límite entre lo antiguo y lo nuevo para detectar problemas de integración con rapidez.

Respuesta modelo

Evaluaría en función de cuatro factores, no de preferencias personales. Primero, la experiencia existente: ¿qué conoce ya el equipo? Las curvas de aprendizaje en la nube son pronunciadas y el coste de productividad de cambiar es real. Si el equipo tiene 3 años de experiencia en AWS, la nueva plataforma necesita ofrecer una ventaja convincente para justificar el tiempo de adaptación. Segundo, requisitos de servicios específicos: ¿el proyecto necesita algo que una nube ofrezca significativamente mejor? GCP para ML (Vertex AI), Azure para integración empresarial (Active Directory), AWS por el catálogo de servicios más amplio. Tercero, el modelo de precios: estimaría los costes usando la calculadora de cada nube para nuestro patrón de carga de trabajo específico. Las instancias reservadas, los precios spot y los costes de salida varían de forma significativa. Cuarto, el contexto organizativo: acuerdos con proveedores, requisitos de cumplimiento e infraestructura existente. Si la empresa ya tiene un Enterprise Agreement con AWS, usar GCP añade complejidad de adquisición. Presentaría una recomendación con una matriz de decisión clara, no solo mi intuición.