diciembre 21, 2025
18 min de lectura

Preguntas de entrevista para Junior SRE con respuestas

interview
career-advice
job-search
entry-level
Preguntas de entrevista para Junior SRE con respuestas
Milad Bonakdar

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:

AspectoSREDevOps
EnfoqueFiabilidad y escalabilidadColaboración y automatización
MétricasSLIs, SLOs, presupuestos de errorFrecuencia de despliegue, tiempo de entrega
EnfoquePrescriptivo (prácticas específicas)Filosofía (movimiento cultural)
TedioExplícitamente limitado al 50%No definido específicamente

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
# Ejemplo de cálculo de SLI/SLO
def calcular_presupuesto_error(total_solicitudes, solicitudes_fallidas, objetivo_slo=0.999):
    """
    Calcula el consumo del presupuesto de error
    
    SLO: 99.9% de tasa de éxito
    Presupuesto de error: 0.1% de fallos permitidos
    """
    tasa_exito = (total_solicitudes - solicitudes_fallidas) / total_solicitudes
    tasa_error = solicitudes_fallidas / total_solicitudes
    
    # Presupuesto de error: cuánto del 0.1% permitido hemos usado
    errores_permitidos = total_solicitudes * (1 - objetivo_slo)
    presupuesto_consumido = (solicitudes_fallidas / errores_permitidos) * 100
    
    return {
        'tasa_exito': tasa_exito,
        'tasa_error': tasa_error,
        'objetivo_slo': objetivo_slo,
        'slo_cumplido': tasa_exito >= objetivo_slo,
        'presupuesto_error_consumido': presupuesto_consumido,
        'presupuesto_restante': max(0, 100 - presupuesto_consumido)
    }

# Ejemplo
resultado = calcular_presupuesto_error(
    total_solicitudes=1000000,
    solicitudes_fallidas=500,  # 0.05% de tasa de error
    objetivo_slo=0.999
)

print(f"Tasa de Éxito: {resultado['tasa_exito']:.4%}")
print(f"SLO Cumplido: {resultado['slo_cumplido']}")
print(f"Presupuesto de Error Consumido: {resultado['presupuesto_error_consumido']:.1f}%")

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:

# Ejemplo: Automatizar el reinicio del servicio
#!/bin/bash
# auto-restart-service.sh

SERVICE_NAME="myapp"
MAX_RETRIES=3
RETRY_DELAY=5

check_service() {
    systemctl is-active --quiet $SERVICE_NAME
    return $?
}

restart_service() {
    echo "$(date): Reiniciando $SERVICE_NAME"
    systemctl restart $SERVICE_NAME
    
    # Esperar a que el servicio se estabilice
    sleep $RETRY_DELAY
    
    if check_service; then
        echo "$(date): $SERVICE_NAME reiniciado correctamente"
        # Enviar notificación
        curl -X POST https://alerts.company.com/webhook \
          -d "{\"message\": \"$SERVICE_NAME auto-reiniciado\"}"
        return 0
    else
        return 1
    fi
}

# Lógica principal
if ! check_service; then
    echo "$(date): $SERVICE_NAME está inactivo"
    
    for i in $(seq 1 $MAX_RETRIES); do
        echo "Intento $i de $MAX_RETRIES"
        if restart_service; then
            exit 0
        fi
        sleep $RETRY_DELAY
    done
    
    # Todos los reintentos fallaron - escalar
    echo "$(date): Falló el reinicio de $SERVICE_NAME después de $MAX_RETRIES intentos"
    curl -X POST https://pagerduty.com/api/incidents \
      -d "{\"service\": \"$SERVICE_NAME\", \"severity\": \"critical\"}"
    exit 1
fi

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
Loading diagram...

Tres Pilares de la Observabilidad:

  1. Métricas: Números agregados (CPU, latencia)
  2. Registros: Eventos discretos
  3. Rastreos: Flujo de la solicitud a través del sistema

