9.7 Planificación de capacidad y pronóstico de demanda

Presentación y motivación

Cada sistema tiene un techo. Los núcleos de cómputo se agotan, los discos se llenan, los grupos de conexiones se agotan, y una cola que estaba vacía en el desayuno se desborda en el almuerzo. La planificación de capacidad es la disciplina de ajustar el suministro de cómputo, almacenamiento, y red a la demanda que esperas, con suficiente margen para que un día normal nunca se acerque al techo y un mal día falle elegantemente en lugar de catastróficamente. El pronóstico de demanda es la otra mitad: predecir cuánta carga viene, cuándo, y por qué, para que el suministro llegue antes que la demanda en lugar de después de la interrupción.

Este capítulo se sitúa entre dos vecinos y se mantiene complementario a ambos. El capítulo 3.5 cubre la escalabilidad como una propiedad arquitectónica: cómo se construye un sistema para que pueda crecer en absoluto, a través de la ausencia de estado, la fragmentación, y el escalado horizontal. El capítulo 9.1 cubre la ingeniería de fiabilidad de sitios (SRE), que fija los objetivos de fiabilidad que la capacidad debe defender. Aquí tomas la arquitectura como dada y los objetivos como fijos, luego respondes una pregunta cuantitativa: cuánto de todo necesitas comprar, reservar, y mantener en reserva para que el sistema cumpla sus objetivos de nivel de servicio (SLO, los objetivos de fiabilidad del capítulo 9.1) a través de la demanda pronosticada y los picos que no pronosticaste. El autoescalado y la ingeniería de rendimiento (capítulo 2.16) son herramientas que usas aquí, pero no son sustitutos de la planificación, y confundirlos con planificación es un error común y costoso.

Para los equipos grandes, la capacidad deja de ser una hoja de cálculo que un ingeniero mantiene y se convierte en un modelo compartido del que dependen muchos servicios. Una plataforma de cientos de servicios comparte reservas finitas: conexiones de base de datos, rendimiento de intermediario de mensajes, cuotas de cuenta en la nube, salida de red. El crecimiento de un equipo puede privar al de otro si nadie tiene la imagen completa. En entornos empresariales, los errores de capacidad aparecen ya sea como millones desperdiciados en infraestructura inactiva o interrupciones vergonzosas durante los momentos exactos que más importan. En el gobierno, las apuestas se agudizan más. Un plazo tributario, una ventana de inscripción de beneficios, o una campaña de registro de salud pública concentra la demanda de una nación en unas pocas horas, la carga es legalmente mandatada en lugar de opcional, y el público recuerda un sitio que se dobló bajo un plazo que se fijó a sí mismo. La planificación de capacidad es cómo mantienes esas promesas.

Principios fundamentales

Planifica la capacidad para la demanda pronosticada más margen deliberado; no corras cerca de la saturación.
Separa la planificación de capacidad, el autoescalado, y la ingeniería de rendimiento; cada uno resuelve un problema distinto.
Pronostica a partir de la tendencia, la estacionalidad, los eventos conocidos, y el crecimiento de negocio, no solo de la semana pasada.
Encuentra tus límites reales mediante pruebas de carga y benchmarking, no adivinando ni esperando que la producción los encuentre.
Trata la latencia cerca de la saturación como un precipicio, no una pendiente; los objetivos de utilización existen por la teoría de colas.
Conoce tus cuellos de botella duros: los grupos de conexiones, las cuotas, y los puntos únicos no autoescalan.
Equilibra el costo contra la fiabilidad a propósito, y revisa la capacidad en una cadencia regular en lugar de después de un incidente.

Recomendaciones

Separa la planificación de capacidad, el autoescalado, y la ingeniería de rendimiento

Estas tres disciplinas a menudo se confunden, y confundirlas lleva a comprar la corrección equivocada. La planificación de capacidad es la pregunta de mediano a largo plazo de cuánto recurso total debes aprovisionar, reservar, y presupuestar a lo largo de semanas, trimestres, y años. El autoescalado es el ajuste automatizado de corto plazo de recursos para rastrear la carga minuto a minuto: te mueve dentro del sobre que aprovisionó la planificación, pero no puede conjurar cuota que nunca reservaste, calentar una base de datos fría, o escalar un componente que solo corre como una única instancia. La ingeniería de rendimiento (capítulo 2.16) cambia la forma del problema haciendo cada unidad de trabajo más barata, así el mismo hardware sirve más demanda.

