4 min lectura • Guide 821 of 877
Service Level Objectives
La reliability es una feature. GitScrum ayuda a equipos a trackear SLOs junto con feature work, asegurando que las inversiones en reliability sean visibles y priorizadas.
Fundamentos de SLO
TERMINOLOGÍA DE SERVICE LEVEL
═════════════════════════════
SLI (Service Level Indicator):
┌─────────────────────────────────────────────────────────────┐
│ │
│ La métrica siendo medida │
│ │
│ Ejemplos: │
│ • Request latency (p95) │
│ • Availability (successful requests / total requests) │
│ • Error rate │
│ • Throughput │
│ │
└─────────────────────────────────────────────────────────────┘
SLO (Service Level Objective):
┌─────────────────────────────────────────────────────────────┐
│ │
│ El valor target para el SLI │
│ │
│ Ejemplos: │
│ • Latency p95 < 200ms │
│ • Availability >= 99.9% │
│ • Error rate < 0.1% │
│ │
└─────────────────────────────────────────────────────────────┘
SLA (Service Level Agreement):
┌─────────────────────────────────────────────────────────────┐
│ │
│ Contrato con consecuencias │
│ │
│ Ejemplos: │
│ • "99.9% uptime o cliente recibe crédito" │
│ • Compromiso legal │
│ • Usualmente más loose que SLO interno │
│ │
└─────────────────────────────────────────────────────────────┘
RELACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SLI ──────→ SLO ──────→ SLA │
│ (métrica) (target) (contrato) │
│ │
│ Ejemplo: │
│ "Request latency" → "p95 < 200ms" → "99% < 500ms" │
│ │
│ SLO es más estricto que SLA (buffer interno) │
│ │
└─────────────────────────────────────────────────────────────┘
Error Budgets
CONCEPTO DE ERROR BUDGET
════════════════════════
¿QUÉ ES?:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Si tu SLO es 99.9% availability: │
│ │
│ Error budget = 100% - 99.9% = 0.1% │
│ │
│ En un mes de 30 días: │
│ 0.1% de 30 días × 24 horas × 60 min = 43.2 minutos │
│ │
│ Puedes tener hasta 43 minutos de downtime │
│ antes de violar el SLO │
│ │
└─────────────────────────────────────────────────────────────┘
CÓMO USARLO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Error budget > 50%: Ship features agresivamente │
│ Error budget 25-50%: Normal pace │
│ Error budget 10-25%: Ser más cuidadoso │
│ Error budget < 10%: Congelar releases, focus en stability │
│ Error budget agotado: Solo fixes de reliability │
│ │
└─────────────────────────────────────────────────────────────┘
BENEFICIOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Hace tradeoff velocity vs stability explícito │
│ • Permite "gastar" reliability en features │
│ • Crea incentivo para mejorar reliability │
│ • Objetivo data-driven, no emocional │
│ │
└─────────────────────────────────────────────────────────────┘
Definiendo SLOs
PROCESO DE DEFINICIÓN
═════════════════════
PASO 1: IDENTIFICAR SLIS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ¿Qué importa a los usuarios? │
│ ├── ¿Está disponible? (Availability) │
│ ├── ¿Es rápido? (Latency) │
│ ├── ¿Funciona correctamente? (Correctness) │
│ └── ¿Puede manejar la carga? (Throughput) │
│ │
└─────────────────────────────────────────────────────────────┘
PASO 2: ESTABLECER TARGETS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Basado en: │
│ ├── Performance actual (baseline) │
│ ├── Expectativas del usuario │
│ ├── Capacidad técnica │
│ └── Costo de mejora │
│ │
│ Regla: No empieces con 100% │
│ 99.9% es muy diferente de 99.99% │
│ │
└─────────────────────────────────────────────────────────────┘
PASO 3: IMPLEMENTAR MEDICIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Instrumentación correcta │
│ • Dashboards de monitoring │
│ • Alertas basadas en SLO │
│ • Error budget tracking │
│ │
└─────────────────────────────────────────────────────────────┘
En GitScrum
SLOs EN GITSCRUM
════════════════
TRACKING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Tareas de reliability en backlog │
│ • Label: reliability, slo │
│ • Priorización basada en error budget │
│ • Visibilidad de tradeoffs │
│ │
└─────────────────────────────────────────────────────────────┘
CUANDO ERROR BUDGET BAJO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Alertar al equipo │
│ • Priorizar reliability work │
│ • Reducir releases riesgosos │
│ • Post-mortem de incidents │
│ │
└─────────────────────────────────────────────────────────────┘