SLA/OLA con proveedores

1) Términos y límites

SLI es un indicador medible (disponibilidad, latencia p99, webhooks procesados con éxito, RPO/RTO).
SLO es el valor objetivo de SLI por ventana de medición (por ejemplo, 99. 9 %/30 días).
SLA es un instrumento jurídicamente vinculante (SLO + procedimientos + reembolsos).
OLA - Objetivos y procesos internos que aseguran el cumplimiento de SLA.
UC (Contrato Underpinning) es un «sustrato» con terceros (canales, centros de datos, CDN, etc.).

Límites: separe claramente el área de responsabilidad del proveedor (nube/WAF/CDN/pasarela de pago/proveedor KYC) de su zona (código, configuración, configuración del cliente).

2) Matriz de criticidad y selección del modelo

La profundidad del SLA, el alcance de las inspecciones y los requisitos de OLA/UC dependen de la matriz.

3) Métricas y ventanas de medición

Disponibilidad (Availability): la proporción de tiempo que el servicio realiza solicitudes según las tolerancias.
Latencia: p95/p99 para operaciones clave; se tiene en cuenta el «éxito lento».
Fiabilidad de datos: RPO (pérdida máxima de datos permitida) y RTO (tiempo de recuperación).
Ancho de banda/límites: cuotas garantizadas (RPS/MBps).
Calidad de las integraciones: porcentaje de webhooks entregados ≤ X min, proporción de respuestas 2xx, repeticiones y deduplicación.
Ventana de medición: 30 días mensuales/deslizantes, excepciones (trabajo programado) con límites.

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• Donde outage es un estado no disponible confirmado por monitoreo externo, no sólo por la página de estado del proveedor.

4) Contenido de SLA (plantilla de sección)

1. Tema y área (servicios, regiones, versiones de la API).
2. Definiciones (SLI/SLO, «incidente», «trabajo planificado», «fuerza mayor»).
3. Objetivos de servicio (SLO) por categoría de solicitud y región.
4. Monitoreo y base de pruebas: de qué manera, con qué sensores, con qué periodicidad.
5. Incidentes y escaladas: canales, tiempos de respuesta/actualización, roles.
6. Reembolsos: créditos/multas/bonificaciones, umbrales, fórmulas.
7. Seguridad y privacidad: DPA, cifrado, registros, notificaciones de infracciones.
8. Cambios de servicio: deprechates, ventana de notificaciones, compatibilidad.
9. Continuidad y DR: RPO/RTO, pruebas de recuperación.
10. Auditoría y cumplimiento: derecho a auditorías, informes, certificaciones.
11. Plan de salida: exportación de datos, plazos, formato, ayuda en la migración.
12. Disposiciones legales: jurisdicción, fuerza mayor, confidencialidad, validez.

5) Ejemplos de formulaciones (fragmentos)

5. 1 Disponibilidad y medición

"El proveedor proporciona 99. 95% de disponibilidad en cada mes calendario. La disponibilidad se mide mediante el monitoreo sintético externo del Cliente desde ≥3 regiones a intervalos de ≤1 minutos. La inaccesibilidad registrada en ≥2 regiones se considera un incidente de nivel de SEV2 al mismo tiempo y se cuenta en Downtime"

5. 2 Latencia de la API clave

"p99 tiempo de respuesta 'POST/payments/authorize' ≤ 450 ms en el 95% de los días del mes. Para la proporción de solicitudes que superan el umbral, se proporciona un informe con un análisis de las causas"

5. 3 Incidentes y escaladas

"S1: ack ≤ 15 min, apdate cada ≤ 30 min, recuperación objetivo ≤ 2 h; S2: ack ≤ 30 min, apdates ≤ 60 min; S3: el siguiente día laborable. Canales: teléfono 24 × 7, puente de chat, correo electrónico"

5. 4 Reembolsos (préstamos)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

Los préstamos no excluyen otras formas de reparación por negligencia grave.

5. 5 Deprecates y compatibilidad

"Al menos 180 días de notificación para cambios que rompan la compatibilidad. Soporte paralelo para vN y vN + 1 durante al menos 90 días"

5. 6 Salida (Exit)

"Dentro de los 30 días posteriores a la terminación, el proveedor proporciona gratuitamente la exportación completa de datos en los formatos de esquema Parquet/JSON +; Servicios de migración adicionales - tarifa X. La destrucción de copias está confirmada por el acto"

6) OLA: soporte interno para SLA externo

• Objetivos: p99 gateway ≤ 200 ms, error rate ≤ 0. 3%, DR: RPO 0, RTO 30 min.
• Responsabilidad: SRE-on-call, 24 × 7; dashboards y alertas comunes.
• Procesos: caos-smoke en lanzamientos, perfume-smoke en PR, heurísticas de shading.
• Gates: bloque de deboia cuando falla la prueba SLO/xaoc; actualización obligatoria de runbook.