La distinción es práctica. Cuando un sistema está lento bajo carga, el autoescalado añade instancias, la ingeniería de rendimiento hace cada instancia más rápida, y la planificación de capacidad decide si puedes costear las instancias y si la base de datos posterior puede aceptar las conexiones que abrirán. Un equipo que recurre solo al autoescalado golpeará un límite duro que nunca planificó; un equipo que recurre solo a la ingeniería de rendimiento optimizará código mientras la cuota de cuenta los limita de todos modos. Necesitas los tres, y necesitas saber cuál exige un problema dado.

Pronostica la demanda a partir de la tendencia, la estacionalidad, los eventos, y el crecimiento de negocio

Un pronóstico construido sobre el promedio de la semana pasada perderá cada momento interesante. Construye el tuyo a partir de cuatro componentes distintos. La tendencia es la dirección subyacente: ¿la demanda está creciendo, plana, o encogiéndose, y qué tan rápido? La estacionalidad es el patrón repetido: el pico diario a las 9 de la mañana, la calma semanal los fines de semana, el aumento anual antes de las vacaciones. Los picos impulsados por eventos son las concentraciones únicas: un lanzamiento de producto, una campaña de marketing, una mención en televisión, un plazo de presentación gubernamental. El crecimiento impulsado por negocio es la demanda que crea tu propia hoja de ruta: un nuevo mercado, la incorporación de un cliente grande, una función que triplica las solicitudes por sesión.

Usa la técnica correcta para cada uno. Una serie de tiempo de carga histórica, descompuesta en tendencia y estacionalidad, te da una línea base defendible para la demanda estable. Los eventos no pueden extrapolarse del historial porque no tienen historial; vienen de hablar con el negocio, leer la hoja de ruta, y preguntar a marketing y producto qué están a punto de lanzar. Los fallos de capacidad más dañinos casi siempre son eventos de los que ingeniería nunca escuchó. La cura es organizacional, no estadística: un canal permanente donde producto, marketing, y operaciones declaran los picos venideros con suficiente anticipación para aprovisionarlos.

Fija objetivos de utilización y respeta el precipicio de la teoría de colas

El instinto de correr la infraestructura «caliente» al 90% de utilización para ahorrar dinero es una trampa, y la razón es la teoría de colas, cubierta en profundidad en el capítulo 11.3. A medida que un recurso se acerca a la utilización completa, el tiempo de espera no sube suave y linealmente; explota. Un servidor al 50% de utilización tiene margen cómodo; el mismo servidor al 90% puede ver latencia varias veces peor, y al 95% la cola puede descontrolarse por completo. La latencia cerca de la saturación es un precipicio, no una pendiente, y tus usuarios sienten el precipicio como tiempos de espera agotados, reintentos, y errores mucho antes de que el recurso esté técnicamente «lleno».

Por eso los planificadores de capacidad fijan objetivos de utilización bien por debajo del 100%, comúnmente en el rango del 50% al 70% para servicios sensibles a la latencia, más alto para el trabajo por lotes orientado al rendimiento que tolera las colas. El objetivo no es desperdicio; es el precio de la latencia predecible. Elige el objetivo a partir del SLO: si tu objetivo de latencia es estricto, tu techo de utilización es más bajo, porque la latencia de cola que produce las colas es exactamente lo que revienta un SLO. El margen y el margen de seguridad son la misma idea desde dos direcciones. El margen es la brecha entre la carga normal y la capacidad; el margen de seguridad es esa brecha expresada como seguro contra un pronóstico que corre alto, una conmutación por error que concentra la carga, o un pico que no viste venir.

Encuentra los límites reales a través de pruebas de carga y benchmarking

No puedes planificar en torno a un límite que no has medido. La prueba de carga impulsa tráfico sintético o reproducido contra un sistema para observar cómo se comportan la latencia, el rendimiento, y la tasa de error a medida que sube la carga, y dónde se rompen. El benchmarking mide un componente en aislamiento para establecer su techo: solicitudes por segundo por instancia, escrituras por segundo por nodo de base de datos, mensajes por segundo por partición de intermediario. Juntos te dicen los dos números que necesita la planificación: cuánto entrega una unidad de capacidad, y dónde se cae todo el sistema.

Ejecuta varias pruebas distintas. Una prueba de carga sube al pico esperado y confirma que el SLO se mantiene con margen. Una prueba de estrés empuja más allá del punto de ruptura para ver cómo falla el sistema, porque un sistema que se degrada elegantemente es muy distinto de uno que colapsa. Una prueba de resistencia mantiene carga moderada durante horas o días para exponer fugas de memoria, agotamiento de conexiones, y problemas de llenado de disco que solo aparecen con el tiempo. Una prueba de pico golpea la carga repentinamente para comprobar si el autoescalado y los búferes la absorben antes de que los usuarios lo noten. Prueba contra datos y topología similares a producción, porque un límite medido en un conjunto de datos de juguete miente. Vuelve a ejecutar estas pruebas cuando el sistema cambia, para que tus números describan el sistema que tienes en lugar del que tenías hace un año.

