diciembre 21, 2025
18 min de lectura

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

interview
career-advice
job-search
entry-level
Preguntas para Entrevistas de Ingeniero de Confiabilidad del Sitio (SRE) Junior: Guía Completa
MB

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:

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.9-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):

version: '3.8'

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@v3
      
      - 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@v3
      
      - name: Construir la imagen de Docker
        run: |
          docker build -t myapp:${{
Newsletter subscription

Consejos de carrera semanales que realmente funcionan

Recibe las últimas ideas directamente en tu bandeja de entrada

Decorative doodle

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.