Observability y Reliability Engineering

Una vez que el sistema está en producción aparecen dos preguntas:

¿Podemos saber qué está sucediendo?

¿Podemos demostrar que el sistema cumple sus objetivos?

La primera corresponde principalmente a Observability. La segunda conecta con Reliability Engineering.

Observability

Las tres señales más conocidas son Logs, Metrics y Traces.

Logs

Eventos individuales:

Payment authorization failed
payment_id=123
provider=provider-a
error=timeout

Buenos para investigar: ¿qué sucedió con esta operación?

Metrics

Valores numéricos agregados: payment_requests_total, payment_errors_total, payment_latency_p95, provider_timeout_rate, queue_depth. Permiten observar tendencias.

RED (para servicios)

USE (para recursos)

Distributed Tracing

Una request distribuida atraviesa varios servicios:

sequenceDiagram
  participant Ch as Checkout
  participant O as Order Service
  participant P as Payment Service
  participant Pr as Payment Provider
  Ch->>O: request
  O->>P: request
  P->>Pr: request
  Pr-->>P: response
  P-->>O: response
  O-->>Ch: response

Y puede desglosarse por el tiempo que consume cada salto:

Eso permite ver que el problema no está en Checkout, sino en el provider.

Herramientas conocidas: OpenTelemetry, Jaeger, Grafana Tempo, Datadog, New Relic, AWS X-Ray. OpenTelemetry es particularmente importante porque proporciona APIs y estándares para generar y exportar telemetry de forma vendor-neutral.

Reliability Engineering

Observability mide. Reliability Engineering define objetivos y trabaja para mantenerlos.

SLI — Service Level Indicator

Qué medimos, por ejemplo:

Successful payment requests
--------------------------------
Total payment requests

SLO — Service Level Objective

El objetivo, por ejemplo 99,95%.

SLA — Service Level Agreement

Es un compromiso contractual. No todo SLO necesita convertirse en SLA.

Error budget

Si tenemos un SLO = 99,95%, el error budget es aproximadamente 0,05%. Esto permite equilibrar confiabilidad y velocidad de entrega. Si el equipo consume repetidamente el error budget, puede ser necesario reducir los cambios riesgosos y priorizar la confiabilidad.

Confiabilidad no significa “nunca fallar”

Un sistema confiable también contempla detección, contención, recuperación y prevención. Por eso la confiabilidad conecta directamente con timeout, retry, circuit breaker, redundancia, failover, backups, degradación controlada y observabilidad.

Dominios de fallo

Un error grave es considerar solamente el componente individual. Podemos analizar distintos dominios de fallo: proceso, instancia, zona de disponibilidad, región, dependencia, base de datos y red. Para cada uno conviene preguntarse:

• ¿Qué pasa si falla?
• ¿Podemos detectarlo?
• ¿Podemos recuperarnos?
• ¿Qué tan rápido?
• ¿Cuántos datos podemos perder?

Confiabilidad en Payments

Supongamos un SLO de 99,95% de operaciones de pago exitosas, con el requisito adicional de evitar cargos duplicados. Entonces observamos disponibilidad, latencia, fallos de proveedores, timeouts, intentos duplicados, fallos de webhooks, consumer lag y errores de base de datos.

Un dashboard puede terminar incluyendo: Payment Success Rate, Payment p95, Provider Timeout Rate, Duplicate Request Rate, Webhook Processing Lag y DLQ Messages. Esto conecta el diseño arquitectónico con la realidad operativa.

Herramientas conocidas

Prometheus, Grafana, Datadog, New Relic, OpenTelemetry, Elastic Stack, CloudWatch. La herramienta no es lo importante. El objetivo es poder responder:

¿Qué está pasando, por qué y cuál es el impacto?

Referencias

• Google, Site Reliability Engineering y The Site Reliability Workbook: referencias fundamentales para SLI, SLO, error budgets y prácticas de confiabilidad.
• AWS Well-Architected Framework: fiabilidad y excelencia operativa son dos de sus seis pilares.