Elige las estrategias de aprovisionamiento deliberadamente

Los proveedores de nube te permiten comprar la misma capacidad de maneras que intercambian precio por flexibilidad, y mezclarlas bien es donde se ahorra dinero real. La capacidad a demanda es flexible y costosa: pagas la tarifa completa por la capacidad de iniciar y detener en cualquier momento, lo cual conviene a la carga impredecible y de corta vida. La capacidad reservada (compromisos de uno o tres años, o planes de ahorro) es más barata por unidad a cambio de una promesa de seguir usándola, lo cual conviene a tu carga base estable. Las instancias spot venden la capacidad sobrante con un descuento profundo pero pueden recuperarse con poco aviso, lo cual conviene al trabajo tolerante a fallos e interrumpible como el procesamiento por lotes y los trabajadores sin estado.

El patrón que funciona es estratificado. Cubre tu carga base estable con capacidad reservada para el menor costo unitario, absorbe la variación diaria y semanal con el autoescalado a demanda, y empuja el trabajo por lotes interrumpible hacia spot para cosechar el descuento. Mantén un grupo de búfer tibio de capacidad preaprovisionada para los servicios que no pueden tolerar el retraso de arranque en frío de escalar desde cero, para que un pico repentino se encuentre con capacidad lista en lugar de una cola mientras arrancan nuevas instancias. La mezcla correcta es una decisión de cartera, y cambia a medida que cambia la forma de tu demanda y los precios del proveedor, así que revísala.

Mapea los cuellos de botella duros que no autoescalarán

El autoescalado cría una confianza peligrosa, porque muchos límites se sitúan aguas abajo de lo que escala y no se mueven cuando eso lo hace. Los grupos de conexiones de base de datos son el ejemplo clásico: escala tu capa sin estado de 10 a 100 instancias y cada una abre conexiones a la misma base de datos, que tiene un tope duro en conexiones concurrentes y empezará a rechazar nuevas. Las cuentas de nube cargan cuotas en casi todo: instancias por región, direcciones IP, llamadas de API por segundo, concurrencia de funciones. Cualquier punto único de la arquitectura, una base de datos primaria, un nodo líder, una caché compartida, un dispositivo con licencia, es un techo que el escalado horizontal en otro lugar no puede elevar.

Hazlos explícitos. Mantén un inventario escrito de cada límite duro entre una solicitud y su respuesta: tamaños de grupo, valores de cuota, componentes de instancia única, límites de tasa de terceros, conteos de asientos de licencia. Para cada uno, registra el valor actual, el uso actual, y la carga a la que se une. Este inventario es la diferencia entre un plan de capacidad que describe todo el sistema y uno que describe solo las partes fáciles y elásticas mientras un grupo de conexiones silenciosamente espera para terminar tu lanzamiento. Eleva las cuotas antes de la necesidad, porque los aumentos de cuota del proveedor pueden tomar días en aprobarse.

Aprovisiona para eventos pico, no solo el promedio

Los promedios ocultan los momentos que importan. Un sistema dimensionado para la carga media fallará en el pico, y para muchas organizaciones el pico es todo el punto: el aumento minorista en el día de compras más grande, el pico de transmisión en una final en vivo, el portal tributario en el plazo de declaración, el sitio de beneficios cuando abre la inscripción. Planifica estos eventos nombrados individualmente. Estima el pico a partir del negocio (usuarios concurrentes esperados, solicitudes por sesión, el múltiplo sobre un día normal), aprovisiona a ese pico con margen, prueba la carga a ese nivel, y prepara la capacidad antes del evento en lugar de improvisar durante él.

Trata un lanzamiento o plazo como un evento operacional con un runbook. Precalienta las cachés y grupos de búfer, eleva las cuotas por adelantado, congela los despliegues riesgosos durante la ventana, y pon humanos de guardia que puedan actuar si el pronóstico resulta bajo. Después del evento, captura el pico real y cuán cerca llegaste a tus límites, porque ese número es la mejor entrada para el plan del próximo año. Los plazos gubernamentales merecen cuidado especial: son autoimpuestos, públicamente conocidos, e inamovibles, así que no hay excusa para sorprenderse y ninguna manera de ocultarlo cuando lo estás.

Instrumenta la capacidad y revísala en una cadencia

