El incidente en GitHub fue causado por la acumulación de reglas de mitigación de incidentes temporales que no fueron debidamente gestionadas en su ciclo de vida. Estas reglas, diseñadas para combatir el abuso en momentos de emergencia, se basaban en patrones de tráfico que, con el tiempo, comenzaron a coincidir con el comportamiento de usuarios legítimos, especialmente aquellos que no habían iniciado sesión. La falta de un proceso formal para revisar, expirar o adaptar estas mitigaciones llevó a un "configuration drift" silencioso, donde las defensas se volvieron obsoletas y contraproducentes.
La cascada de fallo no fue un colapso del sistema, sino una degradación persistente de la experiencia del usuario para un subconjunto de clientes. Las salvaguardas existentes, como los sistemas de alerta, no detectaron este problema porque el impacto individual era pequeño y el porcentaje de falsos positivos era bajo en relación con el tráfico total. Sin embargo, para los usuarios afectados, el bloqueo era del 100% cuando sus solicitudes coincidían con los criterios obsoletos. La complejidad de la infraestructura de protección multicapa de GitHub, que utiliza herramientas como HAProxy, dificultó la trazabilidad de la causa raíz, requiriendo correlación manual de logs de múltiples sistemas con diferentes esquemas.
Este incidente subraya la importancia crítica de la observabilidad no solo para las características del producto, sino también para los sistemas de defensa. La ausencia de un monitoreo específico sobre la efectividad y los efectos secundarios de las reglas de mitigación, junto con la falta de un "lifecycle management" explícito para estas, permitió que el problema persistiera. La lección principal es que las soluciones de emergencia, aunque necesarias, deben ser tratadas como deuda técnica que requiere una resolución planificada y una gestión activa para evitar que se conviertan en problemas a largo plazo que impacten la disponibilidad y la experiencia del usuario.