diciembre 21, 2025
15 min de lectura

Preguntas para Entrevistas de Ingeniero Senior de Confiabilidad del Sitio: Guía Completa

interview
career-advice
job-search
Preguntas para Entrevistas de Ingeniero Senior de Confiabilidad del Sitio: Guía Completa
MB

Milad Bonakdar

Autor

Domina los conceptos avanzados de SRE con preguntas de entrevista exhaustivas que cubren la planificación de la capacidad, la ingeniería del caos, los sistemas distribuidos, el diseño de SLO, el liderazgo de incidentes y las prácticas organizativas de SRE para puestos senior.


Introducción

Se espera que los ingenieros sénior de Site Reliability (SRE) diseñen sistemas fiables a escala, lideren las respuestas a incidentes, impulsen la cultura SRE y tomen decisiones estratégicas sobre las inversiones en fiabilidad. Este rol exige una profunda experiencia técnica, habilidades de liderazgo y la capacidad de equilibrar la fiabilidad con la velocidad del negocio.

Esta guía exhaustiva cubre las preguntas esenciales de la entrevista para los SRE sénior, centrándose en conceptos avanzados, diseño del sistema e impacto organizativo. Cada pregunta incluye explicaciones detalladas y ejemplos prácticos.


Diseño Avanzado de SLO

1. ¿Cómo diseña SLI y SLO para un nuevo servicio con datos limitados?

Respuesta: Diseñar SLO para nuevos servicios requiere equilibrar la ambición con la viabilidad:

Enfoque:

1. Comience con la asignación del recorrido del usuario:

# Identificar recorridos críticos del usuario
user_journeys = {
    'search_product': {
        'steps': ['search_query', 'results_display', 'product_click'],
        'criticality': 'high',
        'expected_latency': '< 500ms'
    },
    'checkout': {
        'steps': ['add_to_cart', 'payment', 'confirmation'],
        'criticality': 'critical',
        'expected_latency': '< 2s'
    },
    'browse_recommendations': {
        'steps': ['load_page', 'fetch_recommendations'],
        'criticality': 'medium',
        'expected_latency': '< 1s'
    }
}

2. Defina los SLI basados en la experiencia del usuario:

# Especificación SLI
slis:
  availability:
    description: "Porcentaje de solicitudes exitosas"
    measurement: "count(http_status < 500) / count(http_requests)"
    
  latency:
    description: "Latencia de solicitud del percentil 95"
    measurement: "histogram_quantile(0.95, http_request_duration_seconds)"
    
  correctness:
    description: "Porcentaje de solicitudes que devuelven datos correctos"
    measurement: "count(validation_passed) / count(requests)"

3. Establezca SLO iniciales de forma conservadora:

def calculate_initial_slo(service_type, criticality):
    """
    Calcular el SLO inicial basado en las características del servicio
    """
    base_slos = {
        'critical': {
            'availability': 0.999,  # 99.9%
            'latency_p95': 1.0,     # 1 segundo
            'latency_p99': 2.0      # 2 segundos
        },
        'high': {
            'availability': 0.995,  # 99.5%
            'latency_p95': 2.0,
            'latency_p99': 5.0
        },
        'medium': {
            'availability': 0.99,   # 99%
            'latency_p95': 5.0,
            'latency_p99': 10.0
        }
    }
    
    return base_slos.get(criticality, base_slos['medium'])

# Ejemplo
checkout_slo = calculate_initial_slo('payment', 'critical')
print(f"Checkout SLO: {checkout_slo}")

4. Planifique la iteración:

  • Comience con una ventana de medición de 4 semanas
  • Revise el rendimiento de SLO semanalmente
  • Ajuste según el rendimiento real y los comentarios de los usuarios
  • Ajuste los SLO a medida que el sistema madura

5. Documente los supuestos:

## Supuestos de SLO (inicial)

### Disponibilidad: 99.9%
- Supuestos: Fiabilidad estándar de la infraestructura en la nube
- Presupuesto de error: 43 minutos/mes
- Revisión: Después de 3 meses de datos

