Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 4 de 5
Right-sizing y coste
Controla el gasto del incidente sin sacrificar evidencia ni convertir un aumento temporal de compute en deuda permanente.
- Duración
- 30 min aprox.
- Objetivo
- Controla el gasto del incidente sin sacrificar evidencia ni convertir un aumento temporal de compute en deuda permanente.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Proyecto de fiabilidad y coste
Recupera un workload degradado equilibrando SLA, capacidad, layout, código y presupuesto.
- Resolver un incidente con método
- Demostrar mejora con métricas
- Definir prevención y alertas
04DiagnósticoRight-sizing y coste
Controla el gasto del incidente sin sacrificar evidencia ni convertir un aumento temporal de compute en deuda permanente.
+
Right-sizing y coste
Controla el gasto del incidente sin sacrificar evidencia ni convertir un aumento temporal de compute en deuda permanente.
Durante un incidente puede ser racional aumentar temporalmente capacidad para restaurar un SLA, pero registra quién lo aprobó, duración máxima y rollback automático. `system.billing.usage` permite atribuir el run y comparar coste por ejecución. Una reparación que reduce runtime pero duplica coste no es mejora salvo que el impacto evitado justifique esa compensación.
Después de estabilizar, elimina recursos temporales, restaura límites de policies y calcula coste de reintentos, backfill y mantenimiento. Distingue coste causado por el incidente del baseline. Los presupuestos alertan; no sustituyen un control operativo de concurrencia, autotermination y modos serverless adecuados.
Modelo mental
Durante un incidente, el coste es una restricción y una señal, no el objetivo principal. Escalar temporalmente puede ser la decisión más barata si reduce una interrupción costosa, pero debe llevar caducidad, propietario y criterio de retirada. Recortar compute mientras se recopila evidencia puede prolongar el fallo o borrar logs; dejarlo ampliado indefinidamente convierte mitigación en nueva línea base. El análisis une coste incremental con tiempo de recuperación, backlog, riesgo de integridad y valor del servicio. También distingue compute útil de retries fallidos, scans repetidos y backfills solapados. La disciplina FinOps del incidente consiste en gastar conscientemente para recuperar y volver después a una configuración medida, no en bloquear acciones urgentes por presupuesto horario.
Diferencia de gasto atribuible al incidente y sus mitigaciones respecto a una línea base comparable de operación normal.
Permite evaluar decisiones urgentes sin confundir crecimiento ordinario con compute, retries o backfills extraordinarios.Fecha, condición o automatismo que obliga a revisar y retirar una configuración temporal de emergencia.
Impide que un escalado útil durante la crisis permanezca indefinidamente como gasto y deuda no examinados.Estimación del impacto de negocio o riesgo que no ocurrió gracias a una mitigación suficientemente rápida y segura.
Da contexto al gasto adicional y evita optimizar sólo la factura mientras aumenta la pérdida del servicio.SELECT
usage_date,
usage_metadata.job_id AS job_id,
sku_name,
SUM(usage_quantity) AS usage_quantity
FROM system.billing.usage
WHERE usage_metadata.job_id = '482901'
AND usage_date BETWEEN DATE '2026-07-18' AND DATE '2026-07-21'
GROUP BY usage_date, usage_metadata.job_id, sku_name
ORDER BY usage_date;Une precios para moneda y compara con días sanos equivalentes; conserva correcciones de uso.
Puntos clave
- Todo escalado de emergencia necesita caducidad y rollback.
- Compara coste por run y cumplimiento de SLA.
- Incluye reintentos y backfills en el coste total del incidente.
Evita
- Dejar un warehouse o clúster sobredimensionado después de la mitigación.
- Omitir el coste de retries y backfills al evaluar la solución.
Recuerdo activo