3) Preguntas técnicas y profesionales (las que separan a un SRE real)
Aquí se decide el rol. En Chile muchas empresas están en AWS/Azure, con Kubernetes, microservicios y observabilidad a medias. Te van a pedir criterio: no solo “sé usar X”, sino “cuándo X es mala idea”. Para calibrar, mira requisitos reales en avisos de empleo de SRE en LinkedIn Jobs, Get on Board e Indeed Chile (patrones: Kubernetes, Terraform, CI/CD, Prometheus/Grafana, incident management).
Q: Explícame la diferencia entre SLI, SLO y SLA, y cómo los usas para tomar decisiones de despliegue.
Why they ask it: Miden si entiendes el “contrato” de confiabilidad y el rol del error budget.
Answer framework: Definición → ejemplo → decisión (con error budget).
Example answer: “SLI es la métrica de experiencia (p. ej., tasa de éxito de checkout). SLO es el objetivo interno (99,9% mensual) y SLA es el compromiso externo con consecuencias. Para despliegues, uso el error budget: si estamos cerca de agotarlo, reduzco riesgo con canary más lento, congelo cambios no críticos o priorizo fixes. Si hay holgura, puedo acelerar releases con controles.”
Common mistake: Confundir SLA con SLO o hablar solo en términos de ‘uptime’.
Q: ¿Qué métricas y señales usarías para detectar degradación en un servicio de pagos en tiempo real?
Why they ask it: Quieren ver si piensas en “golden signals” y en experiencia de usuario.
Answer framework: Golden Signals (latencia, tráfico, errores, saturación) + métricas de negocio.
Example answer: “Parto por latencia p95/p99 por endpoint crítico, tasa de éxito y errores por tipo (4xx/5xx, timeouts). Agrego saturación: CPU, memoria, conexiones DB, colas y rate limits. Y cruzo con señales de negocio: tasa de aprobación, abandonos y reintentos. Lo clave es alertar por impacto al usuario, no por métricas internas aisladas.”
Common mistake: Alertar por CPU alta sin correlación con errores/latencia.
Q: ¿Cómo diseñarías la observabilidad para microservicios en Kubernetes: logs, métricas y trazas?
Why they ask it: Evalúan si puedes construir un sistema observable, no solo instalar herramientas.
Answer framework: “Tres pilares + correlación” (IDs, contexto, sampling, cardinalidad).
Example answer: “En métricas uso Prometheus con etiquetas controladas para evitar cardinalidad explosiva y dashboards en Grafana. En logs, JSON estructurado con trace_id/request_id y niveles consistentes; centralizo con Loki o ELK según el stack. En trazas, OpenTelemetry para instrumentación y un backend tipo Jaeger/Tempo. Lo importante es correlacionar: desde una alerta por SLO puedo saltar a trazas y luego a logs del pod exacto.”
Common mistake: Montar herramientas sin estándares de logging ni estrategia de correlación.
Q: ¿Qué estrategia de despliegue prefieres (blue/green, canary, rolling) y cuándo NO la usarías?
Why they ask it: Buscan criterio de riesgo y entendimiento del sistema.
Answer framework: “Contexto → riesgo → control” (tipo de cambio, reversibilidad, estado, DB).
Example answer: “Canary me gusta cuando puedo medir impacto rápido con SLIs y revertir sin dolor. Blue/green sirve si el cambio es grande y el costo de duplicar infraestructura es aceptable. Rolling es simple, pero puede ser peligroso si hay incompatibilidades. Si hay migraciones de base de datos no reversibles, priorizo enfoque expand/contract, feature flags y compatibilidad hacia atrás.”
Common mistake: Elegir una estrategia como dogma, sin hablar de DB y reversibilidad.
Q: ¿Cómo gestionas la confiabilidad cuando dependes de terceros (pasarelas, SMS, APIs) con SLAs débiles?
Why they ask it: En Chile es común depender de proveedores regionales; quieren resiliencia real.
Answer framework: Resiliencia por capas (timeouts, retries con backoff, circuit breaker, degradación).
Example answer: “Defino timeouts agresivos y retries con backoff y jitter, cuidando idempotencia. Implemento circuit breakers para cortar cascadas y colas para desacoplar. Si el tercero cae, diseño degradación: por ejemplo, permitir ‘pago pendiente’ o reintento asíncrono. Y monitoreo el proveedor como parte del SLO del journey, no como un ‘problema externo’.”
Common mistake: Reintentos infinitos que amplifican la caída del proveedor.
Q: ¿Qué opinas de ‘toil’? Dame ejemplos y cómo lo reducirías en un equipo SRE.
Why they ask it: Quieren mentalidad SRE: automatizar lo repetitivo y proteger foco.
Answer framework: Definición Google SRE → inventario → automatización → guardrails.
Example answer: “Toil es trabajo manual, repetitivo, sin valor duradero: reinicios, tickets iguales, deploys manuales. Lo reduzco midiendo horas/semana, atacando el top 3 con automatización (scripts, self-service, pipelines) y mejorando calidad upstream (tests, validaciones). También pongo guardrails: runbooks, ownership claro y límites al soporte ad-hoc.”
Common mistake: Llamar ‘toil’ a cualquier tarea que no te gusta, sin criterios.
Q: En Terraform, ¿cómo evitas cambios peligrosos en producción y cómo manejas el estado (state) en equipo?
Why they ask it: Infra como código es central; buscan prácticas seguras.
Answer framework: “Control de cambios” (remote state, locking, PRs, plan/apply, entornos).
Example answer: “Uso remote state con locking (por ejemplo S3 + DynamoDB o equivalente en Azure) y separo workspaces/estados por entorno. Todo cambio va por PR con revisión y terraform plan en CI; el apply se hace con permisos controlados y, si aplica, ventanas de cambio. Para recursos críticos, agrego políticas (OPA/Conftest) y módulos versionados.”
Common mistake: Ejecutar apply local sin revisión ni locking, generando drift y conflictos.
Q: ¿Cómo asegurarías alta disponibilidad en una base de datos crítica sin disparar costos?
Why they ask it: Quieren trade-offs: RPO/RTO, replicación, backups, pruebas.
Answer framework: Requisitos → opciones → decisión (RPO/RTO + costo + complejidad).
Example answer: “Primero aclaro RPO/RTO por caso de uso. Luego comparo opciones: réplica en otra zona, failover administrado, o read replicas según patrón de lectura. Mantengo backups con retención y pruebas de restore (no solo ‘tenemos backup’). Y optimizo costo: dimensionamiento correcto, escalado por demanda y evitar sobre-replicar si el RTO lo permite.”
Common mistake: Prometer ‘cero downtime’ sin hablar de RPO/RTO ni pruebas de recuperación.
Q: ¿Qué harías si Prometheus/Grafana (o tu stack de monitoreo) se cae durante un incidente?
Why they ask it: Buscan planes de contingencia y pensamiento de “observabilidad resiliente”.
Answer framework: Mitigación primero → fuentes alternativas → hardening posterior.
Example answer: “Si el monitoreo cae, vuelvo a señales básicas: health checks, métricas del cloud provider, logs centralizados y pruebas sintéticas desde fuera. Priorizo restaurar visibilidad mínima (un dashboard de ‘servicio arriba/abajo’ y errores) aunque sea temporal. Después del incidente, hardening: alta disponibilidad del stack, retención, y alertas fuera de banda (por ejemplo, checks externos).”
Common mistake: Quedarte paralizado porque ‘sin dashboards no se puede’.
Q: En Chile, si trabajas con datos personales, ¿qué prácticas de seguridad y cumplimiento consideras mínimas en operación?
Why they ask it: Muchas empresas están bajo presión por privacidad y auditorías; quieren higiene básica.
Answer framework: “Datos → controles → evidencia” (clasificación, acceso, trazabilidad).
Example answer: “Parto por minimizar exposición: secretos en un vault, rotación y principio de menor privilegio. En logs, evito PII y aplico mascaramiento. Aseguro trazabilidad: auditoría de accesos, cambios de infraestructura y despliegues. Y mantengo evidencia operativa: postmortems, runbooks y controles que soporten auditorías internas, alineándome a marcos como ISO/IEC 27001 cuando aplica.”
Common mistake: Responder solo con ‘encriptamos todo’ sin hablar de accesos, secretos y logging.