Mejoras en la supervisión y las alertas de la autoridad de certificación de Fastly

Esta es la última entrada de una serie de publicaciones en las que hablamos sobre cómo creamos Certainly</u>, la autoridad de certificación (CA) de confianza pública de Fastly. undefinedYa hemos explicado algunas de nuestras decisiones relativas a la arquitectura</u> y los motivos que nos llevaron a optar por un diseño tradicional de base de datos con replicación de nodos primarios</u>. Hoy vamos a hablar de lo que hemos hecho para implementar una supervisión y unas alertas robustas a la par que sostenibles.

Una CA de confianza siempre debe contar con mecanismos de registro y supervisión exhaustivos para detectar rápidamente los fallos en el servicio y las actividades sospechosas dentro del entorno. Esto permite reforzar su integridad y proporcionar a los equipos de operaciones los datos necesarios para responder a los incidentes.

En Fastly siempre hemos procurado ofrecer lo mejor de lo mejor en cuanto a registros y observabilidad en tiempo real</u>, así como integrar datos en tiempo real en otras herramientas, y teníamos claro que debíamos hacer lo mismo cuando nos pusimos manos a la obra con nuestra CA.

La arquitectura de Certainly, hecha a medida y basada en la redundancia, requería registros y métricas de muchos sistemas diferentes, incluidos hosts físicos, dispositivos de red y cámaras. Necesitábamos recopilar toda esta información y unificarla en una señal de alerta que aportara valor. En esta publicación, el término «alerta» hace referencia a un evento que provoca el envío de una notificación push a un ingeniero de guardia para que la atienda de inmediato. Las alertas que hacen ruido sin ofrecer datos relevantes solo sirven para enviar avisos innecesarios, apartar al personal de otras tareas o sus propios asuntos, provocar su desgaste y, en última instancia, empeorar la fiabilidad del servicio. Esta publicación trata sobre las dificultades que plantea la creación de alertas relevantes y lo que hace Certainly para superarlas.

Antes de definir una alerta es necesario reunir registros y métricas con la información necesaria de manera segura. Fastly optó por Splunk (y su integración con PagerDuty) como plataforma de supervisión y por Rsyslog y Telegraf, dos herramientas muy populares de código abierto, para la recopilación de registros y métricas. Una vez que los datos se recogían y aparecían en Splunk, el equipo de Certainly podía crear alertas, investigar los incidentes y generar informes relacionados. 

El punto de partida fue la creación de un conjunto de aproximadamente 60 alertas sobre fallos en el servicio o errores en las herramientas correspondientes. Cuando estas alertas se desplegaron por primera vez, se detectó un número elevado de falsos positivos porque el servicio o el host se estaba reconstruyendo, algo intrínseco al diseño efímero de Certainly. No tardamos en darnos cuenta de que tantos falsos positivos acabarían agotando al personal y afectando a la calidad de la asistencia.  Había que mejorar, así que hicimos varias cosas para solucionar los problemas.

En primer lugar, repasamos las alertas una a una y nos planteamos si realmente eran necesarias. Para ello, nos hicimos preguntas como estas:

• ¿Hace falta una alerta para los fallos en las copias de seguridad si ya hay una para los fallos de restauración?

• ¿Conviene enviar una alerta cuando solo fallan uno o dos servicios redundantes de alta disponibilidad?

Combinamos varias alertas en la medida de lo posible:

• Como las zonas aisladas de nuestro centro de datos siempre están supervisadas mediante numerosos sensores de movimiento, decidimos que solo se debía enviar una alerta cuando se activaban dos de ellos para descartar los falsos positivos causados por vibraciones.

Asimismo, ajustamos los umbrales temporales con el fin de evitar las alertas en situaciones habituales:

• La supervisión de instancias individuales de un servicio durante la revisión de un despliegue o la reconstrucción del host puede provocar muchas alertas durante los procesos del día a día, así que ajustamos los umbrales temporales para tenerlo en cuenta.

Finalmente, desactivamos las alertas temporalmente:

• No tiene sentido enviar alertas sobre accesos no autorizados cuando se está llevando a cabo una inspección presencial,  sobre todo por el trabajo que conlleva evaluarlas y resolverlas.

Una vez concluido este proceso, el número de alertas disminuyó considerablemente y aquellas que se enviaban sí eran relevantes. El equipo empezó a estar más motivado y dejó de mostrar síntomas de desgaste. Además, podía dedicar menos tiempo a prestar asistencia operativa y más a mejorar tanto la fiabilidad del servicio como la infraestructura circundante.

En definitiva, mereció la pena dirigir nuestros esfuerzos a ajustar las alertas. Ahora Certainly es más capaz que nunca de satisfacer las necesidades en cuanto a registros y supervisión de un número cada vez mayor de clientes.