### Latencia (p95): < 1s
- Supuestos: Consultas de base de datos < 100ms
- Supuestos: Sin cálculos complejos
- Revisión: Si cambian los patrones de consulta

### Dependencias
- Disponibilidad de la API externa: 99.95%
- Disponibilidad de la base de datos: 99.99%

Rareza: Común Dificultad: Difícil


2. ¿Cómo maneja los SLO en conflicto entre diferentes segmentos de usuarios?

Respuesta: Diferentes segmentos de usuarios a menudo tienen diferentes necesidades de fiabilidad:

Estrategia: SLO de niveles múltiples

class SLOTier:
    def __init__(self, name, availability, latency_p95, latency_p99):
        self.name = name
        self.availability = availability
        self.latency_p95 = latency_p95
        self.latency_p99 = latency_p99
        self.error_budget = 1 - availability

# Definir niveles
tiers = {
    'premium': SLOTier(
        name='Premium',
        availability=0.9999,  # 99.99% - 4.3 min/mes
        latency_p95=0.5,
        latency_p99=1.0
    ),
    'standard': SLOTier(
        name='Standard',
        availability=0.999,   # 99.9% - 43 min/mes
        latency_p95=1.0,
        latency_p99=2.0
    ),
    'free': SLOTier(
        name='Free',
        availability=0.99,    # 99% - 7.2 horas/mes
        latency_p95=2.0,
        latency_p99=5.0
    )
}

# Enrutar solicitudes basadas en el nivel
def get_user_tier(user_id):
    # Buscar el nivel de suscripción del usuario
    return user_subscription_tier(user_id)

def apply_slo_policy(user_id, request):
    tier = get_user_tier(user_id)
    slo = tiers[tier]
    
    # Aplicar políticas específicas del nivel
    request.timeout = slo.latency_p99
    request.priority = tier  # Para la priorización de la cola
    request.retry_budget = calculate_retry_budget(slo.error_budget)
    
    return request

Implementación con enrutamiento de tráfico:

# Ejemplo de Kubernetes: implementaciones separadas por nivel
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-premium
spec:
  replicas: 10
  template:
    spec:
      containers:
      - name: api
        resources:
          requests:
            cpu: "2"
            memory: "4Gi"
          limits:
            cpu: "4"
            memory: "8Gi"
      priorityClassName: high-priority
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-standard
spec:
  replicas: 5
  template:
    spec:
      containers:
      - name: api
        resources:
          requests:
            cpu: "1"
            memory: "2Gi"

Monitoreo por nivel:

# Disponibilidad por nivel
sum(rate(http_requests_total{status!~"5.."}[5m])) by (tier)
/
sum(rate(http_requests_total[5m])) by (tier)

# Latencia por nivel
histogram_quantile(0.95,
  rate(http_request_duration_seconds_bucket[5m])
) by (tier)

Rareza: Poco común Dificultad: Difícil


Planificación de la Capacidad

3. Describa su proceso de planificación de la capacidad para un servicio de rápido crecimiento.

Respuesta: La planificación de la capacidad garantiza que los recursos satisfagan la demanda al tiempo que optimiza los costos:

Marco de Planificación de la Capacidad:

Loading diagram...

1. Medir la línea de base:

import pandas as pd
import numpy as np
from sklearn.linear_model import LinearRegression