7) Seguimiento y pruebas

Sintética: muestras externas (HTTP/TCP), ruta de usuario, «éxito lento».
RUM: monitoreo personalizado real para confirmar el impacto.
Correlación: etiquetas 'provider', 'region', 'api _ method', 'incident _ id'.
Artefactos: capturas de pantalla/tracks/logs, exportación de KPI, cronología de escalaciones.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) Incidentes e interacción

1. Clasificación SEV, apertura de sala de guerra, asignación IC.

2. Notificación al proveedor por «canal caliente», transmisión de artefactos.

3. Modos de bypass/marcas de bypass (stale, shading, rate-cap).

4. Tiempo compartido, recuperación.

5. Acción post mortem +: actualizar la configuración de límites, claves, rutas de respaldo.

6. Iniciación de préstamos por SLA, fijación en la facturación.

9) Seguridad y DPA

DPA/privacidad: funciones de controlador/procesador, categorías de datos, base de legalidad, plazos/objetivos de procesamiento, subprocesadores y sus SLA.
Cifrado: TLS1. 2+, PFS; datos en reposo, administración de claves (KMS/HSM), rotación.
Auditoría: registros de acceso, notificaciones de infracciones ≤ 72 h, informes pentest bajo petición.
Localización: región de almacenamiento, prohibición de exportación sin consentimiento.

10) Supply Chain y compatibilidad

SBOM/vulnerabilidades: políticas de umbrales CVSS y plazos de corrección (criticado ≤ 7 días, alto ≤ 14).
Compatibilidad con API: pruebas contractuales, «sandbox» y fixtures estables.
Cambios en el proveedor: notas de lanzamiento tempranas, previsualizaciones/ventanas beta, compatibilidad con versiones anteriores.

11) Multipropósito y Failover

Active/Active: más difícil y costoso, pero mayor disponibilidad (tenga en cuenta la consistencia).
Active/Passive: reserva fría/caliente, entrenamiento regular DR.
Abstracciones/adaptadores: contrato único, enrutamiento por salud/costo/factor carbono (si es relevante).
Términos de licencia/comercial: portabilidad, limitación de la retirada de datos, coste de egresos.

12) Plan de salida y ensayos periódicos

Directorio de datos/esquemas y volúmenes.
Script de portabilidad SDK/API (mínimo - segundo origen).
Prueba de «salida seca»: exportación/importación, recuperación, verificación de invariantes.
Plazos legales de retención/eliminación después de la salida.

13) Pruebas de contrato y conformance

Muestras de API: positivo/negativo, límites, errores y retratos.
Entrega de eventos/webhooks: firma/hora/dedoup/repetición.
Líneas de perforación: p99, ancho de banda; pruebas de regresión de las notas de lanzamiento del proveedor.
Región cruzada: la degradación de una sola región no debe interrumpir el SLO globalmente.

14) Anti-patrones

SLA «en la página de estado» sin dimensiones externas.
Los mismos objetivos para todas las regiones/endpoints.
Falta de derechos de auditoría y registros detallados de incidentes.
No hay una OLA/UC → no hay ninguna obligación externa de cumplir internamente.
Plan de salida indefinido → rehén del proveedor.
«Multas solo con créditos» sin derecho a rescindir en infracciones sistemáticas.
Deprecates sin ventana de transición.

15) Check-list del arquitecto

1. ¿Definidos SLI/SLO para flow clave y regiones?
2. ¿Ha elegido un método de monitoreo externo y una base de pruebas?
3. ¿El SLA especifica incidentes, escaladas, ventanas de trabajo programado y un límite de excepciones?
4. ¿Hay una escala de crédito/multas y un derecho de rescisión en N infracciones?
5. DPA/seguridad: ¿cifrado, registros, notificaciones, subprocesadores, localización?
6. ¿Pruebas contractuales y cajas de arena en pipeline?
7. ¿La OLA/UC interna permite la ejecución de SLOs externos?
8. DR: reclamado por RPO/RTO, se realizan entrenamientos, ¿hay informes?
9. Plan de salida: formatos de exportación, plazos, práctica de «salida en seco»?
10. ¿Los gates en CI/CD bloquean lanzamientos que aumentan el riesgo de infracción de SLA?

16) Mini ejemplos (sketches)

16. 1 Política de «deploy-gate» sobre el riesgo del proveedor

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 Exportación de «pruebas de incidente»

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 Prueba contractual de Webhook (pseudocódigo)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

SLA/OLA no es solo un «papel legal», sino un mecanismo arquitectónico de gestión de riesgos y calidad. Métricas y ventanas adecuadas, monitoreo externo, procedimientos claros de incidentes y reparaciones, OLA/UC internos, gates en pipelines, multi-proveedores y plan de salida real convierten la dependencia de los proveedores en una parte controlada, medible y económicamente predecible de su plataforma.