¿Qué diferencia hay entre integración continua, entrega continua y despliegue continuo, y qué implica cada uno para un equipo?

CI: cada commit se integra al trunk y se valida automáticamente con tests. Entrega continua: el artefacto siempre está listo para desplegarse a producción, pero el deploy es una decisión manual. Despliegue continuo: cada commit que pasa los tests llega a producción automáticamente sin intervención humana. La madurez requerida aumenta progresivamente; muchos equipos llegan a entrega continua pero no adoptan despliegue continuo por razones de negocio.

¿Cuándo usarías un despliegue blue-green frente a uno canary y qué riesgos mitiga cada uno?

Blue-green: dos entornos idénticos, el tráfico se mueve completo de uno al otro. Rollback inmediato simplemente redirigiendo el tráfico. Costo: doble infraestructura activa durante el deploy. Canary: el tráfico se mueve gradualmente al nuevo deployment, con monitoreo entre cada etapa. Detecta problemas con un porcentaje pequeño de usuarios antes de afectar a todos. Más complejo de implementar pero más seguro para sistemas con alta carga.

¿Qué consideraciones de seguridad tendrías al diseñar un pipeline de CI/CD?

Nunca hardcodear secretos en el código o en la configuración del pipeline. Usar un gestor de secretos externo. Separar los permisos de cada etapa del pipeline al mínimo necesario. Escanear dependencias y el código en busca de vulnerabilidades en cada build. Firmar los artefactos para garantizar su integridad. Auditar quién puede modificar la configuración del pipeline, ya que es una superficie de ataque crítica.

¿Qué es infraestructura como código y qué problemas resuelve frente a la gestión manual de infraestructura?

IaC describe la infraestructura en archivos de configuración versionables y reproducibles. Resuelve: entornos que divergen entre sí por cambios manuales no documentados, imposibilidad de auditar qué cambió y quién lo cambió, dificultad de recrear un entorno desde cero, y procesos de provisioning lentos y propensos a error humano. El estado de la infraestructura se convierte en código revisable con el mismo proceso que el código de la aplicación.

¿Cómo definirías los recursos de CPU y memoria para un contenedor en Kubernetes y por qué es importante hacerlo?

Kubernetes distingue entre requests (garantía mínima reservada para el scheduler) y limits (máximo que puede consumir antes de ser throttleado o killed). Sin requests, el scheduler no puede tomar decisiones informadas de placement. Sin limits, un contenedor puede agotar los recursos del nodo y afectar a otros pods. Los valores deben basarse en mediciones reales de la aplicación, no en estimaciones.

¿Qué estrategia seguirías para gestionar configuraciones distintas entre entornos (dev, staging, prod) sin duplicar infraestructura?

Parametrizar los módulos de IaC con variables por entorno. En Terraform, usar workspaces o directorios de entorno con tfvars. En Kubernetes, usar Helm charts con values files por entorno o Kustomize con overlays. El código de infraestructura es el mismo; solo los valores cambian. Nunca hardcodear valores específicos de un entorno en los módulos reutilizables.

¿Qué es un SLO y cómo lo usarías para tomar decisiones operacionales?

Un SLO (Service Level Objective) es un objetivo medible de confiabilidad: por ejemplo, el 99.9% de requests deben responder en menos de 200ms. El error budget es el margen de incumplimiento permitido. Si el error budget está agotado, el equipo prioriza confiabilidad sobre nuevas features. Si hay margen, puede asumir más riesgo en deploys. Es una herramienta para hacer explícito el trade-off entre velocidad de desarrollo y estabilidad del sistema.

¿Cómo abordarías la reducción del ruido de alertas en un sistema con demasiadas notificaciones que el equipo ya no atiende?

Auditar las alertas existentes clasificándolas en: actionable (requiere intervención inmediata), informacional (no requiere acción), y ruidosas (se disparan frecuentemente sin consecuencias reales). Eliminar o degradar las dos últimas categorías. Cada alerta debe tener un runbook asociado que explique qué hacer. El objetivo es que cada alerta que llega al on-call sea significativa y tenga una respuesta clara documentada.

