Estimación de la implantación de un límite de velocidad
Cómo planificar la implantación de un límite de tráfico: umbrales, periodos de prueba y comunicaciones con los clientes. El código se escribe en medio día; lo difícil es elegir unos límites que no generen quejas.
La programación lleva medio día. La puesta en marcha dura dos meses.
Los límites de tasa son fáciles de implementar, pero difíciles de poner en práctica. El middleware es un patrón conocido. Lo difícil es elegir unos umbrales que no generen quejas, y la única forma de hacerlo es medir el uso actual, anunciar los límites con antelación, observar durante un periodo de prueba quiénes habrían sido bloqueados, atender las quejas de los usuarios más activos y, solo entonces, aplicar las restricciones. Esa secuencia constituye el trabajo en sí, y no cabe en un sprint.
Los equipos que calculan el tiempo necesario para el middleware se saltan por completo la fase de implementación. Los equipos que calculan el tiempo necesario para la implementación obtienen una cifra mucho mayor, se preguntan si realmente es urgente y, por lo general, deciden dividirla en varias fases a lo largo de varios ciclos, lo cual es la respuesta correcta. Calcular la duración total de todo el proyecto de una sola vez obliga al equipo a enfrentarse a una falsa disyuntiva.
Lo que se dice en la sala
Backend: «El middleware es cosa del pasado. Contamos con una biblioteca».
SRE: «¿Qué umbrales? ¿Hemos consultado la página 99 sobre el uso actual?»
PM: «¿A quién debemos enviar un correo electrónico antes de que esto entre en funcionamiento?»
Soporte técnico: «¿Qué indica el código de respuesta 429? ¿Hay un plazo para volver a intentarlo?»
Titular: «¿Primero el modo de prueba o directamente a la aplicación de la normativa?»
Preguntas que conviene plantearse antes de votar
- ¿Hemos medido el consumo de corriente en los percentiles p50, p95 y p99 por cliente?
- ¿Qué umbrales se han establecido y cómo se han determinado?
- ¿Por cuenta, por dirección IP, por clave API? ¿Combinaciones?
- Período de prueba: ¿cuánto dura y qué se entiende por «sin sorpresas»?
- Comunicación con los clientes: ¿a quién debemos enviar el correo electrónico y con cuánta antelación?
- ¿Cómo es la respuesta 429: mensaje, tiempo de espera para reintentar, enlace a la documentación?
- ¿Cuál es el procedimiento de excepción para un cliente que necesita un límite más alto?
Dividirlo: la aplicación de las normas es una cuestión, las pruebas de simulación y las comunicaciones son otra, y el ajuste de los umbrales es una tercera. Cada una de ellas es considerable por sí sola; el conjunto, en cambio, no lo es.
Adapte el alcance de la implantación, no el middleware. Lo importante es realizar mediciones, comunicar los resultados y llevar a cabo simulacros.
Consulte cómo estimar el lanzamiento de un «feature flag» para ver el mismo patrón en el que «el lanzamiento se lleva todo el trabajo», así como los demás ejemplos prácticos de estimación. Inicie una sesión gratuita de «planning poker» cuando se hayan definido las fases.