High Availability и SLA

High Availability и SLA

1) Términos y relación con el negocio

SLI (Service Level Indicator) es el indicador de servicio medido (por ejemplo, la proporción de solicitudes exitosas de 2xx/3xx ≤ T ms).
SLO (Service Level Objective) es el valor de destino SLI (por ejemplo, "99. 95% de las solicitudes ≤ 300 ms").
SLA (Service Level Agreement) es una obligación contractual con el cliente (multas/préstamos en caso de infracción).
HA (High Availability) son medidas arquitectónicas y operativas que permiten la ejecución de SLO/SLA.

Principio: El SLA se basa en el SLO y el SLO en los SLI observados. No se puede prometer en el SLA lo que no se mide.

2) «Nueve» y las matemáticas de la accesibilidad

Composición de disponibilidad

Cadena secuencial (dependencias por «ruta roja»): 'A _ total = Π A_i' (cada componente reduce el total).
Activos activos paralelos nodos: 'A _ total = 1 − Π (1 − A_i)' (la reserva aumenta el total).

3) Qué medir exactamente (SLI correcto)

Vista personalizada: completar con éxito las operaciones clave (login, depósito, check out) y su latencia p99.
Pasillo de una hora: agregue por ventanas deslizantes (5/30/60 min) y por regiones.
Excepciones: las «ventanas programadas» se contabilizan en SLO y en SLA sólo si así lo dice el contrato.

• Disponibilidad: porcentaje de respuestas exitosas ≤ T.
• Calidad: p95/p99 latency.
• Compuesto: «porcentaje de depósitos exitosos ≤ 5 c».

4) Error Budget y velocidad de combustión

Error Budget = `1 − SLO`. Para 99. El 95% de la ventana mensual da 0. 05% de errores/inactividad.
Burn-rate: tasa de gasto del presupuesto (por ejemplo, 4 × significa que en 6 horas se come el límite diario).
Política: en la combustión rápida - stop releases, enfoque en la estabilización, feature-freeze.

5) Arquitectura HA: del nodo a la región

5. 1 Nodo/servicio

N + 1: mínimo de una réplica redundante (Deployment ≥ 2, PDB, anti-affinity).
Aislamiento de recursos: límites de CPU/RAM/IO, prioridades (PriorityClass).
Graceful shutdown/drain: no hay rotura de solicitudes durante el restart.

5. 2 Zona/Región

Multi-AZ: réplicas en diferentes zonas, equilibrio de zona cruzada, alimentación/red independiente.
Multi-región: activo-activo (más difícil: datos/consistencia) o activo-pasivo (más fácil: RPO por encima).
Datos: CP para dinero/pedidos (quórum/RAFT), EC/AP para cachés/escaparates.

5. 3 Capa de red y perímetro

L7-LB с health-checks, retry/timeout/circuit-breaking.
GSLB/DNS/Anycast para el tráfico global, TTL cortos.
Control egress y canales tolerantes a fallas a proveedores/PSP externos.

6) Degradación en lugar de caída

Feature kill-switch (banderas de ficha): apague el no crítico, guarde el «camino rojo».
Cambiar a rutas simplificadas: sincrono → asinchron/cola, «aceptado en el procesamiento».
Rate-limit/cupos: es mejor limitar el tráfico que dañar a todos.
Modos Stale: dar caché/datos estáticos cuando el origen no está disponible.

7) Administración de dependencias

Mapa de dependencia (service map): directo/transitivo, crítico, SLO de cada uno.
Enlaces vulnerables: proveedor externo sin SLA: envuelve la caché/cola/duplicado.
Aislamiento de Bulkhead: diferentes grupos de conexiones/cuotas para rutas lentas.
Timeouts> Retries: tiempos cortos, un máximo de 1 retroceso para operaciones idempotentes.

8) Operaciones y cambios

Gestión de cambios: lanzamientos a través de canarios/blue-green, gates SLO, retroceso automático.
Ventanas programadas: estandarizar - longitud, frecuencia, comunicaciones.
Incidentes: roles (IC/Comms/Tech/DB), runbook 'y, post mortem con acciones correctivas.
Eventos de seguridad: cuando se compromete, el «modo pánico» (sólo lectura/tokens/rotación/bloqueo).

9) Observabilidad y alerting

Modelo rojo (Tasa, Errores, Duración) para cada ruta.
SLI-dashboards: disponibilidad/latencia por región y por segmento de clientes.
alertas burn-rate: rápido (1h, 14. 4 ×), lento (6h, 2 ×) - señal antes de la interrupción de SLO.
Instancias (Exemplars): permite pasar de métricas a rutas de trace_id.
Sintética: muestras de puntos externos (perímetro, flow de pago).

