Preguntas de entrevista para Junior SRE con respuestas

Milad Bonakdar
Autor
Prepárate para entrevistas de SRE junior con preguntas prácticas sobre SLO, presupuestos de error, alertas, incidentes, Linux, automatización y Kubernetes.
En qué se fija una entrevista de Junior SRE
Las entrevistas de SRE junior suelen evaluar si puedes razonar desde el impacto en usuarios hasta las señales del sistema: SLO, presupuestos de error, alertas, incidentes, señales de Linux, automatización, contenedores y operaciones básicas de Kubernetes. No necesitas sonar como una persona senior. Necesitas mostrar que investigas con orden, comunicas con claridad durante incidentes y automatizas trabajo operativo repetitivo sin ocultar riesgos.
Usa estas preguntas para practicar respuestas breves y conecta cada respuesta con un ejemplo real de proyectos, laboratorios, prácticas o seguimiento de guardias.
Fundamentos de SRE
1. ¿Qué es la Ingeniería de Fiabilidad del Sitio y en qué se diferencia de DevOps?
Respuesta: SRE es el enfoque de Google para ejecutar sistemas de producción de manera fiable a escala.
Principios clave:
- Tratar las operaciones como un problema de software
- Máximo 50% del tiempo en trabajo operativo (tedio)
- Presupuestos de error para equilibrar fiabilidad y velocidad
- Autopsias sin culpables
- Despliegues graduales y reversiones automatizadas
SRE vs DevOps:
SRE implementa los principios de DevOps con prácticas y métricas específicas.
Frecuencia: Muy común
Dificultad: Fácil
2. Explica SLIs, SLOs y presupuestos de error.
Respuesta: Estos son conceptos centrales de SRE para medir y gestionar la fiabilidad:
SLI (Indicador de Nivel de Servicio):
- Medida cuantitativa del nivel de servicio
- Ejemplos: Latencia, disponibilidad, tasa de error
SLO (Objetivo de Nivel de Servicio):
- Valor objetivo para un SLI
- Ejemplo: "El 99.9% de las solicitudes tienen éxito"
Presupuesto de Error:
- Tasa de error permitida (100% - SLO)
- Utilizado para equilibrar la fiabilidad frente a la velocidad de las características
Frecuencia: Muy común
Dificultad: Media
3. ¿Qué es el tedio y cómo lo reduces?
Respuesta: El tedio es el trabajo operativo repetitivo y manual que:
- Es manual (requiere acción humana)
- Es repetitivo
- Puede ser automatizado
- No tiene valor duradero
- Crece linealmente con el crecimiento del servicio
Ejemplos de tedio:
- Reiniciar servicios manualmente
- Copiar archivos entre servidores
- Escalar recursos manualmente
- Respuestas repetitivas a tickets
Estrategias de reducción del tedio:
Objetivo de SRE: Mantener el tedio por debajo del 50% del tiempo, automatizar el resto.
Frecuencia: Muy común
Dificultad: Fácil-Media
Monitorización y Observabilidad
4. ¿Cuál es la diferencia entre monitorización y observabilidad?
Respuesta: Monitorización: Recopilación de métricas y alertas predefinidas
- Conocido-desconocido: Sabes qué vigilar
- Paneles, alertas, métricas
- Ejemplos: CPU, memoria, tasa de solicitudes
Observabilidad: Comprender el estado del sistema a partir de las salidas
- Desconocido-desconocido: Depurar problemas que no anticipaste
- Registros, métricas, rastreos combinados
- Puede responder preguntas arbitrarias
Tres Pilares de la Observabilidad:
- Métricas: Números agregados (CPU, latencia)
- Registros: Eventos discretos
- Rastreos: Flujo de la solicitud a través del sistema
Ejemplo: Prometheus + Grafana + Loki
Frecuencia: Común
Dificultad: Media
5. ¿Cómo configuras alertas efectivas?
Respuesta: Las buenas alertas son accionables, significativas y no causan fatiga.
Mejores prácticas para alertas:
1. Alerta sobre los síntomas, no sobre las causas:
2. Incluir enlaces a runbooks:
3. Utilizar niveles de gravedad apropiados:
4. Evitar la fatiga de alertas:
- Usar
for:duration para evitar el aleteo - Agrupar alertas relacionadas
- Establecer umbrales apropiados
- Revisar y ajustar regularmente
Frecuencia: Muy común
Dificultad: Media
Respuesta a Incidentes
6. Describe tu proceso de respuesta a incidentes.
Respuesta: Una respuesta a incidentes estructurada minimiza el impacto y el tiempo de recuperación:
Pasos de la respuesta a incidentes:
1. Detección:
- Se dispara una alerta o un usuario informa de un problema
- Reconocer la alerta
- Crear un canal de incidentes
2. Triaje:
3. Mitigación:
4. Resolución:
- Arreglar la causa raíz
- Verificar que las métricas vuelvan a la normalidad
- Monitorizar la recurrencia
5. Postmortem (Sin culpables):
Frecuencia: Muy común
Dificultad: Media
7. ¿Cómo resuelves un servicio que está experimentando una alta latencia?
Respuesta: Enfoque de depuración sistemático:
Causas comunes:
- Consultas lentas de la base de datos
- Tiempos de espera de la API externa
- Presión de memoria (pausas de GC)
- Problemas de red
- Agotamiento de recursos
- Rutas de código ineficientes
Frecuencia: Muy común
Dificultad: Media
Automatización y Scripting
8. Escribe un script para comprobar si un servicio está sano y reiniciarlo si es necesario.
Respuesta: Script de comprobación de estado y auto-remediación:
Frecuencia: Común
Dificultad: Media
Prácticas de Fiabilidad
9. ¿Qué es un runbook y por qué es importante?
Respuesta: Un runbook es un procedimiento documentado para manejar tareas operativas e incidentes.
Estructura del runbook:
2. Identificar el cuello de botella
- Comprobar el tiempo de consulta de la base de datos
- Comprobar las llamadas a la API externa
- Comprobar la tasa de aciertos de la caché
- Revisar los despliegues recientes
3. Comprobar las dependencias
Pasos de Mitigación
Arreglos rápidos (< 5 minutos)
- Escalar las instancias de la aplicación
- Aumentar el TTL de la caché temporalmente
Si el problema persiste
- Revertir el despliegue reciente
- Habilitar la limitación de velocidad
Resolución
- Arreglar la causa raíz (consulta lenta, código ineficiente)
- Desplegar la corrección
- Monitorizar durante 30 minutos
- Reducir la escala a la capacidad normal
Escalada
Si no se puede resolver en 30 minutos:
- Escalar a: @backend-team
- Canal de Slack: #incidents
- De guardia: Utilizar la política de escalada de PagerDuty
Relacionado
2. Circuit Breaker:
3. Timeouts y Reintentos:
Frecuencia: Común
Dificultad: Media
Conceptos Básicos de Contenedores
11. ¿Qué es Docker y en qué se diferencia de las máquinas virtuales?
Respuesta: Docker es una plataforma de contenedores que empaqueta las aplicaciones con sus dependencias.
Contenedores vs Máquinas Virtuales:
Diferencias clave:
Conceptos básicos de Docker:
Ejemplo de Dockerfile:
Construir y Ejecutar:
Docker Compose (Multi-contenedor):
Ejecutar con Docker Compose:
Mejores Prácticas:
- Usar imágenes base oficiales
- Minimizar el número de capas
- No ejecutar como root
- Usar .dockerignore
- Etiquetar las imágenes correctamente
- Escanear en busca de vulnerabilidades
Frecuencia: Muy común
Dificultad: Fácil-Media
Control de Versiones y Despliegue
12. Explica los flujos de trabajo de Git y cómo manejas los despliegues.
Respuesta: Git es esencial para el control de versiones y la automatización del despliegue.
Flujo de trabajo común de Git:
Comandos básicos de Git:
Estrategia de Ramificación:
1. Gitflow:
main: Código listo para produccióndevelop: Rama de integraciónfeature/*: Nuevas característicasrelease/*: Preparación de la versiónhotfix/*: Correcciones de emergencia
2. Desarrollo Basado en Trunk:
Flujo de trabajo del despliegue:
1. Pipeline CI/CD (GitHub Actions):
Conclusión
Prepara tu entrevista de SRE junior practicando SLO, alertas, respuesta a incidentes, troubleshooting en Linux y automatización segura. Una buena respuesta no enumera comandos sin contexto: empieza por el impacto en usuarios, revisa señales fiables, mitiga con bajo riesgo y deja aprendizaje documentado.


