El incidente se originó por una comprensión errónea de cómo los límites de CPU de cgroup se aplican en entornos de contenedores. Aunque el monitoreo de CPU average mostraba un uso bajo, el sistema estaba experimentando un throttling severo. Los límites de CPU en cgroups no restringen el número de CPUs a las que un contenedor tiene acceso, sino que asignan un presupuesto de tiempo de CPU por un período de programación (por defecto, 100ms). Una carga de trabajo intensiva y "bursty" podía consumir rápidamente este presupuesto en todos los cores disponibles del host, dejando a otras goroutines sin CPU hasta el siguiente período de programación.
Las salvaguardas tradicionales, como los dashboards de CPU average, fallaron porque esta métrica es inadecuada para cargas de trabajo sensibles a la latencia. El CPU average es útil para preguntas de costo y utilización general, pero no revela la latencia inducida por el throttling o la contención de recursos. La falta de visibilidad sobre métricas específicas de cgroup, como nr_throttled y throttled_usec en /sys/fs/cgroup/cpu.stat, impidió una detección temprana y precisa del problema.
La cascada de fallos incluyó la cancelación de la función Go debido al agotamiento del presupuesto de CPU, lo que a su vez provocó un deadlock en una librería de máquina de estados de terceros. Este comportamiento inesperado de la librería complicó aún más la recuperación y el diagnóstico, ya que el sistema quedaba en un estado irrecuperable. La combinación de un modelo de recursos mal entendido y una dependencia con un comportamiento de fallo deficiente resultó en un incidente prolongado y difícil de depurar.