Airframe

Por que o Airframe

FinOps incluído

O orçamento mensal de um produto é escrito uma vez, na sua entrada do catálogo, e todos os outros orçamentos o seguem: a verificação que segura um merge, os limites do painel de custos e os orçamentos do Google Cloud nos projetos faturados do produto. Um plano agendado relata o desvio, então uma mudança feita fora de um merge request em algo que uma raiz do Terraform gerencia aparece como uma issue.

Um orçamento, usado em toda parte

  1. Um número no catálogo

    A entrada do catálogo traz monthly_budget, em dólares americanos, produção e não produção juntas. As regras de custo o leem da entrada, a raiz do Grafana define com ele os limites do painel de custos, e a fábrica de projetos o divide 70 para 30 num orçamento do Google Cloud em cada projeto faturado, com alertas em 80 e 100 por cento.

  2. O merge request sabe o custo

    Em cada aprovação, o executor planeja cada raiz do produto, calcula o preço de cada plano com o Infracost e publica uma nota por raiz, com o custo mensal dessa raiz diante do orçamento e o que fica de fora. O controle de aprovação soma os custos mensais das raízes e define a verificação Airframe cost do merge request: ela falha quando o total ou qualquer raiz sozinha passa do orçamento, ou quando não foi possível calcular o preço de uma raiz, e o GitLab mantém o merge fechado. O motivo da verificação, que o executor mostra no log do seu job, traz o total e a parte de cada raiz. A recusa diz para aumentar o orçamento no catálogo.

  3. O painel de custos mostra

    Um job diário lê a exportação de faturamento e envia o custo de cada produto como métricas. A pasta do Grafana de cada produto tem um painel de custos: o acumulado do mês e a previsão contra o orçamento, em laranja a 80 por cento e em vermelho a 100. A raiz do Grafana o cria, com os limites tirados de monthly_budget, quando a entrada do catálogo do produto recebe o merge.

  4. O desvio é relatado, não escondido

    No agendamento diário de um repositório, o job de desvio planeja cada raiz sem aplicá-la. Quando um plano não está vazio, a plataforma abre uma issue para essa raiz com os recursos e as suas ações, nunca os seus valores, reescreve a issue enquanto o desvio dura e a fecha quando a raiz volta a convergir.

Experimente

Defina o orçamento de um produto e uma mudança planejada. O veredito e a mensagem são os da verificação de custo do pacote de políticas, com os limites da versão da plataforma que este site descreve.

Negado
  • Negado 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

    Uma mudança que leve o custo mensal projetado do produto acima do orçamento da sua entrada no catálogo é recusada: o orçamento é aumentado por um merge request do catálogo que um líder do domínio aprova, ou a mudança fica menor.

  • Aviso cost.delta

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

  • Aviso cost.delta

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

    Uma mudança que soma mais de USD 10 ou 25 por cento ao mês é projetada para precisar da aprovação da plataforma; hoje o pacote de políticas avisa no merge request e não retém nada. A partir de um custo zero não há percentual, então só o valor é julgado.

Merge: bloqueado até que um merge request do catálogo aumente o orçamento

O que torna isso verdade

Uma mudança acima do orçamento não pode receber merge.
O controle de aprovação define a verificação de status Airframe cost de cada merge request de produto a partir dos planos com preço que o executor fez de cada raiz no seu head: ela falha quando o total das raízes ou qualquer raiz passa do monthly_budget da entrada, ou quando uma raiz não tem preço. O job de geração do domínio ativa no projeto do produto a regra de que as verificações de status precisam passar. Um plano na main também para diante de uma recusa registrada, então nada recusado é aplicado. Os ambientes de pré-visualização e os recursos cobrados por uso ficam fora do número.
Aumentar um orçamento exige um líder de domínio.
A regra de responsáveis do controle de aprovação exige a aprovação de um líder de domínio para uma mudança no catálogo que aumenta monthly_budget; quando os líderes do domínio não têm conta no GitLab, como na demo, a equipe de plataforma os substitui.
Todo produto tem um painel de custos contra o seu orçamento.
A raiz do Grafana de operations, que roda quando o catálogo muda, cria um painel de custos na pasta de cada produto do catálogo: o acumulado do mês e a previsão contra o monthly_budget da entrada, em laranja a 80 por cento e em vermelho a 100. Os números de custo vêm da exportação de faturamento pelo job diário cost:report.
O desvio é relatado.
O job de desvio do componente tf-apply planeja cada raiz no agendamento diário do repositório, e o componente drift-report, como a identidade de auditoria, mantém uma issue com o rótulo audit::drift por raiz com desvio, reescreve a issue e a fecha quando o plano volta a ficar vazio.
Os orçamentos do Google Cloud seguem o mesmo número.
A fábrica de projetos do domínio cria um orçamento em cada projeto de produto faturado a partir de monthly_budget, 70 por cento para produção e 30 para não produção, com alertas em 80 e 100 por cento; a pasta da organização de demonstração e a conta de faturamento têm os seus próprios orçamentos. Hoje nenhum produto da demo é faturado, então nenhum tem ainda os orçamentos dos seus projetos.