La planificación de capacidad corre sobre datos, y los datos vienen de la observabilidad del capítulo 9.2. Rastrea la utilización de cada recurso restringido (CPU, memoria, disco, red, grupos de conexiones, profundidad de cola) contra su límite, para que puedas ver el margen encogiéndose antes de que desaparezca. Vigila las señales de saturación directamente: las longitudes de cola, los tiempos de espera, y las tasas de rechazo revelan el precipicio de colas acercándose. Grafica estas tendencias durante semanas para proyectar cuándo un recurso golpeará su techo a la tasa de crecimiento actual, y alerta sobre la proyección en lugar de solo el valor actual, para que aprovisiones antes del muro en lugar de en él.

Mantén revisiones de capacidad en una cadencia regular, mensual o trimestral, en lugar de solo después de un incidente. En cada revisión, compara el pronóstico con la demanda real y corrige el modelo, recorre el inventario de límites duros y comprueba el margen contra cada uno, mira los eventos venideros y los planes de negocio, y decide qué reservar, elevar, o retirar. Mantén un modelo de capacidad vivo: un documento simple u hoja de cálculo que mapea los impulsores de demanda a las necesidades de recursos, para que cualquiera pueda preguntar «¿qué pasa con la base de datos si el tráfico se duplica?» y obtener una respuesta del modelo en lugar de una interrupción. El modelo nunca es perfecto, pero un modelo escrito y regularmente corregido supera a la intuición cada vez.

Ventajas y desventajas

Enfoque	Ventajas	Desventajas
Objetivo de alta utilización	Menor costo por unidad; menos capacidad inactiva	La latencia explota cerca de la saturación; sin espacio para picos o conmutación por error
Margen generoso	Latencia predecible; absorbe picos y conmutación por error	Mayor costo estable; puede ocultar la ineficiencia
Capacidad reservada	Precio unitario más bajo para carga base estable	Riesgo de compromiso si la demanda cae o cambia
Capacidad a demanda	Flexible; coincide con la carga variable minuto a minuto	Precio unitario más alto; puede sorprender al presupuesto
Instancias spot	Descuento profundo para trabajo interrumpible	Recuperadas sin aviso; inadecuadas para trabajo con estado o crítico en latencia
Autoescalado	Rastrea la carga automáticamente dentro del sobre	No puede exceder la cuota reservada; arranques fríos; enmascara los límites posteriores
Grupo de búfer (capacidad tibia)	Absorbe picos repentinos instantáneamente	Paga por capacidad inactiva entre picos

La tensión central es el costo contra la fiabilidad, y no hay un ajuste que optimice ambos. Corre delgado y ahorras dinero hasta el día en que un pico se encuentra con un recurso saturado y la latencia cae del precipicio de colas. Corre generoso y duermes bien mientras pagas por margen que está inactivo la mayor parte del tiempo. Resuelve la tensión con el SLO en lugar de con miedo o tacañería. Aprovisiona suficiente margen para cumplir el objetivo de fiabilidad a través de los picos pronosticados más un margen, y no más, luego deja que FinOps (operaciones financieras para el gasto en la nube, capítulo 9.4) cace el desperdicio que no defiende un SLO. La meta es un equilibrio deliberado: cada dólar de margen comprado a propósito para comprar una cantidad conocida de fiabilidad, y cada dólar de desperdicio eliminado a propósito porque no compra ninguna.

Preguntas para discutir con tu equipo

