¿Su equipo de ingeniería está experimentando fatiga de alerta? Haz estas 8 preguntas

La fatiga por alertas es un problema común entre los equipos de ingeniería que manejan las operaciones y mantienen la infraestructura.

El problema generalmente surge de un enfoque desordenado para escribir alertas a medida que los equipos crecen y comienzan a usar más infraestructura de complejidad creciente. Esto es bastante normal: a medida que crece una empresa o un equipo, a menudo se necesita tiempo para que se forme una cultura de observación y prácticas sólidas de alerta.

Es fácil crear alertas demasiado sensibles, demasiado ruidosas y demasiado cautelosas. Al principio, todo parece digno de alerta simplemente porque es mejor tener cuidado y maximizar la señal de producción en las primeras etapas de un producto.

“A medida que crece el número y la complejidad de las funciones y la infraestructura, la mejora de las alertas suele estar muy abajo en la lista de prioridades”

Naturalmente, este enfoque no escala muy bien, pero a medida que crece la cantidad y la complejidad de las funciones y la infraestructura, la mejora de las alertas suele estar muy abajo en la lista de prioridades. El resultado es una gran cantidad de alertas semisignificativas, ruido, cambio de contexto y multitarea para el ingeniero de guardia. En casos extremos, los compañeros de equipo se agotan, las alertas se ignoran y su equipo de guardia pasa de mejorar la calidad del servicio a combatir incendios constantemente sin un impacto significativo.

Como todas las empresas, Intercom no es inmune a estas ineficiencias. Así que ideamos un proceso relativamente ligero para combatir la fatiga de alerta.

Cómo pensamos en la estrategia de alertas

El concepto de "disciplina de alerta" es fundamental para controlar las alertas. Al igual que el trabajo de funciones, las alertas y la estrategia de alertas deben abordarse de manera deliberada y estructurada. Sin embargo, a diferencia del trabajo de características, no es algo que pueda planificarse bien con anticipación.

Después de todo, es muy poco probable que pueda predecir el estado operativo y el ruido de su nueva función antes de enviarla. Debe monitorear las alertas de manera regular y planificada para que el trabajo de alerta no alcance niveles insostenibles.

8 preguntas que debe hacerse al evaluar las alertas de su equipo

Presentamos sesiones periódicas de revisión de alertas para equipos que se ocupan de alertas frecuentes. Inicialmente, se llevaron a cabo una o varias veces por ciclo de ingeniería de seis semanas, pero se fueron espaciando a medida que el estado de las alertas y los monitores mejoraba a un nivel más manejable.

Cada sesión de revisión de alertas comienza con una lista ordenada de alertas que se activaron en el período anterior, ordenadas por frecuencia de activación. Usamos la plataforma PagerDuty como nuestra fuente de alertas, y sus funciones de análisis nos brindan la información que necesitamos para desglosar la frecuencia y la respuesta de las alertas. Las alertas que más contribuyen al ruido general (es decir, los incendios más frecuentes) se revisan primero.

Luego, cada alerta se pasa a través de una lista de verificación de preguntas:

1. ¿Sigue siendo relevante la alerta?

Cualquier alerta activada por sistemas obsoletos o sin mantenimiento no debería molestar al ingeniero de guardia y debería eliminarse de inmediato.

2. ¿Se puede accionar la alerta?

Si un ingeniero de guardia recibe la alerta, ¿puede hacer algo ahora mismo para solucionar o mejorar la causa subyacente? Si la alerta no es procesable y útil, debe eliminarse. Un resumen semanal de problemas o degradaciones de rendimiento podría ser un mejor lugar para la información dentro de la alerta.

3. ¿La información de la alerta es inmediatamente útil incluso si no se puede tomar ninguna medida?

Podemos dividir la información de alerta en dos grandes categorías.

• Señales: estas alertas advierten de un sistema que está funcionando al límite, pero no necesariamente significan que el servicio se está viendo afectado. Un ejemplo sería uno de sus servidores funcionando al 100% de la CPU. Si el servicio sigue funcionando bien, ¿deberían los guardias dedicar un tiempo valioso a investigar? ¡Después de todo, su servidor está funcionando con la mejor relación costo-trabajo!
• Síntomas: estas alertas se activan cuando la experiencia del cliente se ve afectada. Un ejemplo aquí sería la cantidad de errores HTTP 5XX que su servicio está devolviendo a las personas que llaman.

