Objetivo
Evitar compras basadas únicamente en especificaciones máximas o consumos instantáneos.
Contexto
Dimensionar comienza por la carga y el nivel de servicio. Dos aplicaciones con igual cantidad de usuarios pueden tener patrones muy diferentes de CPU, memoria, IOPS, latencia y crecimiento.
También importan redundancia, backups, ventanas de mantenimiento, virtualización y recuperación. La capacidad útil puede ser menor que la capacidad nominal por reservas y tolerancia a fallas.
Puntos clave
- Medir uso actual y picos representativos.
- Separar capacidad, rendimiento y disponibilidad.
- Proyectar crecimiento de datos, usuarios y retención.
- Definir reservas para fallas, mantenimiento y virtualización.
- Considerar red, energía, licencias y operación, no sólo hardware.
Recomendaciones
- Documentar cargas, versiones y requisitos del fabricante.
- Recolectar métricas de CPU, memoria, IOPS, latencia y red.
- Diseñar escenarios normal, pico, crecimiento y falla.
- Comparar alternativas físicas, virtuales y nube con costo total.
- Validar mediante prueba o referencia equivalente y monitorear después.
Riesgos y advertencias
- Promedios ocultan picos que afectan experiencia.
- Sobredimensionar aumenta costo sin corregir una mala arquitectura.
- Ignorar crecimiento y recuperación obliga a rediseñar prematuramente.
Cómo validar el resultado
- Las especificaciones se relacionan con una carga medida o estimada.
- Existe margen documentado y criterio para ampliación.
- Los escenarios de falla mantienen los servicios acordados.
Buenas prácticas
Registrar supuestos y revisar capacidad con métricas reales. Un diseño ajustable y observable suele ser más sostenible que intentar predecir todo el ciclo de vida.
Próximos pasos
Construir una ficha de carga por aplicación y medir una semana representativa antes de solicitar cotizaciones.