Checklist de monitoreo de infraestructura: lo que los equipos mid-market deben cubrir

La mayoría de los equipos de tecnología dice que "ya tienen monitoreo". En la práctica suelen tener un dashboard en la nube, algunas alarmas de CPU y un canal de Slack que se silencia hasta que un cliente se queja. Eso no es una práctica de monitoreo: es deseo con gráficas.

Usa este checklist de monitoreo de infraestructura con el CTO, el tech lead y quien recibe páginas. Marca cada ítem hecho, parcial o faltante. Prefiere faltante sobre "creemos que está cubierto". Resultado objetivo: poder responder qué está caído, a quién despertamos y qué hacer después en menos de cinco minutos para cada sistema crítico. Para contexto primero, ver 7 señales de que necesitas monitoreo 24/7 y observabilidad vs monitoreo.

El checklist

1. Lista todos los entornos de producción — cuentas cloud, regiones, clusters Kubernetes, VMs, bases administradas, edge y dependencias SaaS. Pon la lista en un doc compartido, no en la cabeza de alguien.
2. Asigna un dueño primario y un respaldo por cada sistema crítico (nombres de personas, no "el equipo"). Publícalo junto a los runbooks.
3. Prioriza servicios por impacto de negocio — crítico para ingresos, cara al cliente, solo interno, best-effort — para que el paging coincida con dinero y clientes, no con el hábito.
4. Define "caído" en lenguaje de negocio para los sistemas top (p. ej. checkout falla, línea de planta se detiene, API 5xx por encima de X%). Escríbelo junto a cada servicio para que las alertas mapeen a impacto.
5. Dibuja mapas de dependencias de los journeys top — app → DB → caché → cola → API de terceros — e inclúyelos en los canales de incidente.
6. Instrumenta señales doradas en cada servicio crítico: latencia, tráfico, errores y saturación (CPU, memoria, disco, conexiones, profundidad de cola).
7. Activa métricas de host/nodo — espacio en disco, inodos, presión de memoria, errores de red — con umbrales que disparen antes de que el disco se llene a las 3 a.m.
8. Enciende métricas de servicios administrados para RDS/Aurora, ElastiCache, balanceadores y el control plane de Kubernetes; no asumas que "la nube ya lo vigila por ti".
9. Rastrea headroom de capacidad — no solo "¿está rojo ahora?" sino "¿qué tan cerca del precipicio?". Agenda una revisión semanal de crecimiento vs límites.
10. Construye dashboards de journey que respondan una pregunta (salud del checkout, path de login, pipeline de pedidos). Archiva o borra paneles que nadie abre en un incidente.
11. Envía logs de aplicación estructurados (JSON o equivalente) con IDs de request/correlación para seguir un fallo entre servicios.
12. Centraliza los logs fuera de los hosts que mueren con el incidente; define retención que cubra debug y compliance sin costo en blanco.
13. Redacta secretos y PII antes de que los logs salgan de la app — trata el pipeline de logs como path de datos de producción.
14. Conecta cada alerta crítica a logs relacionados en uno o dos clics; si el debug sigue empezando con arqueología por SSH, arregla primero ese path.
15. Reescribe alertas alrededor de síntomas de usuario/negocio — tasa de error, quema de SLO de latencia, lag de cola — no solo CPU. Degrada o elimina umbrales vanidosos.
16. Dale a cada alerta que pagina severidad, dueño y URL de runbook. Si una alerta no tiene nada de eso, es ruido hasta que lo añadas.
17. Mide el ruido de alertas semanalmente — páginas por semana, falsos positivos, alertas sin dueño — y mata o arregla a los peores ofensores.
18. Suprime flapping y duplicados; agrupa disparos relacionados para que un outage sea una conversación.
19. Agrega monitores para fallos silenciosos — vencimiento de certificados, disco lleno, job de backup fallido, crons que nunca corrieron, deployments trabados.
20. Escribe SLOs para tus 1–3 journeys de cliente top (disponibilidad o latencia). Manténlos cortos para que el liderazgo pueda financiarlos. Ver ingeniería de confiabilidad en la nube vs DevOps.
21. Define una respuesta de error budget — aunque sea informal: qué dejas de shippear cuando la quema es alta — y pon alertas de quema de SLO junto a umbrales crudos.
22. Revisa resultados de SLO mensualmente junto a tickets cerrados; trata la quema como planificación de capacidad, no como utilería de postmortem.
23. Agrega checks sintéticos outside-in para URLs/APIs críticas desde fuera de la VPC (y rutas multi-AZ/región, no solo un health endpoint que siempre responde 200).
24. Monitorea vencimiento de TLS y DNS; pagina antes de que lo hagan browsers y clientes.
25. Vigila dependencias de terceros — pagos, auth, email, webhooks — con visibilidad de fallo y un path claro de "¿somos nosotros o ellos?".
26. Monta una rotación on-call para sistemas críticos de negocio (horario laboral con escalamiento fuera de horario está bien) y escribe la ruta: primario → secundario → manager.
27. Documenta runbooks de los incidentes recurrentes top — restart, failover, rollback, drenar cola — y enlázalos desde las alertas que deben dispararlos.
28. Corre un post-incidente por cada evento con impacto al cliente; rastrea acciones a hecho con dueños y fechas.
29. Prepara plantillas de comunicación a stakeholders (status page / Slack / email) para que ingeniería no redacte en medio del fuego.
30. Agenda backups y fecha tu última prueba de restore; un backup sin verificar es especulación. Conoce RPO/RTO de los datastores más críticos.
31. Alerta por éxito/fallo del job de backup, no solo porque "el proceso de la base está up".
32. Haz auditables los cambios de config e IaC para que "qué cambió?" sea respondible en los primeros diez minutos de un incidente.
33. Asigna un dueño del costo de monitoreo y revisa cardinalidad, retención y dashboards sin uso en una cadencia fija.
34. Aplica least privilege en herramientas de monitoreo; audita quién puede cambiar alertas y dashboards de producción.
35. Versiona y parchea agentes/exporters como cualquier dependencia de producción; saca clones de staging y proyectos abandonados del paging de producción.

Califica tu cobertura

Imprime esta tabla (o cópiala) y marca cada fila. Si tres o más filas están en Faltante, arregla inventario, alertas-con-runbook y checks outside-in antes de comprar otra herramienta.

Compra herramientas al final. Primero: completa el inventario, reescribe páginas para que cada alerta tenga runbook y agrega checks outside-in. Pon una revisión mensual de ops en el calendario. Si no tienes capacidad para operar esto de forma continua, usa un retainer mensual que incluya monitoreo de infraestructura en lugar de esperar ciclos libres.

Un checklist real es evidencia de que sabes qué importa, puedes detectar fallos temprano y responder con ownership—no una factura de software más larga.