NutriFlow — SLO Dashboard · Arquitecto de Fiabilidad

SLOs Definidos

booking-api · plan-generator · patient-sync

Alertas PromQL

3 fast_burn · 3 slow_burn · 3 ticket · multi-ventana

SLOs Auditados

5 FAIL · 1 WARN detectados en SLOs existentes

Budget Crítico

40 min

booking-api · presupuesto más ajustado (99.9%)

SLO Definitions — 3 servicios NutriFlow

booking-api request-success-rate

Paciente completa reserva de cita sin error

99.9%

Owner @team-booking

Ventana 28 días

Numerador http_requests{status=~"2..|3.."}

Denominador http_requests_total

Labels env=prod, region=eu-west-1

Revisión quarterly

Error Budget 40.32 min / 28d

Presupuesto más ajustado — crítico para el negocio

plan-generator request-latency

PDF plan nutricional en menos de 3 segundos

99.7%

Owner @team-ai

Ventana 28 días

Numerador duration{plan-gen} < 3s

Denominador count(all_duration_samples)

Labels env=prod

Revisión quarterly

Error Budget 120.96 min / 28d

Servicio IA — margen razonable para degrado por carga

patient-sync data-freshness

Datos visibles en <5 min tras envío (webhook)

99.5%

Owner @team-data

Ventana 28 días

Numerador data_age_seconds < 300

Denominador count(all_data_points)

Labels env=prod

Revisión quarterly

Error Budget 201.60 min / 28d

Servicio webhook — mayor tolerancia por naturaleza asíncrona

Multi-Window Burn-Rate Alerts — Google SRE Workbook Ch.5

Servicio	Alerta	Severidad	Burn Rate	Ventana Larga	Ventana Corta	% Budget Consumido	Rationale
booking-api target 99.9% budget: 40 min	fast_burn	● PAGE	13.44×	1h	5m	2%	Sistema en llamas
	slow_burn	● PAGE	5.6×	6h	30m	5%	Degradación sostenida
	ticket_burn	◆ TICKET	0.933×	3d	6h	10%	Tendencia negativa
plan-generator target 99.7% budget: 121 min	fast_burn	● PAGE	13.44×	1h	5m	2%	Sistema en llamas
	slow_burn	● PAGE	5.6×	6h	30m	5%	Degradación sostenida
	ticket_burn	◆ TICKET	0.933×	3d	6h	10%	Tendencia negativa
patient-sync target 99.5% budget: 202 min	fast_burn	● PAGE	13.44×	1h	5m	2%	Sistema en llamas
	slow_burn	● PAGE	5.6×	6h	30m	5%	Degradación sostenida
	ticket_burn	◆ TICKET	0.933×	3d	6h	10%	Tendencia negativa

PromQL Alert Rules — booking-api (ejemplo)

fast_burn

● PAGE

# fast_burn — 2% budget / 1h = sistema en llamas
# Burn rate threshold: 13.44
(
  sli:rate1h > 13.44 * (1 - 0.999)
  AND
  sli:rate5m > 13.44 * (1 - 0.999)
)

slow_burn

● PAGE

# slow_burn — 5% budget / 6h = degradación sostenida
# Burn rate threshold: 5.6
(
  sli:rate6h > 5.6 * (1 - 0.999)
  AND
  sli:rate30m > 5.6 * (1 - 0.999)
)

ticket_burn

◆ TICKET

# ticket_burn — 10% budget / 3d = tendencia negativa
# Burn rate threshold: 0.933
(
  sli:rate3d > 0.933 * (1 - 0.999)
  AND
  sli:rate6h > 0.933 * (1 - 0.999)
)

Budget matemática — booking-api

target 99.9% / 28d

# Fracción de error permitida
bad_fraction = 0.1% = 0.001

# Presupuesto de tiempo
budget = 28d × 24h × 60m × 0.001
       = 40.32 minutos

# Fast burn: 2% de 40.32 min en 1h
threshold = 0.02 / (1h / 672h) = 13.44×

# MTTD SLO violation: <30 min ✓

SLO Audit — 2 SLOs Existentes (Antes del Fix)

notification-slo.md

4 FAIL

FAIL

target_too_high

target 99.99% — sostenible solo con inversión masiva en ingeniería. Sin plan documentado, bajar el target.

FAIL

window_too_short

window 3d < 7d — ruido estadístico domina. Usar mínimo 7 días (recomendado: 28d).

FAIL

no_error_budget_policy

No hay referencia a política de presupuesto de error. Sin acción acordada, quemar el budget no significa nada.

FAIL

cpu_as_sli

cpu_usage ≠ experiencia de usuario. El sistema puede estar "verde" mientras los usuarios sufren. Usar SLI de requests.

auth-slo.md

1 FAIL 1 WARN

WARN

target_too_low

target 98.5% ≤ 99% — probablemente SLI equivocado. Los usuarios notarán 1.5% de fallos (≈ 1 de cada 67 peticiones).

FAIL

no_error_budget_policy

No hay política de error budget. Añadir: qué hace el equipo cuando se consume el 50%, 75% y 100% del presupuesto.

Fix recomendado — auth-slo

1. Subir target a 99.9% (medir histórico 30d primero)
2. Añadir policy_doc con link a runbook
3. Ejecutar error_budget_calculator.py --target 99.9

SLI Selection — Asignación por Servicio NutriFlow

Experiencia de usuario	Tipo de SLI	Señal medida	Servicio asignado
"¿Completó la reserva sin error?"	request-success-rate	2xx+3xx / total_requests	booking-api ✓
"¿Llegó el PDF en menos de 3 segundos?"	request-latency	count(duration < 3s) / total	plan-generator ✓
"¿Estaba disponible el servicio?"	availability-time	(window - downtime) / window	— no asignado
"¿Están los datos actualizados?"	data-freshness	count(age < 5min) / total_points	patient-sync ✓
"¿Era correcto el plan generado?"	correctness	count(correct) / total_outputs	— pendiente v2.1

SLO Reliability Dashboard