¿Cómo diagnosticarías un pod en estado CrashLoopBackOff en Kubernetes y cuáles son las causas más frecuentes?

Primero kubectl describe pod para ver los eventos y el exit code. Luego kubectl logs con --previous para ver los logs del último intento. Causas frecuentes: error en la configuración de la aplicación (variables de entorno faltantes o incorrectas), liveness probe demasiado agresiva que mata el pod antes de que termine de iniciar, falta de recursos (OOMKilled con exit code 137), o dependencias externas (BD, secretos) no disponibles al momento de iniciar.

¿Cómo gestionarías el estado de Terraform en un equipo con múltiples desarrolladores trabajando sobre la misma infraestructura?

Almacenar el state en un backend remoto compartido (S3 + DynamoDB para locking en AWS, GCS en GCP, Terraform Cloud). El locking previene que dos personas apliquen cambios simultáneamente y corrompan el estado. Separar el state por entorno y por capa de infraestructura (red, cómputo, datos) para reducir el radio de impacto de un error. Revisar el plan en CI antes de aplicar manualmente en producción.

¿Qué diferencia hay entre un Deployment y un StatefulSet en Kubernetes y cuándo usarías cada uno?

Deployment: para aplicaciones stateless donde los pods son intercambiables. El scheduler puede crearlos, moverlos y eliminarlos libremente. StatefulSet: para aplicaciones que requieren identidad estable (hostname predecible), almacenamiento persistente por instancia y orden de inicio/parada determinístico. Usado para bases de datos, message brokers o cualquier servicio que mantenga estado local. Cada pod tiene un PersistentVolumeClaim propio que sobrevive al pod.

¿Cómo implementarías trazas distribuidas en un sistema de microservicios para correlacionar requests entre servicios?

Usar OpenTelemetry como estándar de instrumentación en cada servicio. Cada request genera un trace ID que se propaga en los headers HTTP entre servicios. Los spans representan operaciones individuales con duración y metadatos. Los traces se envían a un backend como Jaeger, Tempo o Datadog. La correlación permite ver el camino completo de un request lento o fallido a través de múltiples servicios, identificando en qué servicio ocurrió el problema.

¿Cómo diseñarías la estrategia de networking en un cluster de Kubernetes para aislar cargas de trabajo con distintos niveles de seguridad?

Usar namespaces para agrupar cargas de trabajo por equipo o nivel de sensibilidad. Implementar NetworkPolicies para controlar el tráfico entre pods: por defecto deny-all y luego permitir explícitamente solo las comunicaciones necesarias. Para aislamiento más fuerte, evaluar service mesh como Istio o Cilium para mutual TLS entre servicios y policies más granulares. Separar cargas de trabajo críticas en node pools dedicados con taints y tolerations.

¿Cómo garantizarías que un cambio de infraestructura en Terraform no tiene efectos no deseados antes de aplicarlo en producción?

Ejecutar terraform plan en CI y revisar el output antes de aprobar. Usar terraform plan -detailed-exitcode para fallar el pipeline si hay cambios inesperados. Implementar políticas de governance con Sentinel o OPA que rechacen automáticamente planes que violen reglas (ej. instancias sin tags, recursos sin encryption). En cambios de alto riesgo, hacer terraform apply en staging primero y comparar el comportamiento antes de aplicar en producción.

¿Qué estrategias usarías para reducir el costo de infraestructura cloud sin degradar el rendimiento o la disponibilidad?

Usar instancias spot o preemptibles para cargas de trabajo tolerantes a interrupciones (workers de colas, jobs de CI). Implementar autoscaling basado en métricas reales para no pagar por capacidad ociosa. Revisar los recursos subutilizados con herramientas de cost management (AWS Cost Explorer, Infracost). Elegir el tipo y tamaño de instancia correcto para cada carga con profiling real. Aplicar políticas de lifecycle a datos en S3 para mover a tiers más baratos automáticamente.