Estas dos categorías funcionan mejor juntas. Una persona de guardia debe reaccionar y solucionar los síntomas, y considerar las señales solo como una fuente adicional de información.

4. Si la alerta es procesable y buscapersonas, ¿debe tratarse de inmediato?

Si no es necesario manejar el problema de inmediato, no debería despertar a nadie en medio de la noche. El equipo debe decidir formas alternativas de mostrar la información en la alerta en estas situaciones, por ejemplo, una notificación de Slack o del tablero, o una tarea abierta en un mecanismo de seguimiento de problemas.

5. Si es procesable, ¿hay un runbook o un enlace de solución de problemas? ¿Son los pasos lo suficientemente claros para ser seguidos por cualquier ingeniero del equipo?

Una de las peores experiencias de ser un ingeniero de guardia, especialmente uno nuevo, es la cantidad de conocimiento tribal que se acumula en los equipos de ingeniería con el tiempo. Es intimidante saltar sobre un incidente de producción de alta gravedad solo para darse cuenta de que no está familiarizado con esa área del sistema y no está bien documentada.

“ Mantener la información de solución de problemas de alerta clara, simple y actualizada contribuye en gran medida a reducir el tiempo medio para mitigar y recuperarse de un incidente ”

Incluso si tiene la experiencia, es posible que haya escrito el código hace tanto tiempo que no recuerda claramente lo que se supone que debe hacer. Mantener la información de solución de problemas de alerta clara, simple y actualizada contribuye en gran medida a reducir el tiempo medio para mitigar y recuperarse de un incidente (MTTM y MTTR).

6. Si es procesable, ¿hay un enlace en el tablero y muestra todas las posibles causas conocidas?

Los tableros son una excelente manera de mostrar grandes cantidades de información del sistema a la vez, lo que significa que los ingenieros no tienen que profundizar en varios registros, métricas y seguimientos para descubrir la causa de un problema. Agregar datos en un tablero y proporcionar el enlace como parte de la alerta permite una resolución de problemas mucho más rápida.

7. ¿La alerta es demasiado sensible o no es lo suficientemente específica? ¿Se beneficiaría de la desensibilización o el cambio de alcance?

Muchas alertas son útiles pero mal calibradas. Pueden ser demasiado amplios y no disparar cada vez que deberían, o demasiado específicos y disparar varias veces por el mismo incidente, lo que solo aumenta el ruido.

8. Finalmente, ¿tiene que hacer la remediación un ser humano?

En cierto modo, todo el código de computadora automatiza algo que un ser humano puede hacer. Entonces, ¿por qué no automatizar la corrección de los problemas que activan las alertas? Si bien ciertas alertas más espinosas serían difíciles de solucionar automáticamente, como un error en el código o un problema de rendimiento en el sistema, las acciones automatizadas pueden resolver muchos problemas comunes.

Esto es especialmente cierto si se ejecuta en una plataforma en la nube como AWS y puede aprovisionar infraestructura sin tener que preocuparse por solicitar hardware adicional. Por ejemplo, si un nodo en su clúster de búsqueda muestra discos defectuosos, ¿por qué no reemplazarlo automáticamente? Si el servicio tiene pocos recursos informáticos debido al aumento del tráfico, ¿por qué no escalar y agregar máquinas virtuales o contenedores adicionales? Los detalles de la remediación se pueden enviar al equipo a través de canales que no son de alerta para que puedan revisar en su tiempo libre.

¿Ha respondido “no” a alguna de estas preguntas?

Responder no a cualquiera de estas preguntas plantea una tarea de alta prioridad para que el equipo trabaje para mejorar la alerta, ya sea que eso signifique detener la paginación, mejorar los pasos de solución de problemas, automatizarla o simplemente solucionar el problema subyacente del sistema.

El quid del enfoque es hacer esto de manera regular y planificada. Mantiene los niveles de ruido bajos y sus operaciones e ingenieros de guardia felices y productivos. Pueden enfocarse en mejorar la calidad y generar impacto en lugar de apagar incendios.

¿Está interesado en la forma en que trabajamos en Intercom? Nos encantaría hablar con usted: consulte nuestros puestos abiertos de ingeniería.