Ejemplo: Prometheus + Grafana + Loki

# Configuración de scraping de Prometheus
scrape_configs:
  - job_name: 'api-server'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'
    scrape_interval: 15s

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:

# Mal: Alerta sobre CPU alta
- alert: HighCPU
  expr: cpu_usage > 80
  
# Bien: Alerta sobre el impacto en el usuario
- alert: HighLatency
  expr: http_request_duration_seconds{quantile="0.95"} > 1
  for: 5m
  annotations:
    summary: "La latencia de la API es alta"
    description: "La latencia del percentil 95 es {{ $value }}s"

2. Incluir enlaces a runbooks:

- alert: DatabaseConnectionPoolExhausted
  expr: db_connection_pool_active / db_connection_pool_max > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "El pool de conexiones de la base de datos está casi agotado"
    runbook: "https://wiki.company.com/runbooks/db-connections"

3. Utilizar niveles de gravedad apropiados:

# Digno de una llamada de guardia (despierta a alguien)
- alert: ServiceDown
  expr: up{job="api"} == 0
  for: 1m
  labels:
    severity: critical
    
# Digno de un ticket (manejar durante las horas de trabajo)
- alert: DiskSpaceWarning
  expr: disk_free_percent < 20
  for: 30m
  labels:
    severity: warning

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:

Loading diagram...

1. Detección:

  • Se dispara una alerta o un usuario informa de un problema
  • Reconocer la alerta
  • Crear un canal de incidentes

2. Triaje:

# Lista de verificación de evaluación rápida
- ¿Cuál es el impacto en el usuario?
- ¿Cuántos usuarios afectados?
- ¿Qué servicios se ven afectados?
- ¿Está empeorando?

3. Mitigación:

# Estrategias comunes de mitigación
- Revertir el despliegue reciente
- Escalar los recursos
- Desactivar la característica problemática
- Failover al sistema de respaldo
- Limitar la tasa de tráfico

4. Resolución:

  • Arreglar la causa raíz
  • Verificar que las métricas vuelvan a la normalidad
  • Monitorizar la recurrencia

5. Postmortem (Sin culpables):

# Plantilla de Postmortem de Incidentes

## Resumen
Breve descripción de lo que sucedió

## Impacto
- Duración: 2024-11-25 10:00 - 10:45 UTC (45 minutos)
- Usuarios afectados: ~10,000 (5% del total)
- Servicios impactados: API, Web Frontend

## Causa Raíz
El pool de conexiones de la base de datos se agotó debido a consultas lentas

## Cronología
- 10:00: Se disparó la alerta por alta latencia de la API
- 10:05: El ingeniero de guardia reconoció
- 10:10: Se identificó la base de datos como cuello de botella
- 10:15: Se aumentó el tamaño del pool de conexiones (mitigación)
- 10:30: Se identificaron y eliminaron las consultas lentas
- 10:45: El servicio se recuperó por completo

## Resolución
- Inmediata: Se aumentó el pool de conexiones de 100 a 200
- A corto plazo: Se añadió un tiempo de espera de la consulta (30s)
- A largo plazo: Optimizar las consultas lentas, añadir la monitorización de las consultas

## Elementos de Acción
- [ ] Añadir alerta para las consultas lentas (Responsable: Alice, Vencimiento: 2024-12-01)
- [ ] Implementar el tiempo de espera de la consulta en la aplicación (Responsable: Bob, Vencimiento: 2024-12-05)
- [ ] Revisar y optimizar las 10 consultas más lentas (Responsable: Charlie, Vencimiento: 2024-12-10)

## Lecciones Aprendidas
- La monitorización del pool de conexiones era insuficiente
- La degradación del rendimiento de las consultas pasó desapercibida

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:

# 1. Verificar el problema
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/health

# curl-format.txt:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#    time_pretransfer:  %{time_pretransfer}s\n
#       time_redirect:  %{time_redirect}s\n
#  time_starttransfer:  %{time_starttransfer}s\n
#                     ----------\n
#          time_total:  %{time_total}s\n

