Saltar al contenido

FinOps

Menú

Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.

Guardar progreso

Lección 4 de 5

Compute policies y budgets

Impone guardrails con compute policies y atribuye serverless mediante usage policies sin incluir información sensible en tags.

17 min aprox.

Detalles

Compute, políticas, etiquetas y costes

Atribuye consumo, controla guardrails y optimiza coste sin degradar el valor del workload.

Reto observable

Construye un informe de coste atribuible y propone tres guardrails cuantificados que reduzcan gasto sin incumplir el SLA.

Al terminar podrás
  • Consultar costes con system tables
  • Etiquetar y atribuir consumo
  • Elegir modos serverless y políticas
Prerrequisitos
m24
Última revisión
25 ago 2026
Nivel
Professional
Ruta relacionada
performance
Dominios blueprint
Cost optimization · System tables
Estado
Revisión editorial interna
Fuentes principales
Compute selection recommendations · Best practices for serverless compute
Reportar un error
04
Diagnóstico

Compute policies y budgets

Impone guardrails con compute policies y atribuye serverless mediante usage policies sin incluir información sensible en tags.

Las compute policies restringen la creación de compute clásico: pueden fijar runtime, modo de acceso, Photon, límites de workers, autotermination y tags. Las familias de políticas aportan bases mantenidas por Databricks. Una buena policy reduce opciones peligrosas y deja editables sólo parámetros que el equipo debe decidir; instalar librerías mediante policies es preferible a init scripts.

Serverless usage policies son objetos distintos que asignan tags de coste a notebooks, jobs, pipelines y otros workloads serverless. Sus tags aparecen en `system.billing.usage.custom_tags`. Los tags viajan a registros y pueden replicarse globalmente: usa centro de coste, producto y entorno, nunca correo, nombre de cliente o datos confidenciales. Recuerda que un pipeline disparado por un job conserva su propia policy.

JSONFragmento de compute policy con guardrails
{
  "autotermination_minutes": {
    "type": "range",
    "maxValue": 60,
    "defaultValue": 20
  },
  "autoscale.max_workers": {
    "type": "range",
    "maxValue": 12,
    "defaultValue": 4
  },
  "custom_tags.cost_center": {
    "type": "fixed",
    "value": "finance-data"
  }
}

Completa la policy con familia y reglas del workspace; prueba que usuarios previstos pueden crear compute y no pueden superar guardrails.

¿Dónde aparecen los tags heredados de una serverless usage policy?

Profundiza

Una policy es una barandilla ejecutable: transforma estándares de coste, seguridad y soporte en opciones permitidas antes de que nazca el compute. No reemplaza RBAC ni decide quién puede leer datos; limita cómo se configura la infraestructura, por ejemplo runtime, familia, Photon, autoscaling, autotermination o tags. En serverless, una usage policy sirve para atribuir consumo según metadatos y contexto disponibles, no para insertar secretos en etiquetas. La buena gobernanza ofrece caminos aprobados para clases de workload, con defaults sensatos y límites explícitos. Una policy demasiado abierta no controla; una demasiado rígida provoca excepciones manuales y equipos que mezclan cargas incompatibles en un único recurso.

Compute policy

Conjunto de reglas que limita y predetermina atributos al crear compute clásico.

Previene configuraciones inseguras o costosas sin depender de revisión manual posterior.
Usage policy

Mecanismo de clasificación y atribución del consumo de productos serverless.

Permite FinOps cuando no existe un clúster propio al que adjuntar tags tradicionales.
Taxonomía de coste

Vocabulario controlado de dimensiones como centro, entorno, producto y clase de workload.

Hace que la atribución sea agregable y evita cientos de etiquetas equivalentes o sensibles.
Resumen

Puntos clave

  • Compute policies gobiernan configuración clásica; serverless usage policies atribuyen actividad serverless.
  • Fija y oculta guardrails, permite sólo decisiones necesarias.
  • Los tags no son un almacén seguro para datos personales o secretos.

Evita

  • Usar la misma etiqueta `Name` que Databricks aplica al clúster y romper atribución/terminación.
  • Incluir identificadores personales o secretos en tags de coste.

Vista de lectura · sin ejecución

databricks-finops-system-tables

databricks-finops-system-tables · commit 7834d5d

README.md

Módulo 25

Contenido del módulo