Saltar al contenido
Todos los artículos

Monitorizar resultados de negocio: paneles en verde, caja vacía

Todo equipo de plataforma conoce el momento: CPU al 30 %, ningún error en los logs, todos los paneles en verde, y hace dos horas que ningún cliente puede pagar. La monitorización clásica vigila las máquinas. Lo que el negocio necesita saber es si la gente puede hacer aquello para lo que ha venido: reservar, pagar, registrarse. Así monto una monitorización que vigila resultados, detecta los problemas desde fuera antes de que los clientes avisen y se mantiene lo bastante tranquila como para que la gente siga leyendo las alertas.

10 min de lectura

1. Vigilar síntomas, no máquinas

El libro de SRE de Google organiza la monitorización en torno a dos preguntas: qué está roto y por qué. El "qué" es un síntoma que nota el usuario: una página que no carga, un pago que falla, una reserva que nunca llega. El "por qué" es una causa: un disco lleno, una consulta lenta, un certificado caducado. Los síntomas merecen alertas porque siempre importan; las causas van en los paneles, donde miras cuando salta un síntoma.

El proyecto Prometheus da el mismo consejo: alertar por síntomas, mantener las alertas sencillas y evitar avisos en los que no hay nada que hacer. Una alerta de CPU a las 3 de la madrugada por una máquina ocupada que atiende a todos los clientes es lo contrario, y enseña a la gente a ignorar el busca.

2. Nombrar los recorridos y ponerles objetivos

Empieza por tres a cinco recorridos que sostienen el negocio y describe cada uno desde el lado del cliente: buscar y reservar una estancia, pagar, recibir la confirmación, apuntarse a un curso. Para cada uno elige un indicador que diga si ha funcionado, como la proporción de reservas iniciadas que se completan o la de pagos con éxito, y acuerda un objetivo con el responsable de negocio.

Un objetivo del 99,5 % de reservas con éxito al día define también un presupuesto de errores: el 0,5 % que puedes perder antes de que el negocio se resienta. El libro de SRE usa ese presupuesto para equilibrar el trabajo de fiabilidad con las funciones nuevas. En la práctica da a cada alerta un umbral claro, y a cada discusión sobre una release, una cifra.

Monitorización de resultados: comprobar desde fuera, comparar con la fuente de verdad, alertar por recorridos, un issue tranquilo por incidencia.
Monitorización de resultados de negocio: desde fuera se ejecutan checks sintéticos cada 10 minutos, un recorrido por el embudo de reservas cada hora y un pago de prueba diario; dentro de la plataforma Kubernetes, las métricas de la aplicación, los eventos de negocio y los watchdogs contra la fuente de verdad alimentan Prometheus y Loki; Grafana muestra los SLO por recorrido de cliente, Alertmanager alerta por síntomas y consumo del presupuesto de errores, abre un issue de GitHub deduplicado por incidencia y avisa en el chat del equipo con enlace al runbook.

3. Comprobar desde fuera, como un cliente

Las métricas de dentro de la plataforma no ven un registro DNS roto, un certificado caducado o un CDN que sirve una página antigua. Los checks sintéticos sí: pequeños scripts que se ejecutan desde fuera y hacen lo que haría un cliente. En una plataforma que opero, comprueban las páginas vitales cada 10 minutos, recorren el embudo de reservas cada hora y hacen un pago de prueba real cada día. Cuando el proveedor del sistema del hostel cambió su API sin avisar, las sondas lo detectaron y las estancias volvieron a ser reservables el mismo día.

Esta web tiene lo mismo en pequeño: un workflow programado pide cada hora las páginas principales, cada artículo, la guía de IA, cada guía en PDF, el sitemap y el enlace de reserva, y un fallo acaba en mi bandeja de entrada.

yaml
# GitHub Actions: a synthetic check that fails (and emails the owner) when a vital page breaks
on:
  schedule:
    - cron: "*/10 * * * *"
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - run: |
          for path in / /book /checkout; do
            code=$(curl -s -o /dev/null -L --max-time 20 -w '%{http_code}' "https://www.example.com$path")
            [ "$code" = "200" ] || { echo "FAIL $path -> $code"; exit 1; }
          done

Consejo práctico

Da a los checks sintéticos su propio cliente de prueba y marca sus reservas y pagos, para que nunca aparezcan en los informes de ingresos ni confundan al equipo.

4. Watchdogs contra la fuente de verdad

Algunos fallos solo aparecen cuando dos sistemas no coinciden. Un cliente ha pagado, pero no existe la reserva. La web ha tenido visitas toda la mañana, pero ni una sola reserva. Llegó un webhook, pero el pedido nunca cambió de estado. Cada uno de estos casos es una consulta corta contra la base de datos o el proveedor de pagos, ejecutada cada pocos minutos, que siempre debería devolver vacío.