class CapacityPlanner:
    def __init__(self, metrics_data):
        self.data = pd.DataFrame(metrics_data)
    
    def analyze_trends(self, metric_name, days=30):
        """Analizar las tendencias históricas"""
        metric_data = self.data[metric_name].tail(days * 24)  # Datos por hora
        
        # Calcular la tasa de crecimiento
        start_value = metric_data.iloc[0]
        end_value = metric_data.iloc[-1]
        growth_rate = ((end_value - start_value) / start_value) * 100
        
        # Identificar el uso máximo
        peak_value = metric_data.max()
        peak_time = metric_data.idxmax()
        
        # Calcular los percentiles
        p50 = metric_data.quantile(0.50)
        p95 = metric_data.quantile(0.95)
        p99 = metric_data.quantile(0.99)
        
        return {
            'growth_rate': growth_rate,
            'peak_value': peak_value,
            'peak_time': peak_time,
            'p50': p50,
            'p95': p95,
            'p99': p99
        }
    
    def forecast_capacity(self, metric_name, months_ahead=3):
        """Pronosticar las necesidades futuras de capacidad"""
        # Preparar los datos
        df = self.data[[metric_name]].reset_index()
        df['days'] = (df.index / 24).astype(int)  # Convertir horas a días
        
        # Entrenar el modelo
        X = df[['days']].values
        y = df[metric_name].values
        
        model = LinearRegression()
        model.fit(X, y)
        
        # Pronosticar
        future_days = np.array([[df['days'].max() + (30 * months_ahead)]])
        forecast = model.predict(future_days)[0]
        
        # Añadir margen de seguridad (20%)
        forecast_with_margin = forecast * 1.2
        
        return {
            'forecast': forecast,
            'with_margin': forecast_with_margin,
            'current': y[-1],
            'growth_factor': forecast / y[-1]
        }
    
    def calculate_resource_needs(self, requests_per_second, 
                                 requests_per_instance=100,
                                 headroom=0.3):
        """Calcular las instancias requeridas"""
        # Capacidad base
        base_instances = np.ceil(requests_per_second / requests_per_instance)
        
        # Añadir margen de maniobra para picos y mantenimiento
        total_instances = np.ceil(base_instances * (1 + headroom))
        
        return {
            'base_instances': int(base_instances),
            'total_instances': int(total_instances),
            'headroom_instances': int(total_instances - base_instances)
        }

# Ejemplo de uso
metrics = {
    'requests_per_second': [100, 105, 110, 115, 120, ...],  # Datos históricos
    'cpu_usage': [45, 48, 50, 52, 55, ...],
    'memory_usage': [60, 62, 65, 67, 70, ...]
}

planner = CapacityPlanner(metrics)

# Analizar las tendencias
trends = planner.analyze_trends('requests_per_second', days=30)
print(f"Tasa de crecimiento: {trends['growth_rate']:.2f}%")
print(f"RPS máximo: {trends['peak_value']}")

# Pronosticar la capacidad
forecast = planner.forecast_capacity('requests_per_second', months_ahead=3)
print(f"RPS pronosticado en 3 meses: {forecast['forecast']:.0f}")
print(f"Con margen de seguridad: {forecast['with_margin']:.0f}")

# Calcular las necesidades de recursos
resources = planner.calculate_resource_needs(
    requests_per_second=forecast['with_margin'],
    requests_per_instance=100,
    headroom=0.3
)
print(f"Instancias requeridas: {resources['total_instances']}")

2. Considere los impulsores del crecimiento:

  • Tasa de crecimiento de usuarios
  • Lanzamiento de características
  • Patrones estacionales
  • Campañas de marketing
  • Expansión geográfica

3. Planifique el margen de maniobra:

  • N+1: Sobrevivir a una falla de instancia
  • N+2: Sobrevivir a dos fallas o una interrupción de zona
  • Picos de tráfico: 2-3 veces la capacidad normal
  • Ventanas de mantenimiento: 20-30% de sobrecarga

4. Optimización de costos:

def optimize_instance_mix(workload_profile):
    """
    Optimizar los tipos de instancia para el costo
    """
    # Mezcla de tipos de instancia
    instance_types = {
        'on_demand': {
            'cost_per_hour': 0.10,
            'reliability': 1.0,
            'percentage': 0.3  # 30% bajo demanda para la línea de base
        },
        'spot': {
            'cost_per_hour': 0.03,
            'reliability': 0.95,
            'percentage': 0.5  # 50% spot para ahorrar costos
        },
        'reserved': {
            'cost_per_hour': 0.06,
            'reliability': 1.0,
            'percentage': 0.2  # 20% reservado para carga predecible
        }
    }
    
    total_instances = workload_profile['total_instances']
    
    allocation = {}
    for instance_type, config in instance_types.items():
        count = int(total_instances * config['percentage'])
        allocation[instance_type] = {
            'count': count,
            'monthly_cost': count * config['cost_per_hour'] * 730
        }
    
    return allocation

