Planificación de capacidad: detecta la saturación antes de que llegue al usuario

Cuando una aplicación se vuelve lenta, ampliar recursos parece la respuesta más directa. A veces lo es; otras veces solo aplaza una consulta ineficiente, una cola bloqueada o un límite externo. Planificar capacidad consiste en relacionar demanda y comportamiento del servicio para anticipar dónde se agotará el margen. No hace falta predecir el futuro con exactitud. Hace falta reconocer tendencias, conocer los límites relevantes y disponer de opciones antes de que el usuario note la saturación.

Empieza por una unidad de trabajo comprensible

Selecciona una medida que explique la actividad: peticiones, documentos procesados, sesiones simultáneas o trabajos completados. Relaciónala con tiempo de respuesta, errores y recursos consumidos. Un porcentaje de CPU aislado informa poco sobre la experiencia del usuario. Una subida de latencia al superar cierto volumen puede revelar un límite práctico, incluso cuando la CPU parece disponer de margen. Mantén las definiciones estables para comparar periodos sin mezclar operaciones de naturaleza distinta.

Mira picos, distribución y componentes

La media diaria puede ocultar veinte minutos de saturación que bloquean una tarea importante. Revisa ventanas más pequeñas y percentiles, además de diferencias entre máquinas o instancias. Un balanceo desigual puede dejar un nodo ocupado y otro ocioso. Examina memoria, disco, conexiones, colas y límites de servicios externos. La planificación debe seguir el recorrido de la petición: comprar más capacidad en una capa no arregla un cuello de botella que está en otra.

Conserva información sobre eventos que explican los cambios: nuevas versiones, campañas, importaciones grandes o modificaciones de configuración. Sin ese contexto, una tendencia puede interpretarse como crecimiento permanente cuando procede de una tarea puntual. También conviene separar horarios interactivos y procesos por lotes. Si ambos compiten por los mismos recursos, mover una tarea a otra franja puede resultar más eficaz y sencillo que aumentar toda la infraestructura.

Calcula el margen para escenarios reales

No diseñes únicamente para el día habitual con todos los componentes disponibles. Considera mantenimiento, pérdida de una instancia y crecimiento previsto. Un servicio redundante puede funcionar bien mientras todo está sano y saturarse al perder un nodo. Estima cuánto trabajo puede absorber el conjunto restante y durante cuánto tiempo. Los supuestos deben estar escritos para que una decisión de reducción de costes no elimine accidentalmente la capacidad reservada para una avería.

• Define la carga habitual y un pico razonable según el historial y los planes conocidos.
• Identifica el primer recurso que limita el servicio y cómo se manifiesta.
• Comprueba capacidad durante mantenimiento o indisponibilidad de un componente.
• Prepara medidas temporales y una ampliación con plazo y coste estimados.

Ensaya sin provocar una incidencia

Las pruebas de carga deben tener alcance, autorización y límites de parada. Utiliza un entorno representativo y datos adecuados; si interviene producción, planifica controles adicionales y comunicación. Incrementa la carga de forma gradual y observa cómo se recupera el sistema al retirarla. El comportamiento bajo sobrecarga importa tanto como el máximo alcanzado: una cola que tarda horas en vaciarse puede prolongar el problema después de terminar el pico.

Decide entre optimizar, limitar y ampliar

Cuando aparece un límite, compara alternativas. Optimizar una consulta, introducir caché con invalidación correcta o controlar concurrencia puede mejorar eficiencia; ampliar recursos puede ser la respuesta más rápida cuando la demanda es legítima. Las estrategias de protección frente a sobrecarga descritas por Google SRE recuerdan que aceptar trabajo ilimitado puede empeorar el resultado. En ocasiones conviene rechazar o posponer tareas de baja prioridad antes de degradar todas las operaciones del servicio.

Cada medida tiene efectos secundarios. Una caché añade decisiones sobre vigencia; limitar concurrencia puede aumentar espera; escalar requiere tiempo y puede estar sujeto a cuotas. Documenta esos intercambios y verifica el resultado con la misma unidad de trabajo inicial. Evita declarar éxito porque bajó una métrica de infraestructura si la latencia percibida sigue igual. La referencia final es el nivel de servicio que necesita la actividad, no una gráfica concreta.

Convierte la previsión en una acción con fecha

Si el crecimiento indica que el almacenamiento se agotará en varios meses, compara ese margen con el plazo real de ampliar, contratar y migrar. Define umbrales que abran una tarea con responsable, no solo una alarma. Revisa previsiones tras cambios significativos y conserva las desviaciones para aprender. Un plan de capacidad útil no promete precisión absoluta: ofrece tiempo para decidir y evita que cada aumento de demanda se convierta en una compra urgente o una interrupción.