10) Pruebas de tolerancia a fallas

Días de juego: escenarios de desactivación de AZ/regiones, degradación de BD/caché, fallo de proveedores externos.
Herramientas Chaos: folios de red (latency/loss), kill-pods, sobrecorriente CPU/IO.
DR-drills: procesamiento de RTO/RPO para sistemas Tier-0 (consulte «Backups and DR»).

11) Diseño de SLA

Definición de «disponibilidad»: lo que se considera un incidente (5xx, tiempo> T, errores de dominio).
Ventana de cálculo: mes/trimestre; incluir/excluir trabajos programados.
Créditos/multas: escala (por ejemplo, 99. 9–99. 99% - X%, por debajo - Y%).
Responsabilidades del cliente: integración, retraídas dentro de límites razonables, límites.
Notificaciones y procedimiento de climas: plazos, formato, base de pruebas (registros/métricas).
Fuerza mayor: formulación jurídica y límites.

• "Disponibilidad de API por SLI "exitosos ≤ 500 ms" no inferior a 99. 95% en un mes calendario. Se excluyen las ventanas programadas (hasta 60 min/mes declaradas con 48 h). A las 99. 90–99. 95% - crédito 5%; 99. 80–99. 90% — 10%; <99. 80% — 25%.»

12) La economía de la novena

• Tier-0 (dinero/pedidos): 99. 95–99. 99%, multi-AZ, DR listo.
• Tier-1 (fiches principales): 99. 9–99. 95%, multi-AZ.
• Tier-2 (no crítico): 99. 5–99. 9%, se permite la degradación/parada en incidentes.

13) Patrones HA por capas

Perímetro: CDN/edge, multi-CDN o GSLB, WAF, rate-limit.
Equilibrio: L7 con outlier-ejection, temporizadores/retras, sticky/consistent-hash.
Aplicaciones: skale horizontal, readiness/liveness, PDB, topology spread.
Datos: leader + replicas, quorum para CP, caché L2, idempotency, PITR.
Colas: duplicación/multiclaster, dedoup, DLQ.
Secretos/confites: GitOps, snapshots atómicos, rollback.

14) Anti-patrones

SLA sin herramientas de medición y sintéticos externos.
Zona única/clúster como SPOF.
Retrés incontrolables → «uno mismo-DDoS».
Transacciones largas/mutex en la ruta caliente.
Migraciones/lanzamientos «duros» sin canarios y un plan de retroceso.
Falta de runbook y comunicación con los stakeholders en el incidente.

15) Lista de verificación de implementación (0-60 días)

0-15 días

Definir SLIs personalizados críticos, especificar SLOs por niveles de Tier-0/1/2.
Incluir alertas burn-rate, SLO-dashboards, verificaciones perimetrales sintéticas.
Eliminar SPOF: ≥2 réplicas, PDB, multi-AZ para frentes y BD críticos.

16-40 días

Introduce los lanzamientos canarios con juego de SLO y auto-descarga.
Mapa de dependencias + cuotas/grupos/temporizadores/SV en cada «ruta roja».
Reglamento de ventanas y comunicaciones programadas, patrones de mensajes de incidentes.

41-60 días

Día de juego: desconexión de AZ, fallo del proveedor externo, «bourst» de tráfico.
Recuento de SLA y préstamos de hecho, publicación de informes a los clientes.
Revisión del «costo ↔ nueve» y de la encrucijada por tiro.

16) Métricas de madurez

≥ 95% de las rutas críticas tienen alertas SLI/SLO y burn-rate.
Los errores de SLO se acompañan de la congelación automática de lanzamientos (política).
Cobertura multi-AZ Tier-0 = 100%, DR-drills exitosos ≥ 1/trimestre.
Tiempo de «detección → mitigación» p50 <5 min, p95 <15 min.
Correlación «liberación ↔ incidentes»: se mantiene y se reduce (rollback rate↓).
Informe público de incidentes/préstamos - dentro de N días hábiles.

17) Ejemplos y pinceladas

• Rápido: "SLO 99. 95%, ventana 1 h, burn ≥ 14. 4× → page on-call».
• Lento: «ventana 6 h, burn ≥ 2 × → ticket & monitoreo».

yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus

SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18) Conclusión

High Availability no es sólo clústeres y réplicas, sino un conjunto coherente de arquitectura, procesos y métricas: SLI/SLO claros, SLA realistas, «nueve» con economía, degradación en lugar de caída, disciplina de timeout/cupos, lanzamientos canarios, ejercicios regulares y transparentes comunicación. Haga que la disponibilidad sea medible y manejable, y se convertirá en una ventaja competitiva, no en una lotería.