Preguntas de entrevista Ingeniero DevOps

Empiezo por entender qué necesita el equipo para entregar de forma segura y rápida, no por elegir herramientas. Mapeo las etapas por las que debe pasar el código: build, test, escaneo de seguridad, empaquetado, despliegue en staging y promoción a producción. Automatizo cada etapa y defino criterios de promoción claros para que nada avance sin cumplir los umbrales de calidad. Para un proyecto típico usaría GitHub Actions o GitLab CI para el pipeline, con builds en contenedores para mantener la consistencia de los entornos. Incluyo pruebas unitarias y de integración automatizadas al principio del pipeline para que los fallos aparezcan rápido y a bajo coste. También incorporo el escaneo de seguridad a nivel de imagen y dependencias en lugar de tratarlo como una preocupación post-despliegue. El objetivo es que cada commit en la rama principal sea desplegable. Trato el pipeline como código y lo versiono junto a la aplicación.

Trato la infraestructura como código como un principio fundamental, no como una optimización. Si la infraestructura no está en control de versiones, no puede revisarse, probarse ni reproducirse de forma fiable. Mi herramienta preferida para infraestructura cloud-agnóstica es Terraform por su sintaxis declarativa, ecosistema de proveedores y comunidad sólida. Para gestión de configuración uso Ansible cuando necesito gestionar el estado en máquinas existentes, y para Kubernetes uso Helm para el empaquetado y ArgoCD para la entrega estilo GitOps. Organizo Terraform en módulos por dominio para mantener la composabilidad y reutilización entre entornos. También impongo un flujo de trabajo plan antes de apply en CI para que los cambios de infraestructura se revisen como cambios de código.

Pienso la observabilidad en términos de los tres pilares: métricas, logs y trazas. Las métricas te dicen que algo va mal, los logs te dicen qué ocurrió, y las trazas te dicen dónde en un sistema distribuido se originó el problema. Mi enfoque estándar es instrumentar las aplicaciones con logs estructurados desde el principio, exportar métricas a una base de datos de series temporales como Prometheus y usar trazado distribuido con OpenTelemetry para entender los flujos de peticiones. Construyo dashboards que reflejan las cuatro señales doradas: latencia, tráfico, errores y saturación. También configuro alertas sobre síntomas que importan a los usuarios, no sobre umbrales de recursos de bajo nivel. El test que aplico a cualquier alerta es: si se dispara a las 3 de la madrugada, ¿vale la pena despertar a alguien?

Tuvimos un agotamiento del pool de conexiones a la base de datos que dejó fuera de servicio nuestro servicio principal durante 35 minutos un martes por la tarde. Estaba de guardia y asumí el mando del incidente. Mi primer paso fue declarar el incidente formalmente, abrir un canal de comunicación dedicado y alertar a los ingenieros relevantes sin inundar el canal de ruido. Mantuve separadas las comunicaciones internas y externas y di a nuestro director de ingeniería una actualización factual breve cada 10 minutos. La mitigación inmediata fue un reinicio y un aumento del límite del pool, que restauró el servicio en 12 minutos. La causa raíz era un job en segundo plano reciente con una liberación de conexión faltante en una condición de error. El cambio de proceso fue añadir una métrica del pool de conexiones a nuestro dashboard principal y una prueba de circuit breaker a nuestras pruebas de carga pre-producción.

Cuando me incorporé a mi equipo anterior, los despliegues a producción ocurrían una vez a la semana los viernes por la tarde y requerían un runbook manual de 30 minutos ejecutado por dos ingenieros. Construí un pipeline completamente automatizado con pruebas de humo automatizadas, despliegue blue-green en nuestro cluster de Kubernetes y rollback automático si las pruebas fallaban. En dos meses estábamos desplegando varias veces al día sin pasos manuales y con un tiempo medio de recuperación de un despliegue fallido de menos de cuatro minutos. La frecuencia de despliegue es una de las métricas DORA, y mejorarla correlacionó directamente con una reducción en la tasa de fallos de cambios.

Cuando me incorporé a una startup sin proceso de guardia, introduje una rotación de guardia ligera y una plantilla sencilla de respuesta a incidentes. Conduje un post-mortem sin culpas tras el primer incidente significativo bajo el nuevo proceso y reconocí explícitamente al ingeniero que había señalado honestamente un fallo de diseño. Durante el trimestre siguiente hice tres sesiones de aprendizaje interno sobre principios SRE, cada una de menos de 30 minutos, y publiqué una lista de comprobación de preparación operativa para nuevos servicios. Al final del año cada equipo tenía una rotación de guardia, los tiempos de respuesta a incidentes habían mejorado y los ingenieros hacían voluntariamente post-mortems sobre casi-incidentes.

Nunca almaceno secretos en variables de entorno codificadas en manifiestos de despliegue o código fuente, y nunca los hago commit en control de versiones. Mi enfoque preferido en un entorno Kubernetes es usar una herramienta de gestión de secretos como HashiCorp Vault o AWS Secrets Manager, con la aplicación recuperando los secretos en tiempo de ejecución a través de un sidecar o init container. Roto los secretos regularmente y automatizo la rotación donde el proveedor lo permite. Para pipelines CI/CD uso la gestión de secretos integrada en la plataforma. También sigo el principio de mínimo privilegio para todas las cuentas de servicio: cada servicio solo debe poder leer los secretos que necesita.

La seguridad de contenedores empieza a nivel de imagen. Uso imágenes base mínimas, escaneo imágenes en CI para vulnerabilidades conocidas con una herramienta como Trivy o Snyk, y aplico una política que bloquea el despliegue de imágenes por encima de un umbral de gravedad. En Kubernetes aplico políticas de red para restringir el tráfico entre pods, uso RBAC para limitar lo que pueden hacer las cuentas de servicio, y ejecuto pods como usuarios no-root con sistemas de archivos raíz de solo lectura donde sea posible. Uso admission controllers para aplicar políticas a nivel de cluster. Para los secretos uso un almacén dedicado en lugar de Kubernetes Secrets, que solo están en base64 a menos que configures el cifrado en reposo.

Empiezo por la visibilidad: no puedes optimizar lo que no puedes ver. Configuro dashboards de costes que desglosan el gasto por equipo, servicio y entorno para que las personas que toman decisiones arquitectónicas vean las implicaciones en tiempo real. Para el dimensionamiento, miro la utilización real de recursos durante una ventana de 30 días antes de hacer cambios. Uso autoescalado horizontal para cargas de trabajo sin estado y reservas o descuentos por uso comprometido para la carga de base predecible. También programo el apagado de entornos que no son producción fuera del horario laboral. Para el almacenamiento aplico políticas de ciclo de vida para mover automáticamente los datos poco consultados a niveles más económicos.