# 2. Comprobar las métricas de la aplicación
# - Tasa de solicitudes (¿pico repentino?)
# - Tasa de errores (¿errores que causan reintentos?)
# - Uso de recursos (CPU, memoria)

# 3. Comprobar las dependencias
# - Tiempo de consulta de la base de datos
# - Llamadas a la API externa
# - Tasa de aciertos de la caché

# 4. Comprobar la infraestructura
top  # Uso de la CPU
free -h  # Memoria
iostat  # E/S del disco
netstat -s  # Estadísticas de la red

# 5. Comprobar los registros en busca de errores
tail -f /var/log/app/error.log | grep -i "timeout\|slow\|error"

# 6. Perfilar la aplicación
# Ejemplo de Python
import cProfile
cProfile.run('mi_funcion()')

# 7. Comprobar la base de datos
# Registro de consultas lentas
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

# Consultas activas
SELECT pid, query, state, query_start 
FROM pg_stat_activity 
WHERE state = 'active';

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:

#!/usr/bin/env python3
"""
Comprobador de salud del servicio con capacidad de auto-reinicio
"""
import requests
import subprocess
import time
import sys
from datetime import datetime

class ServiceMonitor:
    def __init__(self, service_name, health_url, max_retries=3):
        self.service_name = service_name
        self.health_url = health_url
        self.max_retries = max_retries
    
    def check_health(self):
        """Comprobar si el servicio está sano"""
        try:
            response = requests.get(
                self.health_url,
                timeout=5
            )
            return response.status_code == 200
        except requests.exceptions.RequestException as e:
            print(f"{datetime.now()}: La comprobación de salud falló: {e}")
            return False
    
    def restart_service(self):
        """Reiniciar el servicio usando systemctl"""
        try:
            print(f"{datetime.now()}: Reiniciando {self.service_name}")
            subprocess.run(
                ['systemctl', 'restart', self.service_name],
                check=True,
                capture_output=True
            )
            time.sleep(10)  # Esperar a que el servicio se inicie
            return True
        except subprocess.CalledProcessError as e:
            print(f"{datetime.now()}: El reinicio falló: {e.stderr}")
            return False
    
    def send_alert(self, message, severity='warning'):
        """Enviar alerta al sistema de monitorización"""
        try:
            requests.post(
                'https://alerts.company.com/webhook',
                json={
                    'service': self.service_name,
                    'message': message,
                    'severity': severity,
                    'timestamp': datetime.now().isoformat()
                },
                timeout=5
            )
        except Exception as e:
            print(f"Falló el envío de la alerta: {e}")
    
    def monitor(self):
        """Bucle principal de monitorización"""
        if self.check_health():
            print(f"{datetime.now()}: {self.service_name} está sano")
            return 0
        
        print(f"{datetime.now()}: {self.service_name} no está sano")
        self.send_alert(f"{self.service_name} está inactivo", severity='warning')
        
        # Intentar reiniciar
        for attempt in range(1, self.max_retries + 1):
            print(f"Intento de reinicio {attempt}/{self.max_retries}")
            
            if self.restart_service() and self.check_health():
                print(f"{datetime.now()}: Servicio recuperado")
                self.send_alert(
                    f"{self.service_name} auto-recuperado después del reinicio",
                    severity='info'
                )
                return 0
            
            time.sleep(5)
        
        # Todos los reintentos fallaron
        print(f"{datetime.now()}: Falló la recuperación del servicio")
        self.send_alert(
            f"{self.service_name} falló la recuperación después de {self.max_retries} intentos",
            severity='critical'
        )
        return 1

if __name__ == '__main__':
    monitor = ServiceMonitor(
        service_name='myapp',
        health_url='http://localhost:8080/health'
    )
    sys.exit(monitor.monitor())

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:

# Runbook: Alta Latencia de la API