¿Realmente sabemos la carga a la que se une cada uno de nuestros cuellos de botella duros, o estamos asumiendo que el autoescalado nos salvará? La mayoría de los equipos pueden decirte que sus instancias autoescalan, y la mayoría no pueden decirte el límite de conexiones concurrentes en su base de datos primaria, el límite de tasa de API de su tercero más importante, o la cuota de cuenta que limita la concurrencia de su función. Esos son los límites que terminan lanzamientos, y no se mueven cuando escala la capa sin estado. Trae el inventario escrito de límites duros si tienes uno, y si no lo tienes, esa ausencia es el hallazgo. Para cada límite, quieres tres números: el techo, el uso de hoy, y el nivel de demanda en el que se encuentran. Donde no puedas producir los tres, tienes un cuello de botella que gestionas por esperanza.
¿Cuándo probamos la carga por última vez al nivel de nuestro peor pico venidero, en datos similares a producción, y el SLO se mantuvo con margen? Un plan de capacidad es un conjunto de afirmaciones sobre cómo se comporta el sistema bajo carga, y una afirmación no probada es una conjetura con traje. El pico que importa no es el promedio del mes pasado sino el próximo lanzamiento, temporada, o plazo, y la prueba solo significa algo si los datos y la topología se asemejan a la producción, porque un límite medido en un conjunto de datos de juguete miente. Trae los resultados de tus pruebas de estrés y resistencia más recientes, incluyendo dónde se rompió el sistema y cómo falló cuando lo hizo. Si la respuesta honesta es que nunca has llevado el sistema a su punto de ruptura a propósito, entonces descubrirás ese punto en producción, en el peor momento posible, con los usuarios observando.
¿Cómo le dicen producto, marketing, y operaciones a ingeniería sobre un pico antes de que suceda, y con cuánta anticipación? Los fallos de capacidad más costosos no son errores de modelado; son eventos de los que ingeniería nunca escuchó hasta que llegó el tráfico. Un pronóstico puede extrapolar la tendencia y la estacionalidad del historial, pero un evento no tiene historial, así que solo puede venir de la gente que lo planifica. Trae los últimos tres picos de demanda y pregunta, para cada uno, cuántos días de aviso obtuvo ingeniería y si eso fue suficiente para reservar capacidad y probar la carga. La evidencia que quieres es un canal permanente con un tiempo de anticipación lo bastante largo para aprovisionar contra él, porque los aumentos de cuota de la nube por sí solos pueden tomar días. Si el canal no existe, tu plan de capacidad es ciego exactamente ante los momentos que existe para proteger.
¿Qué objetivo de utilización realmente opera cada servicio sensible a la latencia, y podemos rastrear ese número de vuelta a su SLO en lugar de a un objetivo de costo? Esto importa porque la presión de correr la infraestructura caliente es constante y viene de la parte de la organización que ve la factura pero no el precipicio de colas, así que a menos que el objetivo esté escrito y justificado a partir del objetivo de latencia, deriva hacia arriba hasta que un pico encuentra el borde. Las consideraciones en competencia son dinero real en un lado y latencia de cola en el otro, y la posición honesta es que el margen por debajo del 100% es el precio de la latencia predecible, no desperdicio que recortar. Trae la utilización actual de tus pocos servicios principales, el SLO que cada uno defiende, y la latencia que mediste en esa utilización bajo carga, para que la discusión argumente desde la evidencia en lugar de la intuición. En una plataforma empresarial o gubernamental donde un fondo compartido respalda muchos servicios, acuerda el objetivo centralmente y registra quién puede cambiarlo, porque un único equipo elevando silenciosamente su techo puede empujar un recurso del que otros dependen sobre el precipicio para todos.
¿Cuál es nuestra mezcla de capacidad reservada, a demanda, y spot, cuándo la revisamos por última vez, y todavía coincide con la forma de nuestra demanda? La mezcla es donde se ocultan tanto los mayores ahorros sostenidos como el mayor desperdicio sostenido, porque una carga base estable pagada a tarifas a demanda quema dinero cada hora mientras una posición reservada sobrecomprometida paga por capacidad que la demanda desde entonces ha superado o caído por debajo. La tensión es costo contra flexibilidad y riesgo de compromiso: la capacidad reservada es la más barata por unidad pero te ata, spot es más barata todavía pero puede recuperarse sin aviso, y a demanda compra libertad a una prima. Trae la división actual por costo, la curva de demanda que se supone cubre, y la tasa de recuperación y radio de impacto de cualquier carga de trabajo spot, para que la sala pueda ver si el trabajo interrumpible realmente es interrumpible. En entornos empresariales y gubernamentales, vincula los compromisos reservados al ciclo de contratación pública y presupuesto, porque los compromisos multianuales y los planes de ahorro son obligaciones financieras que finanzas y auditoría querrán justificadas contra la demanda pronosticada, no contra la conveniencia del último trimestre.
Cuando viene un evento pico nombrado, ¿quién es dueño del precalentamiento, los aumentos de cuota, las congelaciones de despliegue, y la decisión de seguir adelante, y está escrito como un runbook que hemos ensayado? Los eventos pico son los momentos que la planificación de capacidad existe para proteger, y fallan más a menudo no porque el plan estuviera mal sino porque nadie era responsable de ejecutarlo bajo presión el día. Las consideraciones que compiten aquí son la velocidad y la autonomía contra la coordinación: los equipos quieren seguir enviando, sin embargo un despliegue riesgoso durante la ventana de aumento puede deshacer meses de aprovisionamiento, así que alguien tiene que sostener la autoridad para congelar y detener el lanzamiento. Trae el runbook para tu próximo gran evento, los tiempos de anticipación para los aumentos de cuota y el precalentamiento de grupo de búfer, y el registro de quién sostuvo cada rol la última vez y si los traspasos se mantuvieron. Para un plazo gubernamental que es autoimpuesto, públicamente conocido, e inamovible, nombra al dueño responsable y la ruta de escalado explícitamente, porque no hay opción de descargar la demanda o pedirle a los ciudadanos que regresen después, y un pico del que nadie es dueño es un pico que nadie defenderá cuando llegue.