Rareza: Muy común Dificultad: Difícil


Ingeniería del Caos

4. ¿Cómo implementa la ingeniería del caos en producción?

Respuesta: La ingeniería del caos prueba de forma proactiva la resistencia del sistema inyectando fallas:

Principios de la Ingeniería del Caos:

  1. Construir hipótesis en torno al estado estable
  2. Variar los eventos del mundo real
  3. Ejecutar experimentos en producción
  4. Automatizar experimentos
  5. Minimizar el radio de explosión

Implementación:

# Marco de experimento de caos
from dataclasses import dataclass
from enum import Enum
import random
import time

class ExperimentStatus(Enum):
    PLANNED = "planned"
    RUNNING = "running"
    COMPLETED = "completed"
    ABORTED = "aborted"

@dataclass
class ChaosExperiment:
    name: str
    hypothesis: str
    blast_radius: float  # Porcentaje de tráfico afectado
    duration_seconds: int
    rollback_criteria: dict
    
    def __post_init__(self):
        self.status = ExperimentStatus.PLANNED
        self.metrics_before = {}
        self.metrics_during = {}
        self.metrics_after = {}

class ChaosRunner:
    def __init__(self, monitoring_client):
        self.monitoring = monitoring_client
        self.experiments = []
    
    def run_experiment(self, experiment: ChaosExperiment):
        """Ejecutar experimento de caos con comprobaciones de seguridad"""
        print(f"Comenzando el experimento: {experiment.name}")
        
        # 1. Medir la línea de base
        experiment.metrics_before = self.measure_metrics()
        print(f"Métricas de línea de base: {experiment.metrics_before}")
        
        # 2. Verificar que el sistema esté sano
        if not self.is_system_healthy(experiment.metrics_before):
            print("Sistema no sano, abortando el experimento")
            return False
        
        # 3. Inyectar falla
        experiment.status = ExperimentStatus.RUNNING
        failure_injection = self.inject_failure(experiment)
        
        try:
            # 4. Monitorear durante el experimento
            start_time = time.time()
            while time.time() - start_time < experiment.duration_seconds:
                experiment.metrics_during = self.measure_metrics()
                
                # Comprobar los criterios de reversión
                if self.should_rollback(experiment):
                    print("Criterios de reversión cumplidos, deteniendo el experimento")
                    self.rollback(failure_injection)
                    experiment.status = ExperimentStatus.ABORTED
                    return False
                
                time.sleep(10)  # Comprobar cada 10 segundos
            
            # 5. Revertir la inyección de falla
            self.rollback(failure_injection)
            
            # 6. Medir la recuperación
            time.sleep(60)  # Esperar a que el sistema se estabilice
            experiment.metrics_after = self.measure_metrics()
            
            # 7. Analizar los resultados
            experiment.status = ExperimentStatus.COMPLETED
            return self.analyze_results(experiment)
            
        except Exception as e:
            print(f"Experimento fallido: {e}")
            self.rollback(failure_injection)
            experiment.status = ExperimentStatus.ABORTED
            return False
    
    def inject_failure(self, experiment):
        """Inyectar un tipo de falla específico"""
        # La implementación depende del tipo de falla
        pass
    
    def measure_metrics(self):
        """Medir las métricas clave del sistema"""
        return {
            'error_rate': self.monitoring.get_error_rate(),
            'latency_p95': self.monitoring.get_latency_p95(),
            'requests_per_second': self.monitoring.get_rps(),
            'availability': self.monitoring.get_availability()
        }
    
    def is_system_healthy(self, metrics):
        """Comprobar si el sistema cumple con los SLO"""
        return (
            metrics['error_rate'] < 0.01 and  # < 1% de errores
            metrics['latency_p95'] < 1.0 and  # < 1s de latencia
            metrics['availability'] > 0.999   # > 99.9% disponible
        )
    
    def should_rollback(self, experiment):
        """Comprobar si el experimento debe ser abortado"""
        current = experiment.metrics_during
        criteria = experiment.rollback_criteria
        
        return (
            current['error_rate'] > criteria.get('max_error_rate', 0.05) or
            current['latency_p95'] > criteria.get('max_latency', 5.0) or
            current['availability'] < criteria.get('min_availability', 0.99)
        )
    
    def rollback(self, failure_injection):
        """Eliminar la inyección de falla"""
        print("Revirtiendo la inyección de falla")
        # La implementación depende del tipo de falla
    
    def analyze_results(self, experiment):
        """Analizar los resultados del experimento"""
        before = experiment.metrics_before
        during = experiment.metrics_during
        after = experiment.metrics_after
        
        print(f"\nResultados del experimento: {experiment.name}")
        print(f"Hipótesis: {experiment.hypothesis}")
        print(f"\nMétricas:")
        print(f"  Antes: {before}")
        print(f"  Durante: {during}")
        print(f"  Después: {after}")
        
        # Determinar si la hipótesis fue validada
        hypothesis_validated = (
            during['availability'] >= experiment.rollback_criteria['min_availability']
        )
        
        return hypothesis_validated

