Preguntas de entrevista Intermedio DevOps / SRE

Qué se espera en el nivel Intermedio

Se espera CI/CD, Kubernetes, observabilidad y responsabilidad autónoma de guardia.

Preguntas de ejemplo para entrevista de DevOps / SRE

• TécnicaUn servicio está lento. Explica cómo lo depuras desde el sistema operativo hacia arriba.
  Lo que cubre una buena respuesta

  • top, htop, vmstat para CPU/memoria
  • iostat, iotop para disco
  • netstat, tcpdump para red
  • strace/ltrace para llamadas al sistema
  • perf para contadores de CPU

  Ver respuesta de ejemplo

  Para depurar un servicio lento desde el sistema operativo, primero reviso la carga general con top o htop, observando %CPU, %MEM y load average. Luego uso vmstat para ver si hay cuellos de botella en CPU (context switches, interrupciones) o memoria (swapping). Con iostat y iotop analizo el rendimiento de disco: si hay altos tiempos de espera (await >10ms) o %util cercano al 100%, podría ser E/S. Para red, netstat -s muestra errores, y tcpdump captura paquetes si sospecho latencia de red. Si todo lo anterior es normal, recurro a strace para ver las llamadas al sistema del proceso, identificando syscalls lentas como read/write o select. Finalmente, perf permite muestrear eventos de CPU como cache misses o branches mispredictions. El error común es saltar directamente a la aplicación sin descartar problemas del sistema.

• Técnica¿Qué ocurre, paso a paso, cuando escribes una URL y pulsas enter?
  Lo que cubre una buena respuesta

  • DNS resolution
  • TCP three-way handshake
  • TLS negotiation
  • HTTP request/response
  • Rendering y carga de recursos

  Ver respuesta de ejemplo

  Cuando escribes una URL y pulsas enter, primero el navegador interpreta la URL y verifica la caché local de DNS. Si no está cacheada, realiza una consulta DNS recursiva: raíz → TLD → servidor autoritativo, obteniendo la dirección IP. Luego inicia una conexión TCP con un three-way handshake (SYN, SYN-ACK, ACK). Si la URL usa HTTPS, se negocia TLS: ClientHello, ServerHello, intercambio de certificados, derivación de claves. Una vez establecido el canal seguro, envía una petición HTTP GET al servidor. El servidor procesa y responde con un código de estado (200 OK) y el contenido HTML. El navegador parsea el HTML y descarga recursos adicionales (CSS, JS, imágenes) en paralelo, cada uno con su propia conexión. Finalmente renderiza la página ejecutando JavaScript y aplicando estilos. Un error común es olvidar que las optimizaciones como HTTP/2 o CDN alteran este flujo.

• Técnica¿En qué se diferencian las sondas liveness y readiness de Kubernetes?
  Lo que cubre una buena respuesta

  • liveness: reinicia el contenedor si falla
  • readiness: elimina el Pod del Service si no está listo
  • startup probe: retrasa liveness en arranques lentos
  • periodSeconds, failureThreshold, initialDelaySeconds
  • Ejemplo: app que necesita cargar datos grandes usa startup

  Ver respuesta de ejemplo

  En Kubernetes, las sondas liveness y readiness son mecanismos de health check. La sonda liveness verifica si el contenedor sigue en ejecución; si falla, kubelet reinicia el contenedor. La sonda readiness indica si el contenedor está listo para recibir tráfico; si falla, se elimina el Pod del endpoint de los Services, pero no se reinicia. También existe la sonda startup, que se ejecuta una vez al inicio y desactiva las liveness hasta que el contenedor esté listo; útil para aplicaciones con arranque lento (ej. que cargan grandes modelos en memoria). Un error frecuente es usar la misma sonda para ambos propósitos o no configurar adecuadamente initialDelaySeconds y failureThreshold, causando reinicios innecesarios durante el arranque. La recomendación es tener readiness más flexible (por ejemplo, verificar un endpoint interno que sepa si la app puede servir peticiones) y liveness más estricta (por ejemplo, si el proceso principal muere).

