Airframe

Por qué Airframe

FinOps incluido

El presupuesto mensual de un producto se escribe una vez, en su entrada del catálogo, y todos los demás presupuestos lo siguen: la verificación que detiene un merge, los umbrales del panel de costos y los presupuestos de Google Cloud en los proyectos con facturación del producto. Un plan programado informa la deriva, así que un cambio hecho fuera de un merge request en algo que administra una raíz de Terraform aparece como un issue.

Un presupuesto, usado en todas partes

  1. Un número en el catálogo

    La entrada del catálogo lleva monthly_budget, en dólares estadounidenses, producción y no producción juntas. Las reglas de costo lo leen de la entrada, la raíz de Grafana fija con él los umbrales del panel de costos, y la fábrica de proyectos lo reparte 70 a 30 en un presupuesto de Google Cloud en cada proyecto con facturación, con alertas al 80 y al 100 por ciento.

  2. El merge request conoce el costo

    En cada aprobación, el ejecutor planifica cada raíz del producto, calcula el precio de cada plan con Infracost y publica una nota por raíz, con el costo mensual de esa raíz frente al presupuesto y lo que queda fuera. La compuerta de aprobación suma los costos mensuales de las raíces y fija la verificación Airframe cost del merge request: falla cuando el total o cualquier raíz por sí sola supera el presupuesto, o cuando no se pudo calcular el precio de una raíz, y GitLab mantiene cerrado el merge. El motivo de la verificación, que el ejecutor muestra en el log de su trabajo, da el total y la parte de cada raíz. El rechazo dice que hay que subir el presupuesto en el catálogo.

  3. El panel de costos lo muestra

    Un job diario lee la exportación de facturación y envía el costo de cada producto como métricas. La carpeta de Grafana de cada producto tiene un panel de costos: lo acumulado del mes y la proyección frente al presupuesto, en naranja al 80 por ciento y en rojo al 100. La raíz de Grafana lo crea, con sus umbrales tomados de monthly_budget, cuando se fusiona la entrada del catálogo del producto.

  4. La deriva se informa, no se oculta

    En la programación diaria de un repositorio, el job de deriva planifica cada raíz sin aplicarla. Cuando un plan no está vacío, la plataforma abre un issue para esa raíz con los recursos y sus acciones, nunca sus valores, lo reescribe mientras dura la deriva y lo cierra cuando la raíz vuelve a converger.

Pruébalo

Fija el presupuesto de un producto y un cambio planificado. El veredicto y el mensaje son los de la verificación de costos del paquete de políticas, con sus umbrales de la versión de la plataforma que describe este sitio.

Denegado
  • Denegado cost.budget

    the product's projected monthly cost, USD 45, is above its budget of USD 40 in the catalog: raise the budget by a catalog merge request approved by the domain's leads before this change can merge

    Se rechaza un cambio que lleve el costo mensual proyectado del producto por encima del presupuesto de su entrada del catálogo: el presupuesto se sube con un merge request del catálogo que aprueba un líder del dominio, o el cambio se hace más pequeño.

  • Advertencia cost.delta

    the change adds USD 25 a month (USD 20 to USD 45), above USD 10: platform approval

  • Advertencia cost.delta

    the change adds 125 percent a month (USD 20 to USD 45), above 25 percent: platform approval

    Un cambio que suma más de USD 10 o un 25 por ciento al mes está diseñado para necesitar la aprobación de la plataforma; hoy el paquete de políticas avisa en el merge request y no retiene nada. Partiendo de un costo de cero no hay porcentaje, así que solo se juzga el importe.

Fusión: bloqueada hasta que un merge request del catálogo suba el presupuesto

Qué lo hace cierto

Un cambio que supera el presupuesto no se puede fusionar.
La compuerta de aprobación fija la verificación de estado Airframe cost de cada merge request de producto a partir de los planes con precio que el ejecutor hizo de cada raíz en su head: falla cuando el total de las raíces o cualquier raíz supera el monthly_budget de la entrada, o cuando una raíz no tiene precio. El job de generación del dominio activa en el proyecto del producto la regla de que las verificaciones de estado deben pasar. Un plan en main también se detiene ante un rechazo registrado, así que nada rechazado se aplica. Los entornos de vista previa y los recursos que se cobran por uso quedan fuera de la cifra.
Subir un presupuesto requiere un líder de dominio.
La regla de responsables de la compuerta de aprobación exige la aprobación de un líder de dominio para un cambio en el catálogo que sube monthly_budget; cuando los líderes del dominio no tienen cuenta en GitLab, como en la demo, el equipo de plataforma los reemplaza.
Cada producto tiene un panel de costos frente a su presupuesto.
La raíz de Grafana de operations, que se ejecuta cuando cambia el catálogo, crea un panel de costos en la carpeta de cada producto del catálogo: lo acumulado del mes y la proyección frente al monthly_budget de la entrada, en naranja al 80 por ciento y en rojo al 100. Las cifras de costo vienen de la exportación de facturación a través del job diario cost:report.
La deriva se informa.
El job de deriva del componente tf-apply planifica cada raíz en la programación diaria del repositorio, y el componente drift-report, como la identidad de auditoría, mantiene un issue con la etiqueta audit::drift por cada raíz con deriva, lo reescribe y lo cierra cuando el plan vuelve a estar vacío.
Los presupuestos de Google Cloud siguen el mismo número.
La fábrica de proyectos del dominio crea un presupuesto en cada proyecto de producto con facturación a partir de monthly_budget, 70 por ciento para producción y 30 para no producción, con alertas al 80 y al 100 por ciento; la carpeta de la organización de demostración y la cuenta de facturación tienen sus propios presupuestos. Hoy ningún producto de la demo tiene facturación, así que ninguno tiene todavía los presupuestos de sus proyectos.