# Ejemplo de experimento
experiment = ChaosExperiment(
    name="Prueba de conmutación por error de la base de datos",
    hypothesis="El sistema permanece disponible durante la conmutación por error de la base de datos",
    blast_radius=0.1,  # 10% del tráfico
    duration_seconds=300,  # 5 minutos
    rollback_criteria={
        'max_error_rate': 0.05,
        'max_latency': 5.0,
        'min_availability': 0.99
    }
)

Experimentos comunes de caos:

1. Latencia de la red:

# Usando tc (control de tráfico) para agregar latencia
tc qdisc add dev eth0 root netem delay 100ms 20ms

# Revertir
tc qdisc del dev eth0 root

2. Falla de pod (Kubernetes):

# Matar pods aleatorios
kubectl delete pod -l app=myapp --random=1

# Usando Chaos Mesh
kubectl apply -f - <<EOF
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-failure
spec:
  action: pod-failure
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: myapp
  duration: "30s"
EOF

3. Agotamiento de recursos:

# Estrés de CPU
stress-ng --cpu 4 --timeout 60s

# Estrés de memoria
stress-ng --vm 2 --vm-bytes 2G --timeout 60s

Rareza: Común Dificultad: Difícil


Liderazgo de Incidentes

5. ¿Cómo lidera un incidente de alta gravedad desde la detección hasta el post mortem?

Respuesta: Los SRE sénior a menudo sirven como comandantes de incidentes para interrupciones críticas:

Estructura de comando de incidentes:

Loading diagram...

Responsabilidades del comandante del incidente:

1. Respuesta inicial (0-5 minutos):

## Lista de Verificación del Comandante del Incidente

