Este artículo no describe un incidente específico, sino que es un post-mortem de un patrón de fallo recurrente en la gestión de incidentes: la ineficacia de los sistemas de alerting tradicionales. La causa raíz subyacente de este problema es un 'human-error' en la filosofía de alerting, donde los ingenieros intentan predecir todas las formas en que un sistema puede fallar y crean alertas de bajo nivel sobre esas causas raíz. Esto lleva a una cascada de problemas: falsos positivos que erosionan la confianza, falsos negativos que retrasan la respuesta, y alertas que se vuelven obsoletas rápidamente debido a cambios en la arquitectura del sistema.
Las salvaguardas tradicionales, como las alertas de CPU o de número de pods, fallan porque no correlacionan bien con la experiencia del usuario. Un contenedor con CPU alta no siempre significa una degradación para el usuario final, y una alerta sobre ello puede ser una distracción. Además, estas alertas son frágiles y requieren un mantenimiento constante de umbrales y selectores, lo que rara vez se hace de manera efectiva en sistemas dinámicos. La 'trampa del post-mortem' agrava el problema al fomentar la creación de más alertas de bajo nivel después de cada incidente, en lugar de abordar la raíz del problema de alerting.
La solución propuesta se centra en la experiencia del usuario. Al definir 'user journeys' y establecer Service Level Indicators (SLIs) y Service Level Objectives (SLOs) sobre ellos, los equipos pueden monitorear directamente lo que importa a los usuarios. El 'burn rate' del error budget se convierte en una métrica poderosa para alertar, ya que indica la velocidad a la que la calidad del servicio se está degradando desde la perspectiva del usuario, sin importar la causa subyacente. Este enfoque es más robusto, menos propenso a falsos positivos y negativos, y se mantiene relevante a pesar de los cambios internos del sistema. Aunque no es una panacea (ej. no detecta botones invisibles), es un avance significativo.