## Síntomas
- Latencia del percentil 95 de la API > 1 segundo
- Quejas de los usuarios sobre la lentitud en la carga de la página
- Alerta: "HighAPILatency" disparándose

## Gravedad
**Advertencia** - Degrada la experiencia del usuario pero el servicio es funcional

## Pasos de Investigación

### 1. Comprobar las métricas actuales
```bash
# Comprobar la distribución de la latencia
curl -s http://prometheus:9090/api/v1/query?query='histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))'

# Comprobar la tasa de solicitudes
curl -s http://prometheus:9090/api/v1/query?query='rate(http_requests_total[5m])'

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

# Conexiones de la base de datos
mysql -e "SHOW PROCESSLIST;"

# Latencia de Redis
redis-cli --latency

# APIs externas
curl -w "%{time_total}\n" -o /dev/null -s https://external-api.com/health

Pasos de Mitigación

Arreglos rápidos (< 5 minutos)

  1. Escalar las instancias de la aplicación
kubectl scale deployment api --replicas=10
  1. Aumentar el TTL de la caché temporalmente
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Si el problema persiste

  1. Revertir el despliegue reciente
kubectl rollout undo deployment/api
  1. Habilitar la limitación de velocidad
kubectl apply -f rate-limit-config.yaml

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


**Por qué los runbooks importan:**
- Respuesta a incidentes más rápida
- Procedimientos consistentes
- Compartir conocimientos
- Reducción del estrés durante los incidentes
- Herramienta de formación para los nuevos miembros del equipo

**Frecuencia:** Común  
**Dificultad:** Fácil

---

### 10. Explica el concepto de degradación elegante.

**Respuesta:**
La **degradación elegante** significa que un sistema continúa operando a una capacidad reducida cuando los componentes fallan, en lugar de fallar por completo.

**Estrategias:**

**1. Feature Flags:**
```python
# Deshabilitar características no críticas durante la alta carga
class FeatureFlags:
    def __init__(self):
        self.flags = {
            'recommendations': True,
            'analytics': True,
            'search_autocomplete': True
        }
    
    def is_enabled(self, feature):
        # Deshabilitar características no críticas si el presupuesto de error es bajo
        if self.error_budget_low():
            non_critical = ['analytics', 'search_autocomplete']
            if feature in non_critical:
                return False
        return self.flags.get(feature, False)
    
    def error_budget_low(self):
        # Comprobar si el presupuesto de error < 20%
        return get_error_budget() < 0.2

# Uso
flags = FeatureFlags()
if flags.is_enabled('recommendations'):
    show_recommendations()
else:
    # Degradación elegante - mostrar contenido estático
    show_popular_items()

2. Circuit Breaker:

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"  # Operación normal
    OPEN = "open"      # Fallando, rechazar solicitudes
    HALF_OPEN = "half_open"  # Probando la recuperación

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.failures = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
            else:
                # Devolver fallback en lugar de llamar al servicio que falla
                return self.fallback()
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            return self.fallback()
    
    def on_success(self):
        self.failures = 0
        self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN
    
    def fallback(self):
        # Devolver datos en caché o respuesta por defecto
        return {"status": "degraded", "data": []}

# Uso
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

3. Timeouts y Reintentos:

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry

def create_resilient_session():
    session = requests.Session()
    
    # Estrategia de reintento
    retry = Retry(
        total=3,
        backoff_factor=0.3,
        status_forcelist=[500, 502, 503, 504]
    )
    
    adapter = HTTPAdapter(max_retries=retry)
    session.mount('http://', adapter)
    session.mount('https://', adapter)
    
    return session

# Uso con timeout
session = create_resilient_session()
try:
    response = session.get('https://api.example.com/data', timeout=5)
except requests.exceptions.Timeout:
    # Degradación elegante - usar datos en caché
    response = get_cached_data()

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:

Loading diagram...

Diferencias clave:

