Preguntas para Entrevistas de Ingeniero de Confiabilidad del Sitio (SRE) Junior: Guía Completa

Milad Bonakdar
Autor
Domina los fundamentos esenciales de SRE con preguntas integrales para entrevistas que cubren la monitorización, la respuesta a incidentes, los SLO, la automatización, la resolución de problemas de Linux y las prácticas de confiabilidad para los puestos de SRE junior.
Introducción
La Ingeniería de Fiabilidad del Sitio (SRE, por sus siglas en inglés) combina la ingeniería de software y la administración de sistemas para construir y operar sistemas fiables a gran escala. Como SRE junior, te centrarás en la monitorización, la respuesta a incidentes, la automatización y el aprendizaje de prácticas de fiabilidad que mantengan los servicios funcionando sin problemas.
Esta guía cubre preguntas esenciales para entrevistas de SRE junior, organizadas por temas para ayudarte a prepararte de manera efectiva. Cada pregunta incluye respuestas detalladas, ejemplos prácticos y escenarios prácticos.
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):



