Un reciente análisis profundiza en uno de los detalles técnicos que rodearon la caída de GitHub del pasado 18 de agosto: la política de autoescalado del servicio afectado. El incidente se originó cuando un pod con un sidecar de Istio alcanzó sus límites de concurrencia y no logró escalar correctamente porque la política observaba la carga del servicio principal, pero no la del sidecar.
El autoescalado es la estrategia que ajusta dinámicamente los recursos de cómputo y memoria de un servicio según la carga de tráfico, en contraposición a aprovisionar para el pico máximo. Aunque la métrica habitual es el uso de CPU, un servicio puede saturarse con CPU baja si los hilos quedan bloqueados esperando operaciones de entrada/salida, como ocurrió en Slack en 2021. Para estos casos se necesitan reglas adicionales o, directamente, escalar por volumen de peticiones entrantes.
El texto subraya que cada servicio necesita una política de autoescalado prácticamente artesanal, que solo puede validarse con pruebas de carga. Por ello, no es extraño que los equipos de desarrollo, que no suelen ser expertos en autoescalado, configuren políticas defectuosas. Sin embargo, el autor advierte del riesgo de fijarse solo en el componente defectuoso, lo que el investigador David Woods denomina la falacia de la sustitución de componentes: asumir que mejorar la fiabilidad se reduce a identificar y arreglar piezas individuales. Cualquier sistema contiene defectos latentes y, aun así, no cae continuamente, lo que implica que las interacciones entre componentes son tan importantes como los componentes mismos. En la caída de GitHub confluyeron cambios de patrones de tráfico, la citada política de autoescalado, la saturación del sidecar, la lógica de reintentos, la saturación de nodos HAProxy y el tráfico de autenticación.