Preguntas de entrevista Ingeniero de plataforma

Trato una plataforma de desarrollador interna como un producto cuyos usuarios son los ingenieros, lo que significa aplicar los mismos mecanismos de investigación de usuarios, iteración y bucles de feedback que los equipos de producto usan externamente. Lo más importante que puede hacer un equipo de plataforma es reducir la carga cognitiva: cada decisión que un desarrollador no tiene que tomar sobre infraestructura es una decisión que puede dedicar a su problema real. Una plataforma exitosa tiene un camino dorado claro, una forma opinionada y bien documentada de desplegar y operar un servicio, pero no obliga a los desarrolladores a usarlo en todos los casos. El camino dorado debe cubrir el 80% de los casos de uso con fricción mínima. Para el 20% restante, la plataforma debe proporcionar salidas de emergencia bien documentadas. El mayor modo de fallo que veo es los equipos de plataforma construyendo infraestructura para sí mismos en lugar de para sus usuarios.

Un pipeline CI/CD que escala a múltiples equipos tiene que equilibrar estandarización con flexibilidad. Mi enfoque es definir un conjunto de plantillas de pipeline reutilizables que cubran los patrones más comunes: construir y probar un servicio, construir y subir una imagen de contenedor, desplegar en un cluster de Kubernetes con capacidad de rollback. Estas plantillas son mantenidas centralmente por el equipo de plataforma y versionadas, para que los equipos consuman una versión etiquetada en lugar de una referencia flotante. Dentro de cada plantilla hay puntos de extensión bien documentados donde los equipos pueden añadir pasos personalizados sin bifurcar todo el pipeline. También invierto en feedback rápido: los pipelines que tardan 20 minutos en completarse serán evitados en lugar de usados. Apunto a un bucle de feedback de 5 minutos para pruebas unitarias y linting, y reservo las pruebas de integración más largas para controles previos a la fusión.

Pienso en la observabilidad en términos de los tres pilares, métricas, logs y trazas, pero el objetivo siempre es poder responder "¿por qué es esto lento o está roto?" sin tener que desplegar nuevo código. Para las métricas instrumento los servicios con métricas RED (Rate, Errors, Duration) como baseline. Para los logs impongo logging estructurado en todos los servicios con un esquema coherente que incluye ID de traza, nombre del servicio y severidad, para que los logs de diferentes servicios se puedan correlacionar en una sola consulta. Para las trazas uso tracing distribuido con una estrategia de muestreo que captura el 100% de las trazas de error y un porcentaje configurable de las trazas de éxito. También construyo paneles a nivel de servicio que cualquier ingeniero de guardia puede leer sin conocimiento profundo del servicio específico. La medida de una buena configuración de observabilidad es el tiempo medio de diagnóstico.

Las actualizaciones de Kubernetes son una de las tareas más delicadas desde el punto de vista operativo que realiza un equipo de plataforma, y la clave es tratarlas como una migración sin tiempo de inactividad en lugar de una ventana de mantenimiento. Mi enfoque comienza tres meses antes de una versión objetivo probando la nueva versión en un cluster de prueba dedicado con una muestra de carga de trabajo representativa. Ejecuto la nueva versión en paralelo con el cluster existente durante cuatro a seis semanas, buscando advertencias de deprecación, cambios de API y diferencias de comportamiento. Documento los cambios disruptivos y los comunico a los equipos de ingeniería con al menos seis semanas de antelación. La migración real usa un enfoque de cluster blue-green: provisionó un nuevo cluster en la versión objetivo, migra las cargas de trabajo servicio por servicio con desplazamiento del tráfico en el nivel del balanceador de carga, y mantiene el cluster antiguo activo durante dos semanas por si se necesita rollback.

Me uní a un equipo donde los ingenieros tardaban una media de cuatro horas en configurar un nuevo servicio desde cero, porque no había una plantilla estándar y cada servicio tenía diferentes patrones de logging, configuración y despliegue. Realicé cinco entrevistas cortas con desarrolladores para entender los mayores puntos de dolor, luego construí una herramienta de scaffolding que generaba un esqueleto de servicio listo para producción en menos de dos minutos con valores por defecto opinionados. Antes del cambio medí el tiempo de configuración observando a ingenieros pasar por el proceso. Seis semanas después del lanzamiento repetí la medición y encontré que el tiempo medio de configuración había bajado de cuatro horas a 25 minutos. La encuesta de satisfacción de los desarrolladores mostró que las herramientas eran el área más mejorada ese trimestre.