¿Cómo implementarías un proceso de rotación automática de credenciales de base de datos sin downtime para la aplicación?

Usar un gestor de secretos con soporte de rotación (AWS Secrets Manager, HashiCorp Vault). El proceso de rotación crea las nuevas credenciales, las valida, actualiza el secreto en el gestor, y luego revoca las antiguas. La aplicación debe obtener credenciales del gestor en cada conexión o implementar un mecanismo de renovación del pool de conexiones al detectar un error de autenticación. Probar el proceso completo en staging antes de habilitarlo en producción.

¿Cómo diseñarías la arquitectura de un sistema de despliegue que soporte múltiples equipos con distintos ritmos de release y niveles de autonomía?

Plataforma interna de developer experience (IDP) con abstracciones sobre Kubernetes (Backstage, Crossplane o Humanitec). Cada equipo tiene autonomía para desplegar dentro de guardrails definidos por el equipo de plataforma: cuotas de recursos, políticas de seguridad, patrones de observabilidad obligatorios. El equipo de plataforma es un enabler, no un gatekeeper. Los templates de golden path permiten a nuevos equipos empezar con todas las prácticas correctas por defecto.

¿Cómo implementarías disaster recovery para un sistema crítico con un RTO de 1 hora y RPO de 15 minutos?

RPO de 15 minutos requiere replicación de datos casi en tiempo real: streaming replication a una región secundaria o backups continuos con point-in-time recovery. RTO de 1 hora requiere infraestructura pre-provisionada en la región de DR (warm standby), no recrearla desde cero en el momento del desastre. Automatizar el failover con runbooks probados regularmente en ejercicios de DR. Documentar el RTO/RPO real medido, no el teórico.

¿Cómo estructurarías una estrategia de GitOps para gestionar el estado de múltiples clusters de Kubernetes en producción?

Un repositorio de configuración como fuente de verdad del estado deseado de cada cluster. Herramientas como ArgoCD o Flux sincronizan continuamente el cluster con el repositorio, detectando y corrigiendo drift automáticamente. Los cambios al cluster se hacen siempre mediante pull requests al repositorio, nunca con kubectl directo en producción. Esto proporciona audit trail completo, revisión de cambios y capacidad de rollback inmediato revirtiendo el commit.

¿Cómo diseñarías una estrategia de observabilidad para un sistema que procesa pagos con SLA de 99.99% de disponibilidad?

Definir SLIs precisos: tasa de éxito de transacciones, latencia p99, tiempo de procesamiento end-to-end. SLOs con error budgets pequeños dado el 99.99% objetivo. Alertas en múltiples niveles: alertas de burn rate que detecten degradación antes de que el SLO se vea afectado. Trazas distribuidas para cada transacción. Dashboards de negocio (transacciones por segundo, volumen) y técnicos (latencia, error rate) separados. On-call con escalation policy clara y runbooks probados.

¿Cómo evaluarías si un equipo de desarrollo está listo para adoptar despliegue continuo y qué cambios de proceso y técnicos serían necesarios?

Prerequisitos técnicos: suite de tests con alta confiabilidad, feature flags para desacoplar deploy de release, capacidad de rollback en menos de 5 minutos, y observabilidad que detecte regresiones rápidamente. Prerequisitos de proceso: cultura donde los desarrolladores son responsables del código en producción, deployments pequeños y frecuentes (no batches grandes), y postmortems sin culpa que impulsen mejoras. El mayor bloqueador suele ser cultural, no técnico.

¿Cómo abordarías la reducción del blast radius de un incidente en una arquitectura de microservicios con dependencias complejas?

