Introducción a SLIs, SLOs y SLAs
En el mundo de DevOps y SRE (Site Reliability Engineering), garantizar una alta calidad de servicio es fundamental para el éxito empresarial. Los SLIs (Service Level Indicators), SLOs (Service Level Objectives) y SLAs (Service Level Agreements) son conceptos clave para medir y asegurar que nuestros sistemas cumplen con las expectativas de disponibilidad, rendimiento y fiabilidad.
En este artículo, exploraremos en detalle qué son los SLIs, SLOs y SLAs, cómo se relacionan entre sí, y ofreceremos guías prácticas para implementarlos eficazmente en tu organización.
Historia y Evolución de los Niveles de Servicio
Los conceptos de SLIs, SLOs y SLAs tienen su origen en la gestión de servicios de TI y el marco ITIL (IT Infrastructure Library). Inicialmente, los SLAs surgieron como contratos formales entre departamentos de TI y otras unidades de negocio, o entre proveedores y clientes.
La evolución de estos conceptos ha sido significativa:
| Década | Enfoque | Características |
|---|---|---|
| 1980s | Contratos de servicio básicos | Centrados principalmente en disponibilidad (“uptime”) |
| 1990s | ITIL y gestión de servicios | Formalización de SLAs como parte de la gestión de servicios |
| 2000s | Computación en la nube | SLAs comerciales para servicios cloud |
| 2010s | DevOps y SRE | Evolución hacia SLIs y SLOs como herramientas de ingeniería |
| 2020s | Observabilidad avanzada | Integración con plataformas de observabilidad y automatización |
Google popularizó el uso de SLIs y SLOs a través de su libro “Site Reliability Engineering” (2016), presentando un enfoque más ingenieril y menos contractual para gestionar la fiabilidad de los servicios.
La Jerarquía de los Niveles de Servicio: SLIs, SLOs y SLAs
Este punto requiere consideración cuidadosa en la implementación.
SLIs (Service Level Indicators)
Los SLIs son métricas cuantitativas que miden aspectos específicos del rendimiento de un servicio. Son las mediciones fundamentales sobre las que se construyen los objetivos y acuerdos.
Tipos comunes de SLIs
Disponibilidad: Porcentaje de tiempo que un sistema está operativo y funcional
Latencia: Tiempo que tarda el sistema en responder a una solicitud
Tasa de errores: Porcentaje de solicitudes que resultan en errores
Throughput: Cantidad de operaciones que el sistema puede procesar por unidad de tiempo
Saturación: Grado en que un recurso está ocupado (CPU, memoria, disco, etc.)
Frescura de datos: Cuán actualizados están los datos que se muestran al usuario
Implementación de SLIs con diferentes herramientas
Prometheus:
Esta implementación requiere atención a los detalles y seguimiento de las mejores prácticas.
SLI de disponibilidad basado en solicitudes exitosas
- record: availability:success_rate:ratio_rate5m expr: sum(rate(http_requests_total{status=~“2..”}[5m])) / sum(rate(http_requests_total[5m]))
SLI de latencia basado en el percentil 95
- record: latency:request_duration_p95:5m expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
SLI de tasa de errores
- record: errors:request_errors:ratio_rate5m expr: sum(rate(http_requests_total{status=~“5..”}[5m])) / sum(rate(http_requests_total[5m]))
Datadog:
{
"name": "Availability SLI",
"type": "metric alert",
"query": "sum(last_5m):sum:http.requests{status:200} / sum:http.requests{*} * 100 99.9",
"message": "Availability has dropped below 99.9%",
"tags": ["service:api", "env:production"],
"options": {
"thresholds": {
"critical": 99.9
}
}
}
SLOs (Service Level Objectives)
Los SLOs son objetivos específicos y medibles establecidos para los SLIs. Representan el nivel de servicio que nos comprometemos a ofrecer a nuestros usuarios o clientes.
Características de un buen SLO:
- Específico: Define claramente qué se está midiendo
- Medible: Cuantificable a través de un SLI
- Alcanzable: Realista dadas las restricciones técnicas y de recursos
- Relevante: Alineado con las expectativas del usuario y los objetivos del negocio
- Temporal: Definido para un período específico
Ejemplos de SLOs bien definidos
- El 99.95% de las solicitudes a la API REST serán exitosas (código 2xx) durante un período de 28 días
- El 99% de las solicitudes tendrán una latencia inferior a 300ms, medida durante un período de 30 días
- El tiempo de carga de la página principal será inferior a 2 segundos para el 95% de los usuarios durante una ventana móvil de 7 días
El concepto de presupuesto de error
El presupuesto de error es una derivación clave del SLO, que define cuántas fallas o incumplimientos podemos permitirnos:
Por ejemplo, con un SLO de disponibilidad del 99.9% y 1,000,000 de solicitudes al mes:
Este presupuesto se puede utilizar para:
- Determinar cuándo congelar lanzamientos de nuevas funciones (si el presupuesto está agotado)
- Equilibrar la velocidad de desarrollo con la estabilidad
- Tomar decisiones informadas sobre riesgos de implementación
Definiendo SLOs con Alerting Efectivo
Terraform para Google Cloud SLO:
resource "google_monitoring_slo" "api_availability" {
service = google_monitoring_service.api_service.id
slo_id = "api-availability-slo"
display_name = "API Availability SLO"
goal = 0.995 # 99.5%
rolling_period_days = 28
request_based_sli {
good_total_ratio {
total_service_filter = "resource.type=cloud_run_revision AND resource.labels.service_name=api-service"
good_service_filter = "resource.type=cloud_run_revision AND resource.labels.service_name=api-service AND metric.type=run.googleapis.com/request_count AND metric.labels.response_code_class!=5xx"
}
}
}
resource "google_monitoring_alert_policy" "slo_burn_rate_alert" {
display_name = "SLO Burn Rate Alert"
combiner = "OR"
conditions {
display_name = "Fast burn rate"
condition_threshold {
filter = "select_slo_burn_rate(\"${google_monitoring_slo.api_availability.id}\", \"1h\")"
comparison = "COMPARISON_GT"
threshold_value = 14.4 # Consumirá presupuesto en ~1 hora
duration = "60s"
}
}
conditions {
display_name = "Slow burn rate"
condition_threshold {
filter = "select_slo_burn_rate(\"${google_monitoring_slo.api_availability.id}\", \"6h\")"
comparison = "COMPARISON_GT"
threshold_value = 3 # Consumirá presupuesto en ~24 horas
duration = "600s"
}
}
alert_strategy {
notification_rate_limit {
period = "300s"
}
}
notification_channels = [
google_monitoring_notification_channel.email.id,
google_monitoring_notification_channel.slack.id
]
}
SLAs (Service Level Agreements)
Los SLAs son acuerdos contractuales entre un proveedor de servicios y sus clientes. Definen formalmente el nivel de servicio esperado, así como las compensaciones o penalizaciones si no se cumplen los objetivos.
Componentes clave de un SLA:
- Alcance del servicio: Qué servicios y funcionalidades están cubiertos
- Métricas de desempeño: Basadas en SLIs, pero con umbrales generalmente más bajos que los SLOs
- Responsabilidades: De ambas partes (proveedor y cliente)
- Exclusiones: Situaciones no cubiertas (mantenimiento planificado, fuerza mayor, etc.)
- Penalizaciones: Compensación en caso de incumplimiento
- Procedimientos de escalado: Cómo reportar y escalar problemas
Relación entre SLOs y SLAs
Un principio fundamental es establecer SLOs más estrictos que los SLAs. Por ejemplo:
- SLA de disponibilidad: 99.9% (aproximadamente 8.8 horas de caída por año)
- SLO interno: 99.95% (aproximadamente 4.4 horas de caída por año)
Esta diferencia proporciona un margen de seguridad y permite responder proactivamente antes de incumplir compromisos contractuales.
Ejemplo de cláusula SLA
Implementación Práctica: De la Teoría a la Acción
Esta implementación requiere atención a los detalles y seguimiento de las mejores prácticas.
Paso 1: Identificar los Servicios Críticos
Antes de definir SLIs y SLOs, es crucial identificar qué servicios son más importantes para tu negocio y usuarios.
Método de priorización:
- Impacto en usuario final (1-5)
- Impacto en ingresos (1-5)
- Dependencias (cuántos otros servicios dependen de éste) (1-5)
Puntuación total = Impacto en usuario × Impacto en ingresos × Dependencias
Ejemplo:
| Servicio | Impacto usuario | Impacto ingresos | Dependencias | Puntuación | Prioridad |
|---|---|---|---|---|---|
| Pasarela de pago | 5 | 5 | 3 | 75 | Alta |
| Sistema de autenticación | 4 | 3 | 5 | 60 | Alta |
| Sistema de recomendaciones | 3 | 4 | 2 | 24 | Media |
| Panel de administración | 2 | 2 | 1 | 4 | Baja |
Paso 2: Definir SLIs Significativos
Para cada servicio crítico, define SLIs que realmente reflejen la experiencia del usuario.
Plantilla para definición de SLIs:
## SLI: [Nombre del SLI]
- **Descripción**: [Qué mide este SLI]
- **Fórmula**: [Cómo se calcula]
- **Fuente de datos**: [De dónde se obtienen los datos]
- **Frecuencia de medición**: [Cada cuánto se mide]
- **Responsable**: [Equipo/persona responsable]
- **Notas adicionales**: [Consideraciones especiales]
Ejemplo para un servicio de API:
## SLI: Disponibilidad de API
- **Descripción**: Porcentaje de solicitudes exitosas (no 5xx)
- **Fórmula**: (Total de solicitudes - Solicitudes con errores 5xx) / Total de solicitudes × 100
- **Fuente de datos**: Logs de API Gateway + Prometheus
- **Frecuencia de medición**: Cada minuto, agregado por hora/día
- **Responsable**: Equipo de Plataforma
- **Notas adicionales**: Excluye endpoints de health check y readiness
## SLI: Latencia de API
- **Descripción**: Tiempo de respuesta para solicitudes a la API
- **Fórmula**: Percentil 95 del tiempo entre solicitud y respuesta completa
- **Fuente de datos**: Middleware de timing en aplicación
- **Frecuencia de medición**: Cada solicitud, agregado por minuto
- **Responsable**: Equipo de Backend
- **Notas adicionales**: Se mide en la capa de aplicación, no incluye latencia de red del cliente
Paso 3: Establecer SLOs Realistas
Los SLOs deben ser ambiciosos pero alcanzables. Una buena práctica es analizarlos históricamente antes de establecerlos formalmente.
Proceso recomendado:
- Recopilar datos históricos de los SLIs (mínimo 4-8 semanas)
- Analizar la distribución y tendencias
- Establecer un SLO inicial ligeramente mejor que el rendimiento histórico
- Revisar y ajustar periódicamente (trimestral o semestral)
Ejemplo de análisis histórico de latencia:
import pandas as pd
import matplotlib.pyplot as plt
from scipy import stats
# Cargar datos históricos de latencia (p95) por día
data = pd.read_csv('latency_p95_daily.csv')
# Calcular estadísticas
mean_latency = data['latency_ms'].mean()
percentile_99 = data['latency_ms'].quantile(0.99)
percentile_95 = data['latency_ms'].quantile(0.95)
# Visualizar distribución
plt.figure(figsize=(10, 6))
plt.hist(data['latency_ms'], bins=20, alpha=0.7)
plt.axvline(percentile_95, color='r', linestyle='--', label=f'95th percentile: {percentile_95:.1f}ms')
plt.axvline(mean_latency, color='g', linestyle='-', label=f'Mean: {mean_latency:.1f}ms')
plt.xlabel('Latencia P95 (ms)')
plt.ylabel('Frecuencia (días)')
plt.title('Distribución de Latencia P95 Diaria')
plt.legend()
plt.savefig('latency_distribution.png')
# Propuesta de SLO
proposed_slo = int(percentile_95 * 1.1) # 10% margen sobre el p95 histórico
print(f"SLO propuesto: {proposed_slo}ms para el 95% de las solicitudes")
Paso 4: Implementar Monitoreo y Alertas
Una vez definidos los SLOs, necesitas sistemas para monitorearlos continuamente y alertar cuando estén en riesgo.
Arquitectura de monitoreo para SLOs:
Dashboard de SLO en Grafana:
{
"annotations": {
"list": [
{
"builtIn": 1,
"datasource": "-- Grafana --",
"enable": true,
"hide": true,
"iconColor": "rgba(0, 211, 255, 1)",
"name": "Annotations & Alerts",
"type": "dashboard"
},
{
"datasource": "Prometheus",
"enable": true,
"expr": "changes(slo_deployments_total[1m]) > 0",
"iconColor": "rgba(255, 96, 96, 1)",
"name": "Deployments",
"titleFormat": "Deployment"
}
]
},
"editable": true,
"gnetId": null,
"graphTooltip": 0,
"id": 123,
"iteration": 1597951492522,
"links": [],
"panels": [
{
"datasource": null,
"gridPos": {
"h": 8,
"w": 12,
"x": 0,
"y": 0
},
"id": 2,
"options": {
"displayMode": "lcd",
"orientation": "horizontal",
"reduceOptions": {
"calcs": [
"lastNotNull"
],
"fields": "",
"values": false
},
"showUnfilled": true
},
"pluginVersion": "7.1.5",
"targets": [
{
"expr": "slo:availability:ratio30d",
"interval": "",
"legendFormat": "Availability (30d)",
"refId": "A"
}
],
"timeFrom": null,
"timeShift": null,
"title": "API Availability SLO (30d)",
"type": "bargauge"
},
{
"aliasColors": {},
"bars": false,
"dashLength": 10,
"dashes": false,
"datasource": null,
"fieldConfig": {
"defaults": {
"custom": {}
},
"overrides": []
},
"fill": 1,
"fillGradient": 0,
"gridPos": {
"h": 8,
"w": 12,
"x": 12,
"y": 0
},
"hiddenSeries": false,
"id": 4,
"legend": {
"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": true,
"linewidth": 1,
"nullPointMode": "null",
"percentage": false,
"pluginVersion": "7.1.5",
"pointradius": 2,
"points": false,
"renderer": "flot",
"seriesOverrides": [
{
"alias": "SLO",
"color": "#F2495C",
"dashes": true,
"fill": 0
}
],
"spaceLength": 10,
"stack": false,
"steppedLine": false,
"targets": [
{
"expr": "slo:availability:ratio1h",
"interval": "",
"legendFormat": "Availability (1h)",
"refId": "A"
},
{
"expr": "0.995",
"interval": "",
"legendFormat": "SLO",
"refId": "B"
}
],
"thresholds": [],
"timeFrom": null,
"timeRegions": [],
"timeShift": null,
"title": "API Availability (1h)",
"tooltip": {
"shared": true,
"sort": 0,
"value_type": "individual"
},
"type": "graph",
"xaxis": {
"buckets": null,
"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{
"format": "percentunit",
"label": null,
"logBase": 1,
"max": "1",
"min": "0.99",
"show": true
},
{
"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
],
"yaxis": {
"align": false,
"alignLevel": null
}
}
],
"schemaVersion": 26,
"style": "dark",
"tags": [
"slo",
"api"
],
"templating": {
"list": []
},
"time": {
"from": "now-24h",
"to": "now"
},
"timepicker": {},
"timezone": "",
"title": "API SLO Dashboard",
"version": 1
}
Paso 5: Gestionar y Comunicar
Los SLOs son más efectivos cuando se comunican adecuadamente y se incorporan en los procesos de toma de decisiones.
Informe mensual de SLO (plantilla):
# Informe de SLO - [Mes/Año]
## Resumen Ejecutivo
- SLOs cumplidos: X de Y (Z%)
- Incidentes significativos: N
- Presupuesto de error restante: XX%
## Detalles por Servicio
Este punto requiere consideración cuidadosa en la implementación.
### API
- **Disponibilidad**:
- Objetivo: 99.95%
- Actual: XX.XX%
- Estado: ✅ Cumplido / ⚠️ En riesgo / ❌ Incumplido
- Tendencia: ↑ Mejora / → Estable / ↓ Deterioro
- **Latencia**:
- Objetivo: P95 300ms
- Actual: XXXms
- Estado: ✅ Cumplido / ⚠️ En riesgo / ❌ Incumplido
- Tendencia: ↑ Mejora / → Estable / ↓ Deterioro
### [Otros servicios...]
Este punto requiere consideración cuidadosa en la implementación.
## Análisis de Incidentes
1. **Incidente #123** (2023-06-15)
- Impacto: Aumento de latencia a >500ms durante 45 minutos
- Causa raíz: Saturación de conexiones a base de datos
- Acciones correctivas: Implementación de connection pooling mejorado
## Presupuesto de Error
- Presupuesto inicial: 1,000 errores
- Consumido este mes: 250 errores (25%)
- Acumulado anual: 3,200 errores (42.7%)
## Cambios Planificados
- Propuesta de ajuste SLO de latencia: 250ms → 200ms basado en mejoras recientes
- Nueva métrica SLI para tracking de éxito de transacciones
## Próximos Pasos
- Implementar alertas más granulares para detección temprana
- Revisar y actualizar presupuesto de error para Q3
Ventajas y Beneficios Comprobados
La implementación efectiva de SLIs, SLOs y SLAs proporciona múltiples beneficios tangibles:
1. Alineación entre Equipos y Negocio
Los SLOs establecen un lenguaje común entre equipos técnicos y no técnicos:
Este enfoque cuantitativo permite:
- Conversaciones más productivas sobre prioridades
- Decisiones basadas en datos sobre inversiones en infraestructura
- Mejor comunicación del valor técnico a stakeholders no técnicos
2. Toma de Decisiones Basada en Datos
Con SLOs bien definidos, las decisiones sobre lanzamientos, arquitectura y recursos se vuelven más objetivas:
# Ejemplo conceptual: Algoritmo de decisión para lanzamientos
def should_deploy_new_release():
current_error_budget = get_current_error_budget()
error_budget_threshold = 0.2 # 20% del presupuesto restante
if current_error_budget error_budget_threshold:
return False, "Error budget depleted, postpone non-critical releases"
recent_incidents = get_incidents_last_7_days()
if len(recent_incidents) >= 2:
return False, "Multiple recent incidents, focus on stability"
return True, "Sufficient error budget available for release"
3. Cultura de Mejora Continua
Los SLOs fomentan una cultura de mejora constante:

- Medir: Recopilar datos de SLIs
- Evaluar: Comparar con SLOs
- Analizar: Identificar áreas de mejora
- Mejorar: Implementar cambios
- Repetir: Volver a medir y ajustar SLOs
4. Equilibrio entre Velocidad y Estabilidad
El concepto de presupuesto de error proporciona un mecanismo formal para equilibrar la innovación rápida con la estabilidad:
- Con presupuesto disponible: priorizar nuevas funcionalidades
- Con presupuesto agotado: priorizar estabilidad y fiabilidad
Desafíos Comunes y Cómo Superarlos
Este punto requiere consideración cuidadosa en la implementación.
1. Selección de Métricas Adecuadas
Desafío: Elegir SLIs que realmente reflejen la experiencia del usuario.
Solución:
- Comenzar con los Cuatro Indicadores Dorados: latencia, tráfico, errores y saturación
- Mapear el recorrido del usuario e identificar puntos críticos
- Validar SLIs con feedback real de usuarios
Ejemplo de mapeo de journey:
2. Establecimiento de Objetivos Realistas
Desafío: SLOs demasiado ambiciosos llevan a alertas constantes y fatiga; demasiado relajados no protegen la experiencia del usuario.
Solución:
- Implementar SLOs “silenciosos” inicialmente para calibrar
- Utilizar el modelo de mejora incremental (SLO actual × 1.05)
- Diferenciar entre SLOs internos y externos
Evolución de SLOs:
3. Gestión de Dependencias Externas
Desafío: Los servicios dependen de proveedores externos cuya fiabilidad afecta a tus SLOs.
Solución:
- Implementar SLIs de dependencias separados
- Diseñar para degradación elegante
- Ajustar SLOs considerando las garantías de los proveedores
Fórmula de SLO compuesto:
Ejemplos de degradación elegante:
public ProductResponse getProductDetails(String productId) {
ProductDetails details;
try {
// Intento principal con timeout
details = productService.getProduct(productId, 300, TimeUnit.MILLISECONDS);
} catch (TimeoutException e) {
// Degradación a caché con datos parcialmente actualizados
details = productCache.getProduct(productId);
metrics.incrementCounter("product_service_fallback");
}
PricingInfo pricing;
try {
// Intento principal con timeout más corto
pricing = pricingService.getPricing(productId, 150, TimeUnit.MILLISECONDS);
} catch (Exception e) {
// Fallback a último precio conocido
pricing = pricingCache.getLastKnownPricing(productId);
metrics.incrementCounter("pricing_service_fallback");
}
// Incluso si fallan ambos servicios, devolvemos lo que tenemos
return new ProductResponse(details, pricing);
}
4. Equilibrio entre Detalle y Sobrecarga
Desafío: Demasiados SLIs/SLOs crean sobrecarga de monitoreo y mantenimiento.
Solución:
- Comenzar con 2-3 SLIs por servicio crítico
- Implementar jerarquía de SLOs (críticos vs. aspiracionales)
- Revisar y consolidar periódicamente
Ejemplo de jerarquía:
Casos de Uso y Ejemplos del Mundo
Este punto requiere consideración cuidadosa en la implementación.
Caso 1: Plataforma de Comercio Electrónico
Contexto: Una plataforma de e-commerce con picos de tráfico estacionales y alta dependencia de los ingresos en la disponibilidad.
SLIs implementados:
- Disponibilidad de checkout
- Latencia de página de producto
- Tasa de conversión (como SLI de negocio)
Enfoque de SLO estacional:
- Temporada normal: 99.9% de disponibilidad (43 minutos de caída/mes)
- Temporada alta (Black Friday, Navidad): 99.99% (4.3 minutos de caída/mes)
Resultados:
- Reducción del 65% en incidentes durante temporada alta
- Incremento del 23% en ingresos año tras año
- Mejora de satisfacción del cliente (NPS +15 puntos)
Caso 2: API Financiera
Contexto: API de procesamiento de pagos con requisitos estrictos de fiabilidad y seguridad.
SLIs críticos:
- Disponibilidad de API: 99.99%
- Latencia de transacción: P95 500ms
- Tasa de error en autorizaciones: 0.01%
- Coherencia de datos: 100% (sin pérdida de transacciones)
Implementación técnica:
- Monitoreo multi-región con Prometheus y AlertManager
- Redundancia activa-activa en tres regiones
- Circuit breakers y degradación elegante
Ejemplo de dashboard de SLO:

Resultados:
- Certificación PCI-DSS Level 1
- Cero pérdidas de datos en 3 años de operación
- Tiempo medio de detección de problemas reducido de 15 minutos a 45 segundos
Caso 3: Startup SaaS B2B
Contexto: Startup en crecimiento con recursos limitados que necesita equilibrar desarrollo de producto y fiabilidad.
Enfoque pragmático:
- SLOs iniciales modestos (98% disponibilidad)
- Presupuesto de error utilizado estratégicamente para nuevas funcionalidades
- SLOs diferenciados por nivel de cliente (standard vs. enterprise)
Evolución de SLOs a lo largo del tiempo:
| Etapa | Disponibilidad | Latencia (P95) | Alerting |
|---|---|---|---|
| MVP | 98% | 1000ms | Email en horario laboral |
| Crecimiento | 99% | 750ms | Alertas en Slack 24/7 |
| Enterprise | 99.9% | 500ms | PagerDuty con rotación |
Resultados:
- Crecimiento sostenible sin burnout del equipo
- Capacidad para vender a clientes enterprise con SLAs apropiados
- Transparencia con inversores sobre trade-offs técnicos
El Futuro de SLIs, SLOs y SLAs
La evolución de estos conceptos continúa adaptándose a los cambios en el desarrollo de software y las expectativas de los usuarios.
1. SLOs Centrados en el Usuario
Los SLOs están evolucionando para reflejar mejor la experiencia real del usuario:
- Web Vitals como SLIs: Metrics como LCP, FID y CLS como indicadores estándar
- SLOs de negocio: Vinculando métricas técnicas con resultados de negocio
- SLOs personalizados: Adaptados a segmentos específicos de usuarios o casos de uso
// Ejemplo conceptual: SLO basado en Core Web Vitals
const webVitalsSLO = {
name: "Core Web Vitals",
description: "Experiencia de usuario óptima según estándares de Google",
indicators: [
{
name: "LCP (Largest Contentful Paint)",
target: "2.5s para el 75% de cargas de página",
critical: true
},
{
name: "FID (First Input Delay)",
target: "100ms para el 90% de interacciones",
critical: true
},
{
name: "CLS (Cumulative Layout Shift)",
target: "0.1 para el 80% de cargas de página",
critical: false
}
],
business_impact: "Mejora de 15% en conversiones por cada 0.5s de mejora en LCP"
};
2. SLOs Automatizados con Machine Learning
La inteligencia artificial está transformando la definición y gestión de SLOs:
- Detección automática de anomalías: Identificación de problemas antes de afectar SLOs
- SLOs adaptativos: Ajuste automático basado en patrones históricos y previsiones
- Análisis predictivo: Anticipar violaciones de SLO antes de que ocurran
# Concepto: Sistema de SLO adaptativo con ML
class AdaptiveSLO:
def __init__(self, service_name, initial_target=0.99):
self.service_name = service_name
self.current_target = initial_target
self.model = load_prediction_model(f"models/{service_name}_slo_predictor.pkl")
def predict_optimal_slo(self, recent_performance, upcoming_events):
"""Predice el SLO óptimo basado en datos recientes y eventos futuros"""
features = self._extract_features(recent_performance, upcoming_events)
predicted_slo = self.model.predict(features)[0]
# Limitar cambios a incrementos razonables
max_adjustment = 0.005 # Máximo 0.5% de cambio cada vez
if abs(predicted_slo - self.current_target) > max_adjustment:
direction = 1 if predicted_slo > self.current_target else -1
predicted_slo = self.current_target + (direction * max_adjustment)
return predicted_slo
def update_slo(self):
"""Actualiza el SLO basado en predicciones y lo aplica"""
recent_data = fetch_recent_performance(self.service_name, days=30)
calendar_events = fetch_upcoming_events(days_ahead=14)
new_target = self.predict_optimal_slo(recent_data, calendar_events)
# Actualizar si el cambio es significativo
if abs(new_target - self.current_target) >= 0.001:
self.current_target = new_target
apply_new_slo(self.service_name, new_target)
log_slo_change(self.service_name, new_target, "ML-based adjustment")
3. SLOs como Código
La tendencia de “todo como código” está llegando a los SLOs:
- Definición declarativa: SLOs versionados en repositorios Git como código
- CI/CD para SLOs: Pruebas automatizadas de definiciones de SLO
- Frameworks dedicados: Herramientas específicas para gestión de SLOs
# sloth - Ejemplo de SLO como código
version: "1.0"
service: "payment-api"
labels:
team: "payments"
tier: "1"
slos:
- name: "availability"
objective: 0.995
description: "Proporción de solicitudes exitosas"
sli:
events:
error_query: 'sum(rate(http_requests_total{job="payment-api",status=~"5.."}[{{.window}}]))'
total_query: 'sum(rate(http_requests_total{job="payment-api"}[{{.window}}]))'
alerting:
name: "HighErrorRate"
labels:
severity: "page"
annotations:
summary: "Alta tasa de errores en la API de pagos"
description: "La API de pagos está experimentando una tasa de errores superior al objetivo del SLO."
page_alert:
for: "5m"
burn_rate_threshold: 14.4
ticket_alert:
for: "30m"
burn_rate_threshold: 1
Conclusión
Los SLIs, SLOs y SLAs representan mucho más que simples métricas y acuerdos; constituyen un framework completo para gestionar la fiabilidad de servicios digitales. Este enfoque permite:
- Cuantificar la calidad de servicios técnicos complejos
- Alinear expectativas entre equipos técnicos, negocio y clientes
- Tomar decisiones informadas sobre trade-offs entre velocidad y estabilidad
- Mejorar continuamente con objetivos claros y medibles
A medida que los sistemas se vuelven más complejos y distribuidos, seguir las mejores prácticas en torno a los SLIs, SLOs y SLAs será cada vez más crítico para el éxito. Las organizaciones que dominan estos conceptos no solo mejoran la fiabilidad técnica, sino que también fortalecen la confianza con los clientes y obtienen ventajas competitivas significativas.
La adopción de SLIs, SLOs y SLAs requiere un cambio cultural además de técnico. Implica pasar de una mentalidad reactiva a una proactiva, donde la fiabilidad se diseña desde el principio y se mide constantemente. Este cambio es fundamental para construir servicios digitales que realmente cumplan y superen las expectativas de los usuarios en un mundo cada vez más dependiente de la tecnología.
Recursos Adicionales
- Google SRE Book - Capítulo sobre SLOs
- Documentación oficial y guías de mejores prácticas
- Herramientas y frameworks recomendados
- Casos de estudio y ejemplos prácticos
- Implementando SLOs (O’Reilly)
- Framework OpenSLO
- Prometheus + Grafana para SLOs
- SLOconf - Conferencia dedicada a SLOs
- Proyecto Sloth para SLOs como código
- Herramienta Error Budget Calculator