DevOps y cloud
Monitoreo: alertas que alguien sí atiende
Diseño de observabilidad para equipos sin NOC 24/7: señales ligadas a impacto de negocio, runbooks, dueños y anti-fatiga de alertas.
11 min de lectura · Actualizado 2026-07-22
El problema no es falta de datos, es exceso de ruido
Instalar Prometheus, Grafana y 400 métricas sin curación produce alertas que el equipo silencia en Slack la segunda semana. Monitoreo útil empieza por «¿qué dolor siente el usuario?» no por «¿qué podemos graficar?».
Fatiga de alertas es riesgo de seguridad: cuando todo es rojo, el incidente real pasa desapercibido hasta que un cliente llama furioso.
Regla: cada alerta debe tener dueño nominativo, runbook de 5 pasos mínimo y severidad (P1–P4) acordada. Si no hay runbook, no es alerta — es log.
Empieza con 5–10 señales críticas bien atendidas antes de expandir cobertura.
Señales que importan por capa
Edge/usuario: uptime sintético externo, TTFB p95, tasa 5xx en URL checkout/login, certificado SSL días restantes, expiración dominio.
Aplicación: errores no capturados, latencia API p95, profundidad cola Redis/Rabbit, jobs fallidos consecutivos, disk usage uploads.
Infraestructura: host down, disco > 85 %, OOM kills, réplica DB lag > umbral, backup job failed.
Negocio (si puedes): pedidos/hora vs baseline, webhooks pagos fallidos. Una caída silenciosa de integración ERP a veces no sube CPU.
Routing, escalamiento y horarios
P1 (sitio caído, datos en riesgo): llamada + Whatsapp inmediato a ingeniero on-call, respuesta < 15 min. P2 (degradación): Slack + ticket, respuesta < 1 h laborable.
Horario laboral vs 24/7: define explícitamente qué tiene cobertura nocturna (e-commerce transaccional sí; blog corporativo quizá P3 al día siguiente).
Escalamiento automático si no ack en 10 min. Rotación semanal on-call documentada — no «el que esté despierto».
Integra alertas con PagerDuty, Opsgenie o canal Whatsapp técnico con mensaje accionable: qué falló, enlace dashboard, primer paso runbook.
Runbooks y post-mortems sin culpa
Runbook ejemplo «5xx > 5 %»: 1) Verificar último deploy, 2) Rollback si < 15 min del deploy, 3) Revisar logs app y DB connections, 4) Escalar a senior si persiste 30 min, 5) Comunicar status interno.
Post-mortem blameless en 48 h: timeline UTC, root cause técnico, contributing factors, action items con dueño y fecha. Compartir resumen con gerencia en lenguaje de impacto negocio.
Trend de MTTR (mean time to repair) mensual — objetivo bajar, no solo contar incidentes.
Web Checker 360 como check manual semanal complementario: detecta regresiones SSL/cabeceras que métricas internas no ven.
Stack mínimo viable y evolución
Tier 0 (gratis/barato): UptimeRobot sintético + alertas certificado + log aggregation básico (Loki, Cloudflare analytics) + cron que verifica backup exitoso.
Tier 1: Prometheus node_exporter + alertmanager, Grafana dashboards por servicio, Sentry para errores app, uptime interno healthchecks.
Tier 2: APM (OpenTelemetry), tracing distribuido, SLO con error budget, chaos en staging.
Conecta configura monitoreo y on-call para clientes DevOps-as-a-Service: alertas accionables, runbooks documentados y respuesta de ingeniería en incidentes P1/P2.
Ponlo en práctica ahora
Usa las herramientas gratuitas del Toolbox para validar tu configuración en minutos.
¿Necesitas que lo resolvamos contigo?
Un ingeniero de Conecta puede aplicar esto en tu operación: servicio relacionado o conversación directa.