Perspectiva sectorial

Startup. Tu recurso más escaso es la atención de ingeniería, así que mantén la planificación de capacidad barata y apóyate en la elasticidad del proveedor de nube para la variación diaria. Lo único que no puedes saltarte es una lista escrita de los límites duros que no autoescalan: tu tope de conexiones de base de datos primaria, el límite de tasa de tu tercero más importante, y las cuotas de cuenta que golpearías bajo una función repentina o pico de prensa. Prueba la carga a varias veces tu pico normal en datos de tamaño de producción antes de tu primer aumento real, porque la confianza frágil que te da el autoescalado es exactamente lo que se rompe cuando una base de datos rechaza conexiones.

Pequeña empresa. No tienes un especialista de capacidad y tienes un presupuesto ajustado, así que trata esto como un problema de comprar y configurar en lugar de un proyecto de modelado. Favorece los servicios gestionados que absorben el escalado por ti, fija alertas de gasto y tableros de utilización simples para que una factura desbocada o un recurso saturando sea visible temprano, y conoce los pocos eventos nombrados (una prisa estacional, un cliente grande yendo en vivo) que definirán tu año. Reserva capacidad para tu carga base estable para recortar la factura, y resiste construir maquinaria de pronóstico que no puedes mantener cuando la forma de la demanda apenas se mueve.

Empresa. El problema es un conjunto compartido y finito de fondos detrás de cientos de servicios, así que la capacidad se convierte en gobernanza de cartera: un inventario de límites duros mantenido, objetivos de utilización derivados centralmente de los SLO, y una mezcla deliberada de capacidad reservada, a demanda, y spot revisada contra los precios en vivo. Estandariza las pruebas de carga, estrés, resistencia, y pico para que cada equipo mida de la misma manera en datos similares a producción, y ejecuta revisiones de capacidad en una cadencia que atrape un margen que se encoge antes de que lo haga un incidente. Presupuesta explícitamente la coordinación, porque el crecimiento de un equipo puede privar al de otro cuando nadie tiene todo el modelo.

Gobierno. La demanda a menudo se concentra legalmente en un plazo inamovible y públicamente conocido, así que planifica específicamente para ese pico nombrado y aprovisiona un amplio margen de seguridad, ya que no puedes descargar la demanda ni pedirle a los ciudadanos que regresen después. Las reglas de contratación pública moldean el aprovisionamiento: los compromisos reservados multianuales y los acuerdos de cuota de proveedor deben justificarse contra la demanda pronosticada y sobrevivir la auditoría, así que mantén el pronóstico, la evidencia de prueba de carga, y el inventario de límites duros documentados y defendibles. Publica expectativas realistas donde puedas, eleva los límites del proveedor bien antes de la ventana, y registra el pico real de cada ciclo, porque la rendición de cuentas pública significa que un portal que se dobla bajo un plazo que se fijó a sí mismo es un fallo que ve todo el país.

Ejemplos

Startup. Una startup de diez personas opera una aplicación de consumo sobre infraestructura de nube con autoescalado y se siente segura porque el conteo de instancias crece con la carga. Su primera aparición en televisión triplica el tráfico en una hora, la capa sin estado escala hermosamente, y la aplicación se cae de todos modos: cada nueva instancia abría conexiones de base de datos hasta que la base de datos golpeó su tope de conexiones y empezó a rechazarlas. La lección remodela su práctica. Añaden un agrupador de conexiones frente a la base de datos, escriben cada límite duro entre una solicitud y una respuesta, y prueban la carga a varias veces su pico normal en un conjunto de datos de tamaño de producción. Cubren su carga base estable con un compromiso de capacidad reservada para el descuento y mantienen un pequeño grupo de búfer tibio para que el siguiente pico encuentre capacidad lista. Los cambios cuestan una semana y convierten su confianza frágil en un plan que pueden defender.

Empresa. Un minorista global trata su día de ventas más grande como el evento de capacidad del año. Meses antes, un equipo multifuncional construye un pronóstico de demanda a partir de la tendencia y estacionalidad de años anteriores más el plan de mercadeo, traduce el pronóstico en necesidades de recursos a través de un modelo de capacidad, y aprovisiona al pico proyectado con margen generoso. Prueban la carga, el estrés, la resistencia, y el pico de la ruta completa en datos similares a producción, elevan cada cuota de nube relevante semanas antes, precalientan cachés y grupos de búfer, y congelan los despliegues riesgosos para la ventana circundante. La capacidad reservada cubre la carga base estable por costo, el autoescalado a demanda absorbe la curva diaria, y el trabajo por lotes interrumpible corre en spot. La observabilidad rastrea cada recurso restringido contra su límite en tiempo real durante el evento, con alertas sobre la saturación proyectada en lugar del valor actual. El día pasa sin drama, que es exactamente el resultado que compró la planificación.