Subí una actualización de nuestras imágenes de contenedor base que incluía una versión más reciente de una biblioteca compartida. La había probado contra nuestros propios servicios de plataforma pero no había comprobado todos los servicios consumidores. Dentro de las dos horas del despliegue, tres equipos reportaron builds rotos porque la actualización de la biblioteca introdujo un cambio de API disruptivo que no era retrocompatible. Mi respuesta inmediata fue revertir la imagen base a la versión anterior y enviar una actualización clara del incidente a todos los equipos afectados en 15 minutos. Una vez resuelto el problema inmediato, realicé una revisión post-incidente. La causa raíz era que no teníamos pruebas de compatibilidad automatizadas para actualizaciones de bibliotecas compartidas. Construí un pipeline de pruebas que valida los cambios de imagen base contra los 20 servicios consumidores principales antes de cualquier publicación.

Gestionaba un backlog de plataforma donde dos equipos tenían necesidades urgentes en competencia: el Equipo A quería mejorar el rendimiento de las consultas de logs porque su tiempo de depuración había aumentado significativamente, y el Equipo B quería rotación de secretos de autoservicio porque su auditoría de seguridad había señalado un proceso manual. Realicé una sesión de priorización estructurada con ambos equipos, presentando honestamente la capacidad del equipo de plataforma y pidiendo a cada equipo que cuantificara el coste del retraso. La solicitud del Equipo B tenía una fecha límite de cumplimiento que la hacía objetivamente más prioritaria. Me comprometí con el Equipo A con una fecha de entrega específica en cuatro semanas y les di un workaround temporal mientras tanto. Luego entregué la solicitud del Equipo B en tres semanas y la del Equipo A en la semana cinco.

Terraform a escala tiene tres desafíos principales: gestión del estado, reutilización de módulos y prevención de la deriva. Para el estado uso un backend remoto con bloqueo, típicamente S3 y DynamoDB en AWS, y separo el estado por entorno y por frontera de servicio para que un apply fallido en un área no pueda corromper el estado de otra. Organizo el código Terraform en un repositorio de módulos y un repositorio de configuraciones. El repositorio de módulos contiene módulos versionados y probados que codifican los estándares organizacionales: un módulo de namespace de Kubernetes estándar que incluye RBAC, políticas de red y cuotas de recursos; un módulo de base de datos estándar que impone cifrado en reposo y copias de seguridad automatizadas. Los equipos referencian versiones específicas de módulos en sus configuraciones. Ejecuto un Terraform plan automatizado en CI en cada pull request. La detección de deriva se ejecuta en un horario nocturno y alerta sobre cualquier diferencia inesperada.

Los problemas de vecino ruidoso en Kubernetes surgen cuando una carga de trabajo consume más CPU o memoria de lo esperado e impacta otras cargas de trabajo en el mismo nodo. La defensa principal es una configuración correcta de los requests y limits de recursos, pero establecerlos con precisión requiere datos, no suposiciones. Uso una combinación de VPA (Vertical Pod Autoscaler) en modo recomendación para recopilar datos sobre el uso real de recursos durante dos semanas antes de establecer requests y limits, e impongo que cada despliegue debe tener requests y limits definidos usando políticas de control de admisión. También uso namespaces de Kubernetes con ResourceQuota y LimitRange para evitar que un solo equipo consuma más de su cuota asignada de la capacidad del cluster. Para cargas de trabajo con perfiles de recursos muy diferentes, uso selectores de nodos y taints para co-localizar cargas similares en pools de nodos dedicados.

La gestión de secretos a escala tiene que resolver tres problemas: almacenamiento seguro, acceso controlado y rotación sin interrupción del servicio. Para el almacenamiento uso un gestor de secretos dedicado, ya sea HashiCorp Vault o AWS Secrets Manager, e impongo que ningún secreto aparezca nunca en variables de entorno al nivel de Kubernetes o en control de versiones. Los secretos se inyectan en el momento de la creación del pod a través de un driver CSI o un webhook de admisión que extrae del gestor de secretos, para que los desarrolladores no necesiten gestionar manualmente los secretos en los manifiestos de despliegue. Para el control de acceso uso políticas que otorgan a cada servicio acceso solo a los secretos específicos que necesita, basadas en la identidad de la cuenta de servicio de Kubernetes. Para la rotación la automatizo usando la función de rotación del gestor de secretos con funciones Lambda que actualizan el secreto y luego disparan un reinicio gradual de los despliegues afectados.