GH GambleHub

Informes uptime y auditoría de SLA

1) Por qué se necesita un proceso formal de informes uptime

Confianza del cliente y transparencia contractual: una única técnica de medición, cálculos repetibles.
Gestión de SLO y presupuesto de errores: un conjunto de datos de disponibilidad con lanzamientos e incidentes.
Los préstamos SLA correctos son fórmulas objetivas, pagos/compensación predecibles.
Sostenibilidad legal - base de pruebas, auditoría independiente, Legal Hold.


2) Términos y límites

SLI Disponibilidad - Una fracción de las verificaciones/transacciones exitosas durante el período.
SLO es un objetivo interno (por ejemplo, 99. 95% en 28 días).
SLA es una obligación externa (por ejemplo, 99. 9 %/mes + préstamos de servicios).
La ventana de medición es un mes calendario (SLA) y una ventana rolling (SLO).
Scope: qué componentes se incluyen en el cálculo (edge, API, pagos) y cuáles no (portal de administración, no prod).

💡 Regla: SLA ≤ SLO y se basa en SLI verificados por el cliente.

3) Fuentes de la verdad (y cuándo cuál es el principal)

1. Sintética (blackbox/headless) es un SLI primario para la «disponibilidad ocular del usuario».
2. Registros/métricas: confirman la escala y la naturaleza del fallo.
3. Eventos comerciales: «éxito de la operación» (por ejemplo, el pago está autorizado).
4. Status Page - Comunicación pública; se compara con los hechos Nº 1-3.

En caso de discrepancias: prioridad detrás de la sintética con el quorum correcto de ≥2 regiones.


4) Metodología para calcular la disponibilidad

4. 1 Fórmula básica


Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 Cuórum multi-regional

El incidente se contabiliza si los ≥N de las regiones independientes/ASN registran simultáneamente la denegación.
Recomendado: N = 2 de 3 (EU/NA/APAC).

4. 3 Tipos de SLI

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
SLI Business: transacciones exitosas/todos los intentos (excluyendo fallos de cliente).

4. 4 Excepciones (documented)

Ventanas de mantenimiento programadas, anunciadas con antelación a las horas N y respetadas.
Fuerza mayor de SLA (por ejemplo, proveedor de desastres IX) - sólo si hay evidencia y aviso público.
Errores/restricciones del cliente (quota exceeded, 4xx).


5) Política de mantenimiento de ventanas

Franjas horarias acordadas en el contrato (p. ej., T. 02: 00-04: 00 por UTC + 0).
Los marcadores 'mantenimiento = verdadero' en alertas/paneles → una excepción a SLI.
Umbral de notificación: con un mínimo de 5 días hábiles (o como en el contrato).
Fuera de la ventana - se considera una influencia SLA.


6) Casos de edge y reglas de redondeo

Brownout (deterioro parcial): cuenta la proporción de fallos (downtime weighted) en lugar de «0/1».
Flapping: unidad mínima de contabilidad - intervalo de muestra (por ejemplo, 30-60 segundos) + hysteresis (por: 2-5 minutos).
Clock drift: todo el tiempo en UTC y ISO-8601; sincronización NTP.


7) Ejemplos de PromQL (sintética → aptime)

Éxito de la validación HTTP:
promql probe_success{job="blackbox-http"} == 1
p95 latency:
promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))
SLA-aptime en un mes (segundo):
promql sum_over_time((probe_success==1)[30d]) / (30246060)
Quorum de fallos (≥2 de la región en 3 minutos):
promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) Ejemplos de SQL (agregaciones de informes)

Aptime y downtime de meses:
sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;
Conciliación con la página de estado (incidentes):
sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) Plantilla de informe mensual (Customer-friendly)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) Créditos SLA: cálculo y aplicación

Tabla de créditos: por ejemplo, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10%, etc.
True-up: el crédito se aplica como credit note a la siguiente cuenta.
Automatización: regla "si 'measured _ availability <SLA' → 'credit _ note. create()`».
Escaparate para el cliente: tarjeta de portal «SLA credits balance».