Estos watchdogs son las comprobaciones más valiosas que conozco, porque detectan justo los fallos que se escapan a las métricas técnicas: todo fue rápido y devolvió 200, y aun así el resultado era incorrecto. Exporta el resultado como métrica para que alerte como todo lo demás.

sql
-- Paid, but no reservation after 15 minutes: should always be empty
SELECT p.id, p.amount, p.created_at
FROM payments p
LEFT JOIN reservations r ON r.payment_id = p.id
WHERE p.status = 'succeeded'
  AND r.id IS NULL
  AND p.created_at < now() - interval '15 minutes';

5. Alertar por el objetivo, no por cada parpadeo

Convierte los indicadores de los recorridos en recording rules de Prometheus y alerta cuando caen por debajo del objetivo el tiempo suficiente para importar. Una condición de tráfico mínimo evita alertas de noche, cuando dos reservas fallidas de tres parecen un desastre. Cada alerta lleva un resumen en palabras claras y un enlace al runbook que dice qué mirar primero.

En la plataforma mencionada arriba, Prometheus, Grafana, Loki y Alertmanager ejecutan 143 reglas de alerta en Kubernetes. Parece mucho, pero la mayoría alimentan paneles y tickets; solo las ligadas a recorridos de cliente despiertan a una persona.

yaml
groups:
  - name: booking-slo
    rules:
      - record: booking:success_ratio:rate1h
        expr: |
          sum(rate(bookings_completed_total[1h]))
            / sum(rate(bookings_started_total[1h]))
      - alert: BookingSuccessBelowObjective
        expr: |
          booking:success_ratio:rate1h < 0.995
            and sum(rate(bookings_started_total[1h])) * 3600 > 20   # enough traffic to judge
        for: 15m
        labels:
          severity: page
        annotations:
          summary: "Fewer than 99.5% of started bookings complete"
          runbook_url: "https://runbooks.example.com/booking-success"

6. Mantenerlo lo bastante tranquilo para que se lea

Un sistema de alertas muere de ruido mucho antes que por falta de cobertura. Lo que me funciona: un issue de GitHub por incidencia, abierto automáticamente cuando falla un check y cerrado automáticamente cuando se recupera, deduplicado para que un check intermitente actualice el mismo issue en vez de abrir veinte, y límites por hora para que una tormenta no inunde el chat del equipo. El issue se convierte de paso en el registro del incidente, con marcas de tiempo.

Revisa las alertas una vez al mes. Cada alerta que saltó sin que nadie tuviera que actuar es candidata a borrarse, pasar a un panel o ajustarse. El objetivo es que cada aviso signifique algo.

7. Que cada release se demuestre a sí misma

El incidente más barato es el que detiene una barrera de release. Dos barreras hacen la mayor parte del trabajo: las migraciones de base de datos se ejecutan en seco contra una copia antes de que un cambio pueda fusionarse, y un smoke test corre justo después de cada despliegue y lo marca en rojo si se rompe una ruta vital. Las dos reutilizan las mismas comprobaciones que la monitorización, así que una página de reservas rota hace fallar la release antes de que la vea ningún cliente.

La checklist de abajo cubre estos básicos, desde backups que se han restaurado de verdad hasta checks de negocio que avisan a una persona. Cada hueco que muestre es un sitio donde tus paneles pueden seguir en verde mientras el negocio no lo está.

Interactivo

¿Tu app hecha con IA está lista para producción?

Marca lo que ya se cumple. Lo que queda es tu lista de tareas, en orden.

0/12 listo

Tus tres próximos pasos

  1. El código vive en Git; los cambios pasan por pull requests
  2. Ninguna clave secreta en el frontend; las del servidor, solo en el servidor
  3. Seguridad a nivel de fila (o equivalente) en cada tabla
Pedir una revisión de preparación
Todas las calculadoras y checklists

Conclusión

Vigila lo que hacen los clientes, desde fuera y contra la fuente de verdad, alerta solo por los recorridos que generan dinero y mantenlo lo bastante tranquilo para que cada aviso signifique algo.

Más artículos

    Hablemos

    Cuéntame qué estás construyendo; te respondo en 1 o 2 días laborables.

    Dominik Heinrich
    Empresa
    MADO Consulting

    Disponible en todo el mundo en remoto. Presencial bajo petición, según el país.

    Te respondo en 1 o 2 días laborables. Huecos libres: mira el calendario

    Abre aquí el calendario de reservas de Calendly. Al cargarlo se envían datos a Calendly (ver aviso legal).