CaracterísticaContenedoresMáquinas Virtuales
Tiempo de InicioSegundosMinutos
TamañoMBsGBs
Uso de RecursosLigeroPesado
AislamientoNivel de procesoNivel de hardware
SOComparte el SO anfitriónSO separado por VM

Conceptos básicos de Docker:

# Pull una imagen
docker pull nginx:latest

# Ejecutar un contenedor
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  nginx:latest

# Listar los contenedores en ejecución
docker ps

# Ver los registros
docker logs my-nginx

# Ejecutar un comando en el contenedor
docker exec -it my-nginx bash

# Detener el contenedor
docker stop my-nginx

# Eliminar el contenedor
docker rm my-nginx

Ejemplo de Dockerfile:

# Imagen base
FROM python:3.12-slim

# Establecer el directorio de trabajo
WORKDIR /app

# Copiar los requisitos
COPY requirements.txt .

# Instalar las dependencias
RUN pip install --no-cache-dir -r requirements.txt

# Copiar el código de la aplicación
COPY . .

# Exponer el puerto
EXPOSE 8000

# Comprobación de salud
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8000/health || exit 1

# Ejecutar la aplicación
CMD ["python", "app.py"]

Construir y Ejecutar:

# Construir la imagen
docker build -t myapp:1.0 .

# Ejecutar con variables de entorno
docker run -d \
  --name myapp \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://db:5432/mydb \
  -e LOG_LEVEL=info \
  myapp:1.0

# Ver el uso de recursos
docker stats myapp

Docker Compose (Multi-contenedor):

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://db:5432/mydb
    depends_on:
      - db
      - redis
    restart: unless-stopped
  
  db:
    image: postgres:14
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data
  
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Ejecutar con Docker Compose:

# Iniciar todos los servicios
docker compose up -d

# Ver los registros
docker compose logs -f web

# Escalar el servicio
docker compose up -d --scale web=3

# Detener todos los servicios
docker compose down

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:

Loading diagram...

Comandos básicos de Git:

# Clonar el repositorio
git clone https://github.com/company/repo.git
cd repo

# Crear una rama de características
git checkout -b feature/add-monitoring

# Hacer cambios y commit
git add .
git commit -m "Añadir monitorización de Prometheus"

# Push al remoto
git push origin feature/add-monitoring

# Actualizar desde main
git checkout main
git pull origin main
git checkout feature/add-monitoring
git rebase main

# Fusionar la característica (después de la aprobación del PR)
git checkout main
git merge feature/add-monitoring
git push origin main

Estrategia de Ramificación:

1. Gitflow:

  • main: Código listo para producción
  • develop: Rama de integración
  • feature/*: Nuevas características
  • release/*: Preparación de la versión
  • hotfix/*: Correcciones de emergencia

2. Desarrollo Basado en Trunk:

# Ramas de características de corta duración
git checkout -b feature/arreglo-rapido
# Trabajar durante < 1 día
git push origin feature/arreglo-rapido
# Fusionar a main inmediatamente después de la revisión

Flujo de trabajo del despliegue:

1. Pipeline CI/CD (GitHub Actions):

name: Desplegar a Producción

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Ejecutar pruebas
        run: |
          npm install
          npm test
      
      - name: Ejecutar linting
        run: npm run lint
  
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Construir la imagen de Docker
        run: |
          docker build -t myapp:${{

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.

Newsletter subscription

Consejos de carrera semanales que realmente funcionan

Recibe las últimas ideas directamente en tu bandeja de entrada

Destácate ante los Reclutadores y Consigue el Trabajo de Tus Sueños

Únete a miles que transformaron sus carreras con currículums impulsados por IA que pasan el ATS e impresionan a los gerentes de contratación.

Comienza a crear ahora

Compartir esta publicación

Duplica tus Llamadas para Entrevistas

Los candidatos que adaptan sus currículums a la descripción del trabajo obtienen 2.5 veces más entrevistas. Usa nuestra IA para personalizar tu CV automáticamente para cada solicitud al instante.