Implementar circuit breakers para evitar que el fallo de un servicio se propague en cascada. Diseñar degradación elegante: si un servicio de recomendaciones falla, mostrar resultados por defecto en lugar de fallar toda la página. Usar bulkheads para aislar los thread pools de dependencias críticas de las no críticas. Establecer timeouts agresivos en todas las llamadas entre servicios. Hacer chaos engineering controlado regularmente para validar que los mecanismos de aislamiento funcionan como se espera.

Confundir conocer herramientas con entender los principios que resuelven

Saber usar Terraform no equivale a entender gestión de estado, drift detection o estrategias de módulos a escala. Los entrevistadores de empresas con infraestructura compleja preguntan el 'por qué' detrás de cada herramienta. Un candidato que solo puede describir comandos sin explicar las decisiones de diseño no diferencia entre junior y senior.

No mencionar observabilidad al diseñar o proponer cambios de infraestructura

Proponer una arquitectura sin responder cómo sabrás que funciona correctamente en producción, cómo detectarás degradación o cómo diagnosticarás un incidente es una señal de pensamiento incompleto. La observabilidad no es un add-on; es parte del diseño desde el inicio.

Hablar de automatización sin mencionar las fases de validación y los mecanismos de rollback

Automatizar un deploy sin mencionar qué lo detiene si algo va mal, cómo se detecta el problema y cómo se revierte genera más riesgo que el proceso manual. Los entrevistadores de empresas con alta frecuencia de deploys preguntan específicamente por estos mecanismos de seguridad.

No considerar el costo como una variable de diseño en decisiones de infraestructura

Proponer soluciones altamente disponibles sin mencionar su costo, o sin evaluar si el nivel de disponibilidad justifica ese costo para el caso de uso específico, muestra falta de madurez en el rol. El DevOps engineer debe poder articular el trade-off entre confiabilidad y costo con datos concretos.

Describir procesos de on-call sin mencionar cómo se reduce la carga operacional con el tiempo

Un equipo que normaliza el pager noise, las alertas ruidosas o los incidentes repetitivos sin generar action items para eliminarlos está en un ciclo de deuda operacional. Los entrevistadores maduros preguntan qué hiciste después del incidente para que no se repita, no solo cómo lo resolviste.

Proponer Kubernetes como solución para cualquier problema de infraestructura sin evaluar la complejidad que añade

Kubernetes resuelve problemas reales a escala, pero añade una capa significativa de complejidad operacional. Proponerlo para una startup con un equipo de 3 personas o una aplicación con 100 usuarios diarios muestra falta de criterio sobre el ajuste entre la solución y el problema. Un DevOps maduro evalúa si el problema justifica esa complejidad.

Ingeniero DevOps

Acelera la entrega de software construyendo los sistemas, pipelines y cultura que conectan desarrollo con producción.

Un DevOps Engineer diseña y mantiene la infraestructura, los pipelines de integración y entrega continua, y las prácticas operacionales que permiten a los equipos de desarrollo desplegar software de forma rápida, confiable y segura. Su trabajo abarca desde la automatización de builds y despliegues hasta la observabilidad de sistemas en producción, la gestión de infraestructura como código y la respuesta a incidentes. Actúa como puente entre los equipos de desarrollo y operaciones, promoviendo una cultura de responsabilidad compartida sobre la confiabilidad del sistema.

DockerKubernetesTerraformCI/CDAWSObservabilidad

Recluta al mejor Ingeniero DevOps aquí

Empieza ahora

Responsabilidades Principales

•Diseñar, implementar y mantener pipelines de CI/CD que automaticen el build, testing y despliegue de aplicaciones en múltiples entornos.
•Gestionar infraestructura como código con herramientas como Terraform o Pulumi, garantizando reproducibilidad y control de versiones.
•Administrar clusters de Kubernetes y plataformas cloud, optimizando costos, disponibilidad y escalabilidad.
•Implementar sistemas de observabilidad con métricas, logs y trazas distribuidas para detectar y diagnosticar problemas en producción.
•Definir y ejecutar procesos de respuesta a incidentes, incluyendo runbooks, postmortems y mejoras preventivas.
•Asegurar que la infraestructura y los pipelines cumplan con políticas de seguridad, compliance y gestión de secretos.

