Detectar los problemas antes que los clientes

← Todos los proyectos
CASO 03

OBSERVABILIDAD · OPERACIONES · AUTOMATIZACIÓN

24/7equipo de guardia

Cuando me incorporé en 2000, había unos pocos servidores y scripts que analizaban logs. Ese enfoque no podía seguir el ritmo del crecimiento ni de la complejidad.

Reto

Sustituir el análisis reactivo de logs por una monitorización escalable que detectara problemas antes de que los usuarios los comunicaran.

Enfoque

Empezar con Nagios y Zabbix, añadir comprobaciones y avisos y registrar métricas para analizar tendencias.

Resultado

Una práctica que evolucionó con el tiempo, incorporando después Grafana y Checkmk para combinar alertas tempranas y visibilidad a largo plazo.

Lea el estudio de caso

Un entorno pequeño con puntos ciegos crecientes. Al principio solo había unos pocos servidores y scripts de análisis de logs. Con el crecimiento, el enfoque dejó de escalar y de representar la complejidad. Además, era reactivo: mostraba lo que ya había ocurrido.

El jefe y el cliente no son herramientas de monitorización. ¿Por qué descubrir un problema cuando ya ha sucedido? Si un responsable o un cliente es el primero en comunicar una caída, operaciones ya llega tarde. Además del incidente, queda en riesgo la confianza en el trabajo del equipo, dentro y fuera de la organización.

El clásico: un certificado TLS a punto de caducar. En 2000 no existían de la misma forma las opciones actuales de renovación automática. Let’s Encrypt llegó mucho después, en 2015. Necesitábamos vigilar la caducidad antes de descubrirla mediante una conexión fallida. Los requisitos y emisores pueden variar; incluso la renovación automatizada necesita supervisión.

Detectar, avisar y conservar datos. Nuestras primeras opciones fueron Nagios y Zabbix. Hacían falta comprobaciones y avisos que llegaran a alguien capaz de actuar. Los avisos se dirigían especialmente al equipo de guardia 24/7 para atender incidentes a cualquier hora. Por motivos de coste, la web todavía no tenía una arquitectura de alta disponibilidad. La detección fiable y la respuesta rápida eran esenciales para mantener la mejor calidad de servicio posible; la monitorización no eliminaba por sí sola el riesgo de interrupciones. Con los años, los canales incluyeron SMS, WhatsApp y PagerDuty; no significa que todos se utilizaran ya en 2000.

Del incidente a la tendencia. Registrar métricas permitía estudiar cómo evolucionaban carga, latencia y capacidad, más allá de una alarma aislada. Después se añadieron Grafana y Checkmk. El objetivo seguía siendo detectar antes el deterioro y entender hacia dónde se dirigían los sistemas.

El principio que permanece. La monitorización es más que una colección de paneles: debe dar al equipo la oportunidad de actuar antes de que otra persona tenga que señalar el problema.

Fuente histórica: anuncio del primer certificado público de Let’s Encrypt (2015).

Desliza o usa las teclas de flecha · Esc se cierra