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.
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.
# 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; }
doneConsejo 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.
-- 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.
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.
Tus tres próximos pasos
- El código vive en Git; los cambios pasan por pull requests
- Ninguna clave secreta en el frontend; las del servidor, solo en el servidor
- Seguridad a nivel de fila (o equivalente) en cada tabla
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.
Proyectos reales relacionados
Pruébalo tú mismo
Fuentes y guías oficiales
Más artículos
- 3.025 pull requests en diez meses: un proceso de entrega con IA, desde dentro
- La Ley de IA de la UE para medianas empresas: qué te aplica y desde cuándo
- FinOps para el gasto en IA: tokens, caché, enrutado y presupuestos que aguantan
- Hacer visible una red de restaurantes en las respuestas de la IA: un proyecto GEO paso a paso
- Cómo está hecha esta web: estática donde se puede, en streaming donde hace falta
- Costes de Kubernetes en EKS y GKE: el mismo método, otras palancas
- Una landing zone para empresas medianas, en Terraform o Bicep: las piezas que importan
- El manual de migración de sistemas heredados: oleadas, ejecución en paralelo y recuentos y checksums idénticos
- Seguridad de MCP a fondo: dejar entrar a los asistentes de IA en tu producto sin abrir las puertas
- Agentes de IA por teléfono: la arquitectura y los tropiezos que ninguna demo enseña
- Pruebas de restauración: un backup que nunca has restaurado es solo una esperanza
- Respuestas de IA en streaming en Azure Static Web Apps: la cabecera que lo retenía todo
- Construir un asistente de IA para WhatsApp de principio a fin: lo que hace falta más allá de la demo
- Sistemas air-gapped: software crítico sin conexión a internet
- IA en producción en AWS: Amazon Bedrock y AgentCore en una configuración privada
- IA en producción con Microsoft Foundry: una configuración de referencia privada para agentes
- /goal, /loop o rutinas: deja de vigilar a tu agente de programación
- Los nuevos planes de Claude: Max, Ultra y lo que significan para los equipos
- OpenAI Codex a finales de 2026: goal mode, dots y cómo blindarlo
- ¿GitHub Copilot, Claude Code o Codex? Cómo elegiría para una empresa
- Fundamentos de GEO: cómo aparecer en las respuestas de la IA
- IA en producción en Google Cloud: de Vertex AI a Gemini Enterprise Agent Platform
- LLM locales en una red air-gapped: IA para tus datos más sensibles
- Quiero ejecutar un LLM local: ¿qué servidor compro?
- MiniMax M3: ¿un modelo puntero que puedes ejecutar tú mismo?
- Investigación de prompts a gran escala con un modelo abierto
- SEO y GEO juntos: una auditoría práctica en 6 pasos
- Dimensionar bien Kubernetes: el método que llevó un clúster de 7 a 4 nodos
- IA privada para datos sensibles: un LLM local que supera la revisión de seguridad
- Del prototipo con IA a producción: las ocho capas que añado, en este orden