• ProgramaciónEscribe un script que analice logs y reporte las tasas de error más altas.
  Lo que cubre una buena respuesta

  • Parsea logs con expresiones regulares
  • Agrupa por minuto/hora y cuenta errores
  • Calcula tasa: errores / total peticiones
  • Reporta las 5 mayores tasas
  • Usa dicts con ventanas de tiempo

  Ver respuesta de ejemplo

  El script que presento analiza logs en formato común (ej. Nginx) y calcula la tasa de error (códigos 4xx/5xx) por minuto. Primero define una expresión regular para extraer la fecha y el código de estado. Luego itera sobre cada línea, normaliza el timestamp al minuto y cuenta totales y errores en un diccionario. Al final, para cada minuto calcula la tasa y almacena en una lista, ordena descendente y reporta las 5 más altas. La complejidad es O(n) en tiempo y O(m) en espacio, donde m es el número de minutos únicos. Un error común es no considerar la zona horaria o mezclar formatos de log. El script es ejecutable con python script.py <archivo>.

  #!/usr/bin/env python3
  import sys
  import re
  from collections import defaultdict
  from datetime import datetime
  
  def parse_log_line(line):
      # Formato: 192.168.1.1 - - [10/Oct/2023:13:55:36 +0000] "GET / HTTP/1.1" 200 1234
      pattern = r'\[(\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2}) .+?" (\d{3})'
      match = re.search(pattern, line)
      if not match:
          return None
      ts_str = match.group(1)
      status = match.group(2)
      # Convertir a timestamp normalizado al minuto
      dt = datetime.strptime(ts_str, '%d/%b/%Y:%H:%M:%S')
      minute_key = dt.strftime('%Y-%m-%d %H:%M')  # Ej: 2023-10-10 13:55
      return minute_key, status
  
  def main():
      if len(sys.argv) != 2:
          print("Uso: python analisis_logs.py <archivo_log>")
          sys.exit(1)
      
      logfile = sys.argv[1]
      total_by_minute = defaultdict(int)
      error_by_minute = defaultdict(int)
      
      with open(logfile, 'r') as f:
          for line in f:
              result = parse_log_line(line)
              if result:
                  minute, status = result
                  total_by_minute[minute] += 1
                  if status.startswith('4') or status.startswith('5'):
                      error_by_minute[minute] += 1
      
      # Calcular tasas
      rates = []
      for minute in total_by_minute:
          total = total_by_minute[minute]
          errors = error_by_minute.get(minute, 0)
          if total > 0:
              rate = errors / total * 100
              rates.append((minute, rate))
      
      # Ordenar descendente por tasa
      rates.sort(key=lambda x: x[1], reverse=True)
      
      # Reportar top 5
      print("Top 5 minutos con mayor tasa de error:")
      for minute, rate in rates[:5]:
          print(f"{minute}: {rate:.2f}%")
  
  if __name__ == '__main__':
      main()

• Diseño de sistemasDiseña un pipeline de CI/CD con despliegues a producción seguros y graduales.
  Lo que cubre una buena respuesta

  • Integración continua con pruebas unitarias y análisis estático
  • Build y publicación de imágenes Docker en registro
  • Despliegue gradual: canary, blue/green, rolling update
  • Feature flags y kill switches
  • Rollback automático si métricas empeoran

  Ver respuesta de ejemplo

  El pipeline de CI/CD seguro y gradual comienza con el commit en el repositorio, que dispara una fase de integración: compilación, pruebas unitarias, linting y análisis de seguridad (SAST). Si todo pasa, se construye una imagen Docker y se etiqueta con el hash del commit, luego se sube a un registro de imágenes. Para el despliegue, se utiliza un enfoque gradual: primero se despliega en un entorno de staging donde se ejecutan pruebas de integración y de carga. Luego en producción se realiza un rollout con actualizaciones graduales (rolling update) o un despliegue canary (ej. 5% de tráfico). Las feature flags permiten activar/desactivar funcionalidades sin desplegar. Se monitorean métricas de error, latencia y logs; si las métricas superan un umbral, se ejecuta un rollback automático al despliegue anterior. Para mayor seguridad, se usan blue/green deployments (dos entornos completos) y se exige aprobación manual antes del 100% de tráfico. La clave es tener un buen observabilidad y tiempos de recuperación rápidos. Un error común es descuidar las pruebas de rendimiento en staging y que solo se detecten en producción.