Habilidades Clave

Technical Skills

Contenerización con Docker y orquestación con Kubernetes: deployments, services, ingress, RBAC y gestión de recursos
Infraestructura como código con Terraform o Pulumi: módulos, state management, workspaces y políticas de drift
Plataformas cloud (AWS, GCP o Azure) con conocimiento profundo de sus servicios de cómputo, red, almacenamiento y seguridad
Diseño e implementación de pipelines CI/CD con GitHub Actions, GitLab CI, Jenkins o equivalentes
Observabilidad: métricas con Prometheus/Grafana, logs con ELK o Loki, y trazas distribuidas con OpenTelemetry
Scripting y automatización con Bash, Python o Go para tareas operacionales y herramientas internas

Soft Skills

Mentalidad de confiabilidad: pensar primero en cómo puede fallar un sistema antes de pensar en cómo construirlo
Comunicación clara durante incidentes para coordinar respuesta técnica y mantener informados a stakeholders no técnicos
Colaboración con equipos de desarrollo para diseñar sistemas que sean operables desde el inicio, no como afterthought
Documentación rigurosa de runbooks, decisiones de arquitectura y postmortems que el equipo pueda consumir y actualizar
Capacidad de priorizar mejoras de confiabilidad frente a nuevas features bajo presión de negocio
Pensamiento sistémico para identificar puntos de fallo únicos y dependencias ocultas en arquitecturas complejas

Casos de uso reales

Contexto

Un pipeline bien diseñado reduce el tiempo desde que se hace commit hasta que el código llega a producción, con todas las validaciones necesarias para mantener la calidad y seguridad.

Ejemplos reales

Pipelines con stages de lint, test, build, scan de vulnerabilidades y deploy
Estrategias de despliegue blue-green o canary para releases sin downtime
Rollback automático basado en métricas de error rate o latencia post-deploy
Ambientes efímeros por pull request para testing aislado antes de merge

Contexto

La infraestructura como código permite tratar los recursos cloud con las mismas prácticas de ingeniería que el software: revisión, versionado, testing y reproducibilidad.

Ejemplos reales

Módulos Terraform reutilizables para redes, cómputo y bases de datos
Gestión de múltiples entornos (dev, staging, prod) con workspaces o stacks separados
Detección automática de drift entre el estado declarado y la infraestructura real
Políticas de compliance como código con Sentinel o OPA

Contexto

En sistemas con múltiples servicios, la observabilidad es lo que permite diagnosticar dónde y por qué falla algo cuando un usuario reporta un problema.

Ejemplos reales

Stack de métricas con Prometheus y dashboards operacionales en Grafana
Correlación de logs, métricas y trazas con un correlation ID único por request
Alertas con runbooks asociados para reducir el tiempo de respuesta en incidentes
SLIs, SLOs y error budgets como marco de trabajo para decisiones de confiabilidad

Contexto

Los secretos (credenciales, API keys, certificados) son el vector de ataque más común en infraestructura cloud. Su gestión incorrecta es causa frecuente de brechas de seguridad.

Ejemplos reales

Integración de HashiCorp Vault o AWS Secrets Manager en pipelines y aplicaciones
Rotación automática de credenciales de base de datos y API keys
Escaneo de secretos en commits con herramientas como Gitleaks o Trufflehog
Principio de mínimo privilegio en roles IAM y service accounts de Kubernetes

Contexto

Los sistemas fallan. La diferencia entre organizaciones maduras e inmaduras en operaciones es la velocidad de detección, respuesta y la capacidad de aprender de cada incidente.

Ejemplos reales

Runbooks automatizados para los incidentes más frecuentes
Postmortems sin culpa que generan action items medibles
Chaos engineering controlado para descubrir debilidades antes de que las encuentre la producción
Guardias de on-call con rotación equitativa y reducción progresiva de alertas ruidosas