Gobierno. Una agencia tributaria nacional opera un portal de declaración cuya demanda se concentra legalmente en los días antes de un plazo inamovible, cuando todo un país declara a la vez. La agencia planifica específicamente para ese pico en lugar de para un promedio anual que sería insignificante. Estima los declarantes concurrentes a partir de años anteriores y datos de población, aprovisiona a ese pico con un amplio margen de seguridad porque no hay opción de descargar la carga o pedirle a los ciudadanos que regresen después, y prueba la carga a la concurrencia proyectada en datos realistas. El equipo mantiene un inventario escrito de cada cuota y punto único de fallo, eleva los límites con los proveedores bien antes de la ventana, y fija objetivos de utilización lo bastante bajos para que el precipicio de colas permanezca lejos del aumento del plazo. Después de cada temporada de declaración registran el pico real y cuánto margen quedó, alimentando el modelo del próximo año. El público ve un portal que se mantiene activo el día para el que está diseñado, que es todo el punto de la promesa de la institución.

Caso de negocio: motivaciones, ROI y TCO

El retorno de la planificación de capacidad aparece como dos costos evitados que tiran en direcciones opuestas, que es lo que hace valiosa la disciplina. El subaprovisionamiento cuesta interrupciones, y las interrupciones durante los eventos pico cuestan más: ingresos perdidos, transacciones perdidas, y daño reputacional precisamente cuando la audiencia es más grande. Un sitio minorista caído en su día más grande o un portal gubernamental colapsando en su plazo de declaración paga años de planificación en una sola mala hora. El sobreaprovisionamiento cuesta en la dirección opuesta, en facturas de la nube por capacidad que está inactiva, y a escala empresarial unos pocos puntos de sobreaprovisionamiento crónico a través de una flota suman millones de dólares al año. La planificación de capacidad es la práctica que encuentra el medio deliberado: suficiente para defender el SLO a través de los picos, no más que eso.

El costo de adoptar es principalmente disciplina en lugar de herramientas. Construyes un pronóstico de demanda, escribes tus límites duros, ejecutas pruebas de carga en una cadencia, mezclas tus estrategias de aprovisionamiento, y mantienes revisiones de capacidad regulares. El costo total de propiedad (TCO) mejora desde ambos lados a la vez: menos incidentes impulsados por capacidad bajan el costo de la inactividad y la respuesta de emergencia, y el dimensionamiento correcto continuo más una mezcla sensata de reservado y spot bajan la factura de infraestructura estable. Para presentar el caso al liderazgo, conecta la capacidad a los números que ya vigilan. Vincula el subaprovisionamiento a los ingresos perdidos por hora de inactividad pico y a los incumplimientos de SLO con penalizaciones contractuales, y vincula el sobreaprovisionamiento al informe de desperdicio de FinOps del capítulo 9.4. El argumento no es prudencia abstracta; es dinero en ambos lados de un dial que puedes fijar a propósito.

Antipatrones y trampas

Autoescalado como plan: confiar en instancias elásticas mientras un grupo de conexiones de base de datos, una cuota de cuenta, o un punto único silenciosamente limitan todo el sistema.
Correr caliente para ahorrar dinero: apuntar a una utilización del 90% o más y encontrar el precipicio de colas, donde la latencia explota y el SLO se rompe.
Promedios en lugar de picos: dimensionar para la carga media para que el sistema falle exactamente en el evento pico que justificó construirlo.
Pronosticar solo desde el historial: extrapolar la tendencia y la estacionalidad mientras se pierde el lanzamiento o campaña del que ingeniería nunca fue informada.
Límites no probados: planificar en torno a un punto de ruptura que nadie ha medido, luego descubrirlo en producción en el peor momento.
Pruebas de carga con datos de juguete: medir la capacidad en datos y topología irreales, produciendo números que mienten sobre el sistema real.
Sin inventario de límites duros: gestionar las cuotas, grupos, y puntos únicos por memoria y esperanza en lugar de una lista escrita y mantenida.
Reservar todo o no reservar nada: sobrecomprometerse con capacidad reservada que la demanda supera o cae por debajo, o pagar tarifas a demanda completas por una carga base estable.
Revisión de capacidad solo después de incidentes: tratar la planificación como apagado reactivo de incendios en lugar de una cadencia regular que aprovisiona antes de la necesidad.

Modelo de madurez