### Acciones Inmediatas
- [ ] Reconocer el incidente
- [ ] Evaluar la gravedad (SEV-1, SEV-2, SEV-3)
- [ ] Crear un canal de incidentes (#incident-AAAA-MM-DD-NNN)
- [ ] Notificar a los equipos apropiados
- [ ] Designar roles:
  - [ ] Líder Técnico
  - [ ] Líder de Comunicaciones
  - [ ] Escriba (documentar la línea de tiempo)

### Evaluación de la Gravedad
**SEV-1 (Crítico):**
- Interrupción completa del servicio
- Pérdida de datos
- Brecha de seguridad
- > 50% de usuarios afectados

**SEV-2 (Alto):**
- Interrupción parcial
- Rendimiento degradado
- 10-50% de usuarios afectados

**SEV-3 (Medio):**
- Degradación menor
- < 10% de usuarios afectados
- Solución alternativa disponible

2. Fase de investigación:

class IncidentCommander:
    def __init__(self, incident_id):
        self.incident_id = incident_id
        self.timeline = []
        self.status_updates = []
        self.action_items = []
    
    def coordinate_investigation(self):
        """Coordinar la investigación técnica"""
        # Pistas de investigación paralelas
        tracks = {
            'recent_changes': self.check_recent_deployments(),
            'infrastructure': self.check_infrastructure_health(),
            'dependencies': self.check_external_dependencies(),
            'metrics': self.analyze_metrics_anomalies()
        }
        
        return tracks
    
    def make_decision(self, options, deadline_minutes=5):
        """Tomar una decisión con límite de tiempo"""
        print(f"Se necesita una decisión en {deadline_minutes} minutos")
        print(f"Opciones: {options}")
        
        # Recopilar información de los líderes técnicos
        # Tomar una decisión basada en:
        # - Impacto en el usuario
        # - Riesgo de cada opción
        # - Tiempo para implementar
        # - Reversibilidad
        
        return selected_option
    
    def communicate_status(self, interval_minutes=15):
        """Actualizaciones de estado regulares"""
        update = {
            'timestamp': datetime.now(),
            'status': self.get_current_status(),
            'impact': self.assess_user_impact(),
            'eta': self.estimate_resolution_time(),
            'next_update': datetime.now() + timedelta(minutes=interval_minutes)
        }
        
        # Enviar a las partes interesadas
        self.send_status_update(update)
        self.status_updates.append(update)
    
    def log_timeline_event(self, event, timestamp=None):
        """Documentar la línea de tiempo del incidente"""
        self.timeline.append({
            'timestamp': timestamp or datetime.now(),
            'event': event,
            'logged_by': self.get_current_user()
        })

3. Estrategias de mitigación:

def evaluate_mitigation_options():
    """Evaluar y priorizar las opciones de mitigación"""
    options = [
        {
            'action': 'Revertir la implementación',
            'time_to_implement': 5,  # minutos
            'risk': 'low',
            'effectiveness': 'high',
            'reversible': True
        },
        {
            'action': 'Escalar los recursos',
            'time_to_implement': 2,
            'risk': 'low',
            'effectiveness': 'medium',
            'reversible': True
        },
        {
            'action': 'Desactivar el indicador de característica',
            'time_to_implement': 1,
            'risk': 'low',
            'effectiveness': 'high',
            'reversible': True
        },
        {
            'action': 'Conmutación por error de la base de datos',
            'time_to_implement': 10,
            'risk': 'medium',
            'effectiveness': 'high',
            'reversible': False
        }
    ]
    
    # Ordenar por: bajo riesgo, alta eficacia, implementación rápida
    sorted_options = sorted(
        options,
        key=lambda x: (
            x['risk'] == 'low',
            x['effectiveness'] == 'high',
            -x['time_to_implement']
        ),
        reverse=True
    )
    
    return sorted_options

4. Post mortem (sin culpables):

# Post Mortem del Incidente: Interrupción de la API

**Fecha:** 2024-11-25
**Duración:** 45 minutos
**Gravedad:** SEV-1
**Comandante del Incidente:** Alice
**Líder Técnico:** Bob

## Resumen Ejecutivo
Interrupción completa de la API que afecta a todos los usuarios debido al agotamiento del grupo de conexiones de la base de datos.

## Impacto
- **Usuarios afectados:** 100% (todos los usuarios)
- **Duración:** 45 minutos
- **Impacto en los ingresos:** ~$50,000
- **Impacto en el SLO:** Consumió el 75% del presupuesto de error mensual

## Causa Raíz
Grupo de conexiones de la base de datos agotado debido a una fuga de conexión en una nueva característica implementada 2 horas antes del incidente.

## Línea de Tiempo
| Hora | Evento |
|------|-------|
| 14:00 | Implementación de v2.5.0 |
| 15:45 | Primeras alertas de aumento de la latencia |
| 15:50 | Interrupción completa de la API |
| 15:52 | Incidente declarado (SEV-1) |
| 15:55 | Identificada la base de datos como cuello de botella |
| 16:05 | Decisión de revertir la implementación |
| 16:15 | Reversión completada |
| 16:20 | Servicio recuperándose |
| 16:35 | Recuperación completa confirmada |

## Lo Que Salió Bien
- Detección rápida (5 minutos desde el primer síntoma)
- Estructura de comando de incidentes clara
- Decisión rápida de revertir
- Buena comunicación con las partes interesadas

## Lo Que Salió Mal
- Fuga de conexión no detectada en las pruebas
- Sin monitoreo del grupo de conexiones
- Implementación durante las horas pico

## Elementos de Acción
| Acción | Propietario | Fecha de Vencimiento | Estado |
|--------|-------|----------|--------|
| Agregar monitoreo del grupo de conexiones | Alice | 2024-12-01 | Abierto |
| Implementar la detección de fugas de conexión en las pruebas | Bob | 2024-12-05 | Abierto |
| Actualizar la política de implementación (evitar las horas pico) | Charlie | 2024-11-30 | Abierto |
| Agregar un interruptor de circuito para las conexiones de la base de datos | David | 2024-12-10 | Abierto |

## Lecciones Aprendidas
- Las brechas de monitoreo pueden ocultar problemas críticos
- El momento de la implementación importa
- Necesidad de mejores pruebas de integración para fugas de recursos

Rareza: Muy común Dificultad: Difícil


Fiabilidad de Sistemas Distribuidos

6. ¿Cómo garantiza la fiabilidad en una arquitectura de microservicios distribuidos?

Respuesta: Los sistemas distribuidos introducen desafíos únicos de fiabilidad:

Patrones clave:

1. Malla de Servicio para la Resiliencia:

# Ejemplo de Istio: Interrupción de circuito y reintentos
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api-service
spec:
  host: api-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        http2MaxRequests: 100
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
      minHealthPercent: 40
    loadBalancer:
      simple: LEAST_REQUEST
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-service
spec:
  hosts:
  - api-service
  http:
  - retries:
      attempts: 3
      perTryTimeout: 2s
      retryOn: 5xx,reset,connect-failure,refused-stream
    timeout: 10s
    route:
    - destination:
        host: api-service

2. Rastreo Distribuido:

from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

# Configurar el rastreo
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

# Instrumentar la biblioteca de solicitudes
RequestsInstrumentor().instrument()

# Usar en el código
tracer = trace.get_tracer(__name__)

def process_order(order_id):
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order.id", order_id)
        
        # Llamar al servicio de pago
        with tracer.start_as_current_span("call_payment_service"):
            payment_result = call_payment_service(order_id)
        
        # Llamar al servicio de inventario
        with tracer.start_as_current_span("call_inventory_service"):
            inventory_result = call_inventory_service(order_id)
        
        return combine_results(payment_result, inventory_result)

3. Patrón de Aislamiento:

import asyncio
from asyncio import Semaphore

class BulkheadExecutor:
    def __init__(self, max_concurrent=10):
        self.semaphore = Semaphore(
Newsletter subscription

Consejos de carrera semanales que realmente funcionan

Recibe las últimas ideas directamente en tu bandeja de entrada

Decorative doodle

Tu Próxima Entrevista Está a Solo un Currículum de Distancia

Crea un currículum profesional y optimizado en minutos. No se necesitan habilidades de diseño, solo resultados comprobados.

Crea mi currículum

Compartir esta publicación

Haz que tus 6 Segundos Cuenten

Los reclutadores escanean currículums durante un promedio de solo 6 a 7 segundos. Nuestras plantillas probadas están diseñadas para captar la atención al instante y mantenerlos leyendo.