La lista de verificación postincidente que evita que las tormentas de reintentos se conviertan en caídas

Tu página de on-call indica que un endpoint está lento; la siguiente página es de un cliente que lo está reintentando. En la caída de GitHub.com del 17 de agosto de 2026, el servicio permaneció degradado durante 7 horas y 47 minutos. En Central US, un pod sidecar de Istio alcanzó su límite de concurrencia mientras el autoscaler de GitHub medía el servicio host en lugar del sidecar. En el pico, los errores de web y API rondaron el 20 por ciento, y los fallos en descargas de archivo y repositorio raw rondaron el 50 por ciento.

Escala el componente que se satura

Un autoscaler sigue una métrica. Si sigue la métrica equivocada, la capacidad crece mientras el componente saturado sigue lleno. Un servicio host puede parecer saludable mientras el sidecar que lo precede ya está rechazando trabajo. La nota postincidente debe nombrar el componente saturado, no el síntoma. Si el autoscaler no vigila ese componente, la solución es una métrica, no más capacidad.

El punto ciego del autoscaling es la diferencia entre el componente que se satura y la métrica que el escalador vigila. Un panel que solo muestra el volumen de peticiones puede ocultar una cola que ya está llena. El líder de on-call debe poder señalar la métrica que habría disparado la alerta antes. El postmortem debe registrar la métrica faltante, la métrica que debería haberse vigilado y el responsable que la añadirá.

Limita el tráfico generado por el cliente

Una tormenta de reintentos añade carga. Durante el mismo incidente, el Copilot Token Service de GitHub pasó de un normal 7.000 a 9.000 peticiones por segundo a 70.000 a 100.000 peticiones por segundo, un aumento aproximado de diez veces. GitHub identificó un posible defecto de reintento en VS Code, provocado por respuestas lentas de un único endpoint interno, como un contribuyente a la mayor carga y la recuperación más lenta. Pausar los cuatro nodos saturados del balanceador de carga HAProxy de una vez produjo una recuperación inmediata y generalizada del servicio.

Un presupuesto de reintentos limita el trabajo extra que un cliente puede generar. Sin un límite, un endpoint lento puede arrastrar al sistema completo a trabajo adicional. El presupuesto debe ser lo suficientemente pequeño para proteger el servicio y lo suficientemente grande para preservar reintentos útiles. El backoff debe distribuir los reintentos en el tiempo, y un circuit breaker debe impedir que el cliente siga llamando a una ruta que falla. Nombra al cliente que amplificó el tráfico, incluso si el cliente está fuera del codebase de la empresa.

Registra los clientes desplegados como dependencias de producción

Un cliente que sale del codebase de la empresa no deja de ser parte del sistema. Puede reintentar, cachear, agrupar o fallar de formas que el equipo del servicio no diseñó. El líder de operaciones debe mantener un inventario de clientes que registre el nombre del cliente, la versión en uso, el comportamiento de reintento y el equipo que puede modificarlo.

Ese inventario debe estar junto al mapa de dependencias del servicio, no en una hoja de cálculo que solo aparece durante un incidente. Si un cliente es antiguo, dilo en el postmortem. Si un cliente no puede parchearse rápidamente, el servicio debe asumir que reintentará y diseñarse para eso. Un registro de cliente ausente es un hueco en el mapa de dependencias, no un problema de papeleo.

Ejecuta la lista de verificación en el postmortem

La lista de verificación debe estar en el postmortem del incidente, no en un hilo de chat. Debe ser lo suficientemente corta para ejecutarse en la misma reunión donde el equipo decide qué cambió, y cada elemento debe ser verificable rápidamente.

• Nombre el componente saturado. Escribe el servicio, pod, cola o endpoint exacto que se llenó.
• Verifica la métrica del autoscaler. Confirma que la política de escalado lee el componente saturado, no un servicio padre saludable.
• Establece un presupuesto de reintentos. Da a cada cliente un número máximo de reintentos, backoff y circuit breaker.
• Lista los clientes desplegados como dependencias de producción. Registra la versión, el comportamiento de reintento y quién puede parchearlo.

Un fallo de un cliente desplegado es un fallo de producción. El equipo no puede aplicar un hotfix a un cliente que no controla, por lo que el postmortem debe tratar a ese cliente como un servicio con un responsable, una versión y un modo de fallo conocido. Si el cliente reintenta sin presupuesto, el servicio debe diseñarse para absorber esa carga.