11) Auditoría, Pruebas y Legal Hold

Auditoría-trail: quién/qué/cuándo calculó, versión de la técnica, sumas de comprobación.
Los datos raw son inmutables (append-only); ajustes - por registros individuales.
Legal Hold: congelar el rango de datos (muestras, registros, tarjetas de incidente, alertas).
Réplica de archiving: almacenamiento independiente (WORM/S3 Object Lock).


12) Conciliación con la página de status público

El incidente en la página de estado está obligado a tener una línea de tiempo y componentes.
No coincidencia tiempo/escala → se crea discrepancy-record y se realiza por RCA.
El resultado del informe contiene la sección «Reconciliation Notes».


13) Incidentes e informes

Cada ventana de downtime corresponde a una tarjeta INC (ID, SEV, propietario, RCA, CAPA).
En el informe: enlace a INC, raíz breve, estado CAPA.
Para SEV-1: postmore de temas ≤ 48 h del cierre.


14) Control de calidad de datos

Higiene de muestras:> 99% de agentes de escrúpulos exitosos, sin pases> 5 minutos.
Anti-ruido: quorum + multi-window, debounce.
El empalme de pistas/registros se registra y documenta.
Métodos de prueba: pruebas de cálculo unit, ficheros de oro en datos históricos.


15) Seguridad y privacidad

TLS/mTLS para ingest, firma de paquetes (HMAC).
Edición PII en logs/informes; El informe SLA no debe revelar datos personales.
RBAC/ABAC a los informes; las huellas de acceso se escriben en el registro de auditoría.


16) Dashboards y widgets SLO (qué mostrar)

Overall availability por servicios para el mes/trimestre.
Downtime Windows con severity y el canal del objeto.
Error budget burn (fast/slow) y tendencias.
Releases overlay - anotaciones de las publicaciones.
SLA credits forecast - con la tendencia actual.


17) Plan de implementación (3 iteraciones)

1. Modelo y datos (2 semanas): fijar SLI/SLO/SLA, incluir sintética quorum, recoger «materia prima» en DWH.
2. Cálculo e informe (2-3 semanas): fórmulas, SQL/PromQL, plantillas YAML/PDF, portal del cliente, préstamos automáticos.
3. Auditoría y automatización (3-4 semanas): Legal Hold, reconciliation con status page, webhooks firmados, regulaciones de dispouts.


18) Check-list de la calidad del informe

  • Se han definido scope, SLI, técnica y ventana de medición.
  • Hay quorum y multi-window; flapping se suprime.
  • Las excepciones (mantenimiento/fuerza mayor) están documentadas.
  • Cada ventana de downtime está asociada con INC y RCA.
  • Los créditos SLA son contados y reflejados en la facturación.
  • Reproducimos el informe (versiones de fórmulas/datos).
  • Audit Trail y Legal Hold están incluidos.
  • Se negocia la página de estado público (reconciliation notes).

19) Mini preguntas frecuentes

¿Por qué los sintéticos son la fuente principal?
Es el camino más cercano al usuario e incluye un perímetro (DNS/CDN/WAF). Métricas/registros - aclarar la causa.

¿Cómo contamos las degradaciones parciales?
Downtime ponderado: la proporción de fallas × la duración de la ventana, no «todo o nada».

¿Es necesario almacenar los controles «crudos»?
Sí. Para auditar y volver a calcular en caso de disputa - raw necesita necesariamente.


Resultado

Los informes y auditorías uptime de SLA no son una «cifra de fin de mes», sino un sistema reproducible de medición, reglas y evidencia: SLIs correctos, comprobaciones de quorum, fórmulas transparentes, conjunto de incidentes y facturación, control de excepciones y Legal Hold. Fije la metodología, automatice el cálculo y los créditos, mantenga el trail de auditoría, y sus SLA se volverán manejables, comprensibles y seguros.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.