Para empezar con la planificación de capacidad en Fabric esta semana, abre Capacity Metrics y observa el consumo de unidades y la sobrecarga durante los picos reales. Después define un ritual de operación de capacidad (encender, asignar, pausar y reanudar antes y después de las ventanas de carga) y verifica siempre el estado por API. No necesitas un proyecto grande: necesitas mirar, decidir y repetir.
¿Qué significa planificar capacidad en Fabric?
En Microsoft Fabric, la capacidad es el conjunto de unidades de cómputo que sostiene tus cargas: informes de Power BI, flujos de datos, notebooks, modelos semánticos y agentes. Planificar capacidad no es adivinar un número al inicio, es operar un sistema cuyo consumo sube cuando lo usan más personas o cuando corren procesos pesados.
El error común es tratar la capacidad como una compra única. La realidad es que el consumo cambia según el día, la campaña, la demostración o el cierre de mes. Por eso la planificación se parece más a un ritual que a una decisión aislada: observas, ajustas y vuelves a observar. El objetivo de negocio es simple: que los usuarios encuentren el sistema disponible y rápido cuando toman decisiones, sin pagar de más por cómputo que nadie usa.
¿Por qué empezar esta semana y no en un proyecto grande?
Porque la observación temprana protege la confianza. Después de publicar un sistema de datos, observar cómo se comporta es lo que evita que dirección pierda la fe en las cifras. Si un informe se cae por sobrecarga en plena reunión, el problema no se percibe como técnico, se percibe como falta de rigor en los números.
Empezar esta semana significa hacer lo mínimo útil ya: mirar el consumo actual, identificar los momentos de tensión y practicar las operaciones básicas de capacidad antes de que las necesites en vivo. No hace falta rediseñar nada. Fabric ofrece herramientas distintas para preguntas distintas, y ninguna vista aislada sustituye una guía operativa. Lo que sostiene el sistema es el hábito, no una configuración perfecta de un solo día.
¿Qué herramienta responde cada pregunta de operación?
Fabric separa la observabilidad en piezas. Confundirlas hace perder tiempo, porque cada una responde algo distinto. Esta es la separación práctica:
| Herramienta | Pregunta que responde | Cuándo la usas |
|---|---|---|
| Monitoring Hub | ¿Qué ejecuciones corrieron, fallaron o tardaron? | Diagnóstico inicial diario |
| Workspace Monitoring | ¿Cuál es la tendencia y quiero alertas propias? | Investigación de patrones en el tiempo |
| Capacity Metrics | ¿Cuánto consumo hay y dónde está la sobrecarga? | Optimizar o escalar capacidad |
| OneLake Catalog | ¿Quién es responsable, cuál es el linaje y el gobierno? | Confianza y acceso sobre los datos |
Para capacidad, tu ancla es [Capacity Metrics](https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app): muestra el consumo de unidades, la sobrecarga y los patrones que ayudan a decidir si optimizas o escalas. Monitoring Hub te da el diagnóstico inicial de ejecuciones, y Workspace Monitoring conserva registros consultables para tendencias. Si quieres profundizar en cómo monitorear capacidad, cargas y fallos, conviene entender que cada vista aporta una parte; juntas forman el mapa de observabilidad.
¿Cómo se ve la guía operativa mínima de capacidad?
La operación de capacidad tiene un orden que conviene respetar para no dejar contenido no disponible por accidente. Estos son los pasos base:
- Confirmar que la CLI tiene sesión activa y que tu cuenta cuenta con rol de administración o de asignación en esa capacidad.
- Leer el workspace y las capacidades disponibles.
- Asignar el workspace correcto a la capacidad que corresponde.
- Pausar o reanudar mediante Azure o la Fabric API según la necesidad.
- Volver a comprobar el estado hasta que el workspace y la capacidad muestren lo esperado.
El punto crítico: pausar una capacidad puede dejar contenido no disponible, y la operación no termina cuando envías el comando, termina cuando verificas el estado final. Un pausado a medias es peor que no pausar, porque genera una caída silenciosa. Por eso la verificación por API no es un extra, es parte del procedimiento.
¿Qué rituales sostienen la capacidad en el tiempo?
La planificación de capacidad no es un evento, es una rutina. Estos son los rituales de operación que la mantienen sana:
- Control de cargas (cadencia diaria, o mayor si la criticidad lo pide): su meta es cazar cada fallo mientras todavía es invisible para quien consulta los informes.
- Operación de capacidad (antes y después de demostraciones o ventanas de carga intensa): encender o asignar capacidad cuando hace falta, retirar la asignación de una capacidad de pago o reasignar al terminar, y pausar la capacidad de pago cuando corresponde.
- Revisión de adopción (mensual): ver si el sistema se usa en decisiones reales y dónde necesita ajustes.
- Higiene del workspace (según cambios grandes): revisar modelos duplicados, elementos temporales e informes reconectados que inflan el consumo sin aportar valor.
El ritual que más ahorra dinero es el de capacidad ligado a ventanas de carga. Muchas organizaciones pagan cómputo encendido las 24 horas cuando solo lo necesitan durante una demostración o un cierre, y ahí es donde se decide cómo controlar los costos de la plataforma de datos. Pausar la capacidad de pago cuando corresponde, y verificar que quedó pausada, es una de las palancas más directas de eficiencia.
¿Qué probar antes de una demostración o una carga intensa?
Antes de mostrar el sistema a dirección o de una ventana de uso alto, conviene una prueba básica de consumo con el usuario o rol esperado, no solo con quien construyó la solución. Los pasos mínimos:
- Confirmar la capacidad activa antes de empezar.
- Probar el consumo real desde Power BI, Excel, Copilot o Data Agent, Teams y Fabric App según corresponda.
- Ejecutar la prueba con un usuario final, porque el creador suele tener permisos y cachés que ocultan problemas.
- Al cerrar, pausar o apagar la capacidad de demostración si corresponde, y verificar el estado.
Esta prueba evita la sorpresa más costosa: descubrir la sobrecarga en vivo. Observar el consumo con el usuario real antes del evento te da margen para escalar o reasignar sin apuro.
¿Cuál es el primer paso concreto para esta semana?
Abre Capacity Metrics y dedica quince minutos a leer el consumo de los últimos días. Identifica un pico y pregúntate qué lo causó. Después escribe tu primer ritual: un control de cargas diario y una rutina de pausar y reanudar antes de la próxima ventana intensa. Con eso ya estás planificando capacidad, no en teoría, sino en operación.
La capacidad se opera mejor cuando el modelo semántico ya funciona como un contrato claro entre las áreas: la infraestructura amplifica lo que ya está ordenado, no lo arregla. Si quieres ver cómo se ve ese orden aplicado, y evaluar si el camino para tu equipo pasa por formación, consultoría o ambas, mira la demo gratuita y decide con criterio hacia dónde llevar tu operación.
Preguntas relacionadas
¿Qué herramienta uso para ver el consumo de capacidad en Fabric?
Capacity Metrics. Muestra el consumo de unidades, la sobrecarga y los patrones que te ayudan a decidir si optimizas o escalas la capacidad. Monitoring Hub, en cambio, sirve para el diagnóstico inicial de ejecuciones y fallos.
¿Pausar una capacidad de Fabric deja los informes fuera de servicio?
Sí, pausar una capacidad puede dejar contenido no disponible. Por eso la operación no termina cuando envías el comando: termina cuando verificas por API que el workspace y la capacidad muestran el estado esperado.
¿Con qué frecuencia debo revisar la capacidad?
El control de cargas conviene hacerlo cada día, o con más frecuencia si la criticidad lo justifica, de modo que los fallos aparezcan antes que la desconfianza de quien lee los informes. La operación de capacidad se hace antes y después de demostraciones o ventanas de carga intensa.
¿Necesito un proyecto grande para empezar a planificar capacidad?
No. Esta semana basta con leer el consumo en Capacity Metrics, identificar los picos reales y definir un ritual básico de control de cargas y de pausar y reanudar. La planificación de capacidad es un hábito de operación, no una configuración única.
¿Por qué probar el consumo con un usuario final y no solo con quien creó la solución?
Porque el creador suele tener permisos y cachés que ocultan problemas de consumo. Probar Power BI, Excel, Copilot o Data Agent con el usuario o rol esperado revela la sobrecarga antes de una demostración, no durante ella.