• Diseño de sistemasDiseña la monitorización y las alertas para un servicio multirregión.
  Lo que cubre una buena respuesta

  • Métricas clave: latencia (p50/p99), errores, tráfico, saturación (USE)
  • Dashboards por región y agregados globales
  • Alertas multi-ventana: nivel crítico, advertencia, informativo
  • Health checks sintéticos desde múltiples puntos
  • Escalamiento automático basado en demanda regional

  Ver respuesta de ejemplo

  Para un servicio multirregión, la monitorización debe ser holística: coleccionar métricas de cada región (CPU, memoria, latencia de peticiones, tasas de error) usando agentes o exportadores (Prometheus Node Exporter, cAdvisor). También se despliegan health checks sintéticos desde varias ubicaciones geográficas que ejecutan peticiones periódicas y miden la disponibilidad real. Los dashboards se organizan por región y a nivel global, destacando percentiles de latencia (p50, p99) y tasas de error. Las alertas se configuran con lógica multi-ventana: por ejemplo, si el p99 supera 500ms durante 5 minutos en más del 10% de las réplicas, se dispara una alerta crítica. Para detectar degradaciones parciales, se alerta cuando una región muestra diferencias significativas respecto a la media global. También se monitorea la saturación de recursos (USE method) y el balance de tráfico entre regiones. Las alertas deben tener niveles (info, warning, critical) y canales de notificación (PagerDuty para críticas, Slack para warnings). Un error típico es poner alertas demasiado sensibles que generan ruido o no escalar adecuadamente la carga entre regiones.

• ConductualExplícame un incidente que lideraste y las acciones del postmortem.
  Lo que cubre una buena respuesta

  • Contexto del incidente: alcance, duración, impacto
  • Detección y respuesta inicial
  • Investigación de causa raíz
  • Mitigación y resolución
  • Postmortem con acciones correctivas y preventivas

  Ver respuesta de ejemplo

  Lideré un incidente donde un cambio en la configuración de un balanceador de carga causó que el tráfico se enrutara a una región con capacidad insuficiente, degradando la latencia en un 300% durante 45 minutos. Al detectar el aumento de alertas de latencia, formé un equipo de respuesta en un canal dedicado. Priorizamos restaurar el servicio: primero revertimos el cambio de configuración, lo que normalizó la latencia en 10 minutos. Luego investigamos la causa raíz: el cambio fue aprobado sin revisión y no tenía pruebas en staging. Documentamos todo en un postmortem que incluía la cronología, el impacto (pérdida de ingresos estimada en $10k) y las acciones acordadas: implementar un proceso de aprobación de cambios con revisión por pares, añadir alertas de tráfico por región y crear pruebas de integración para la configuración del balanceador. Asigné propietarios y fechas límite para cada ítem. Posteriormente hicimos una reunión sin culpa para compartir lecciones. El error común es no tener un runbook claro para revertir cambios rápidamente; ahora lo tenemos.

• Conductual¿Cómo equilibras el trabajo de fiabilidad con las solicitudes de funcionalidades?
  Lo que cubre una buena respuesta

  • SLA, SLO, SLI como marco de priorización
  • Presupuesto de error para features
  • Trabajo compartido en sprints: fiabilidad vs funcionalidades
  • Automatización y toil reduction para liberar tiempo
  • Comunicación con producto sobre riesgos técnicos

  Ver respuesta de ejemplo

  Equilibrar fiabilidad con nuevas funcionalidades requiere un acuerdo basado en SLOs (Service Level Objectives). Defino SLIs (latencia, disponibilidad) y un presupuesto de error: si estamos cerca de violar el SLO, priorizamos trabajo de fiabilidad (error budgets). En la planificación de sprints, asigno un porcentaje fijo (ej. 20%) a tareas de mantenimiento y reducción de toil, documentando el beneficio en términos de fiabilidad. Automatizo procesos repetitivos (despliegues, monitorización) para liberar tiempo del equipo. Cuando llegan solicitudes de funcionalidades, evalúo el impacto en la fiabilidad existente y negocio con producto un trade-off: por ejemplo, aceptar una degradación temporal del SLO a cambio de una feature crítica. También implemento feature flags para desactivar funcionalidades si riesgos la estabilidad. El error común es priorizar siempre las funcionalidades y acumular deuda técnica hasta que ocurre un incidente grave. Por eso es clave tener métricas visibles para todos y un proceso de postmortem que justifique inversiones en fiabilidad.

Qué evalúan los entrevistadores

Cómo prepararte

• Depura desde primeros principios: los entrevistadores quieren un enfoque sistemático y por capas.
• Enmarca tus respuestas en torno a SLOs, presupuestos de error y postmortems sin culpas.
• Automatiza todo en tus respuestas; los pasos manuales se leen como señales de alarma.

Preguntas frecuentes