Nivel 1, Iniciar: La capacidad es reactiva y ad hoc. Los equipos añaden recursos después de agotarlos, confían en que el autoescalado maneje todo, y no tienen pronóstico, ni inventario de límites duros, ni pruebas de carga. Los eventos pico se enfrentan con esperanza, y las interrupciones durante los lanzamientos y plazos se tratan como mala suerte.
Nivel 2, Desarrollar: Aparecen prácticas básicas pero varían por equipo. Algo de monitoreo muestra la utilización, algunas pruebas de carga ocurren antes de grandes eventos, se conocen las cuotas principales, y existe un pronóstico aproximado en algunos lugares, pero el modelo no se mantiene, los cuellos de botella posteriores a menudo se pierden, y el margen se fija por regla de dedo en lugar de a partir del SLO.
Nivel 3, Estandarizar: La planificación de capacidad es una disciplina documentada que se aplica en toda la organización. Un pronóstico de demanda combina la tendencia, la estacionalidad, los eventos, y el crecimiento de negocio; se mantiene un inventario escrito de límites duros; los objetivos de utilización se derivan de los SLO; las pruebas de carga, estrés, resistencia, y pico corren en una cadencia contra datos similares a producción; y el aprovisionamiento mezcla reservado, a demanda, y spot deliberadamente. Un canal permanente lleva advertencias de eventos de producto y marketing a ingeniería.
Nivel 4, Gestionar: La capacidad se mide y controla contra líneas base. El pronóstico se compara con la demanda real cada ciclo y el error se rastrea y reduce; la utilización, las señales de saturación, y el margen contra cada límite duro se grafican en tendencia y se alertan como proyecciones en lugar de valores actuales; los eventos pico se revisan después contra el verdadero pico observado; y la mezcla de aprovisionamiento, la cobertura de compromiso reservado, y el costo por SLO se reportan como métricas que bloquean las decisiones de continuar o no. Los datos, no la intuición, deciden qué reservar, elevar, o retirar.
Nivel 5, Orquestar: La planificación de capacidad se mejora continuamente y se integra en toda la organización. Los pronósticos se validan y refinan automáticamente, la saturación se proyecta y se aprovisiona contra ella antes de que llegue, las mezclas de aprovisionamiento se optimizan contra los precios en vivo, los eventos pico corren desde runbooks ensayados, y el costo y la fiabilidad se equilibran deliberadamente contra el SLO a través de toda la plataforma. El modelo de capacidad es un activo compartido y adaptativo que reequilibra la flota a medida que cambian la forma de la demanda y los precios del proveedor.

Ideas para el debate

¿Cuál es tu objetivo actual de utilización para los servicios sensibles a la latencia, y puedes justificarlo a partir de tu SLO y el comportamiento de colas en lugar de un deseo de ahorrar dinero?
¿Cuáles de tus componentes no pueden autoescalar en absoluto, y qué pasa con el resto del sistema cuando uno de ellos se satura?
Si tu tráfico se duplicara el próximo trimestre, ¿qué recurso golpea su techo primero, y cuántos días de anticipación necesitarías para elevarlo?
¿Cómo decides la mezcla de capacidad reservada, a demanda, y spot, y cuándo la revisaste por última vez contra la forma real de tu demanda?
Cuando viene un evento pico, ¿quién es dueño del precalentamiento, los aumentos de cuota, y la decisión de seguir adelante, y está escrito como un runbook?
¿Se disparan tus alertas de capacidad sobre la saturación proyectada semanas antes, o solo sobre la utilización actual una vez que el muro ya está cerca?

Puntos clave

La planificación de capacidad ajusta el suministro a la demanda pronosticada con margen deliberado; es distinta del autoescalado (corto plazo, dentro del sobre) y la ingeniería de rendimiento (unidades de trabajo más baratas).
Pronostica a partir de la tendencia, la estacionalidad, los eventos conocidos, y el crecimiento de negocio, y obtén advertencias de eventos de producto y marketing, porque los eventos no tienen historial que extrapolar.
Respeta el precipicio de la teoría de colas (capítulo 11.3): la latencia explota cerca de la saturación, así que fija los objetivos de utilización a partir de tu SLO y mantén margen real.
Encuentra los límites mediante pruebas de carga, estrés, resistencia, y pico en datos similares a producción, y mantén un inventario escrito de los cuellos de botella duros que no autoescalarán.
Mezcla la capacidad reservada, a demanda, y spot con grupos de búfer tibios, planifica los eventos pico nombrados individualmente, y revisa la capacidad en una cadencia en lugar de después de las interrupciones.

Referencias y lecturas adicionales

Betsy Beyer, Chris Jones, Jennifer Petoff, y Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, y Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott y Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment y Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management