FinOps não é só tagged costs: como estruturar chargeback real para squads de engenharia

A ilusão do tagging como estratégia

Todo mundo começa com tags. É o passo óbvio, tem documentação farta e parece lógico: colocar team:dataplatform, environment:production, costcenter:CC001 em cada recurso e pronto, você tem visibilidade. O problema é que tags resolvem um problema de legibilidade, não de alocação real.

Considere um cenário comum: seu squad de dados roda Spark jobs em EMR que escalam de 10 para 200 instâncias durante um ciclo de ETL noturno. As tags estão lá. Mas quem pagou pelos 190 instânciashora extras? O job foi disparado por um pipeline orquestrado pelo Airflow, que está no squad de platform. A tabela de destino é do domínio do squad de analytics. A query que disparou o job foi escrita por um analista que nem tem team tag no IAM. Com tags puras, você tem um nome em um campo, não uma história de responsabilidade.

Tags sãoo sinal de trânsito, não o policial. Você precisa de alguém que interprete, normalize e decida, e esse alguém precisa de estrutura, não de boa vontade.

O modelo de camadas: do invoice ao squad

Chargeback real exige pensar em camadas de transformação de dados de custo. Não existe uma planilha mágica que saia do billing export e chegue no squad. Existe um pipeline.

A primeira camada é dado bruto: o export de billing do seu provider (AWS Cost and Usage Report, GCP BigQuery Billing Export, Azure Cost Management Export). São registros por linha de recurso, granulares até o segundo em alguns providers, com dimensões como account, service, usage type, region e, sim, tags.

A segunda camada é mapeamento e normalização. Aqui você junta os dados crus com seu inventário de infraestrutura (provavelmente no Terraform, Pulumi ou Helmfile). O objetivo é responder: "Este recurso X pertence a qual squad? Qual produto? Qual ambiente? Qual nível de serviço?" E mais importante: "Este recurso é compartilhado ou dedicado?"

Recursos compartilhados são onde a maioria das iniciativas de chargeback tropeça. Seu cluster EKS não é do squad de platform, ele existe para todos os squads. Seu VPC Endpoint para S3 é consumido por todo mundo. Seu NAT Gateway é impessoal. Se você ratear esses custos proporcionalmente, vai ter dor de cabeça política intensa a cada renegociação.

A terceira camada é rateio e alocação. Aqui entram as decisões de política: um recurso dedicado é alocado 100% para o owner. Um recurso compartilhado pode ser rateado por proporcional de uso (CPUhora, memóriahora, request count), por headcount do squad, ou por uma combinação. Não existe regra universal, existe contexto de negócio.

A quarta camada é markup e de lucro. Se você opera FinOps com mentalidade dechargeback (não deshowback), os squads precisam receber um custo que reflita o valor real do recurso para o negócio, não só o preço spot. Isso inclui overhead de operação, margem de contingência e, em modelos mais sofisticados, custo de capital.

flowchart TB
    subgraph L1["Camada 1 Fatura Bruta"]
        F1[Invoice Original]
        F2[Dados Fornecedor]
        F3[Linhas de Custo]
    end
    subgraph L2["Camada 2 Tagging Mapeamento"]
        T1[Categorizacao]
        T2[Tags Centro Custo]
        T3[Mapeamento GL]
    end
    subgraph L3["Camada 3 Alocacao Taxas"]
        R1[Rate Cards]
        R2[Conversao Moedas]
        R3[Ajuste Temporal]
    end
    subgraph L4["Camada 4 Markup Profit Center"]
        M1[Calculo Markup]
        M2[Margem Profit Center]
        M3[Rateio Indireto]
    end
    subgraph L5["Camada 5 Squad Chargeback"]
        S1[Alocacao por Squad]
        S2[Rateio Final]
        S3[Relatorio Carga]
    end
    L1 --> L2 --> L3 --> L4 --> L5
    style L1 fill:#1e3a5f,stroke:#2ecc71,color:#fff
    style L2 fill:#2c5282,stroke:#2ecc71,color:#fff
    style L3 fill:#2b6cb0,stroke:#2ecc71,color:#fff
    style L4 fill:#3182ce,stroke:#2ecc71,color:#fff
    style L5 fill:#4299e1,stroke:#2ecc71,color:#fff
    style F1 fill:#48bb78,stroke:#1e3a5f,color:#fff
    style F2 fill:#48bb78,stroke:#1e3a5f,color:#fff
    style F3 fill:#48bb78,stroke:#1e3a5f,color:#fff
    style T1 fill:#38a169,stroke:#1e3a5f,color:#fff
    style T2 fill:#38a169,stroke:#1e3a5f,color:#fff
    style T3 fill:#38a169,stroke:#1e3a5f,color:#fff
    style R1 fill:#319795,stroke:#1e3a5f,color:#fff
    style R2 fill:#319795,stroke:#1e3a5f,color:#fff
    style R3 fill:#319795,stroke:#1e3a5f,color:#fff
    style M1 fill:#3182ce,stroke:#1e3a5f,color:#fff
    style M2 fill:#3182ce,stroke:#1e3a5f,color:#fff
    style M3 fill:#3182ce,stroke:#1e3a5f,color:#fff
    style S1 fill:#2b6cb0,stroke:#1e3a5f,color:#fff
    style S2 fill:#2b6cb0,stroke:#1e3a5f,color:#fff
    style S3 fill:#2b6cb0,stroke:#1e3a5f,color:#fff

Showback versus chargeback: escolha consciente

Essa distinção é fundamental e frequentemente mal entendida.

Showback é mostrar aos squads o custo que eles geram, sem consequências financeiras reais. O squad vê o número, reflete e (teoricamente) otimiza. Em teoria. Na prática, showback funciona bem em organizações maduras com engineers que já têm cultura de custo e em empresas earlystage onde adicionar complexidade financeira é overengineering.

Chargeback é debitar o custo real na P&L do squad/product/team. Existe consequence financeira. O engineering manager tem budget e precisa explicar variação. Isso muda o jogo, mas exige que o modelo seja justo, compreensível e estável. Se o modelo de chargeback é (injusto, inexplicável ou errático), você não cria accountability, você cria desconfiança e cinismo.

Minha recomendação para empresas de 50 a 500 engenheiros: comece com showback por 23 trimestres para calibrar o modelo. Quando os dados estiverem bons e os squads estiverem confortáveis com a lógica, migre para chargeback. A tentativa de pular direto para chargeback sem calibração é o erro mais caro que você pode fazer, em termos de credibilidade política do time de FinOps.

Anatomia de um sistema de chargeback real

Vamos ao concreto. Um sistema minimamente viável para chargeback por squad precisa de:

Export diário de billing para um bucket GCS/S3/Blob, particionado por dia Pipeline de transformação rodando em schedule (dbt + Airflow, ou Spark, ou até uma CTE gigante no BigQuery se você quiser simplicidade brutal) Inventário de recursos sincronizado com seu IaC state (se você usa Terraform Cloud ou HCP Packer, tem APIs) Mapeamento dinâmico entre recurso e squad, não manual (ninguém vai atualizar planilha de mapeamento todo dia) Dashboard por squad que mostre: custo total, breakdown por service, tendência, top recursos, anomalias Alerting (nível squad) para quando o custo sair da banda esperada

Aqui vai um exemplo de como estruturar o mapeamento no Terraform para que seja rastreável downstream:

locals {
  ownership = {
    "emrcluster${var.environment}${var.team}" = {
      squad     = var.team
      product   = var.product
      cost_type = "dedicated"
      shared_with = [] # empty for dedicated, populated for shared
    }
    "ekscluster${var.environment}" = {
      squad     = "platform"
      product   = "infrastructure"
      cost_type = "shared"
      rate_key  = "computerequests" # how to split shared cost
    }
  }
}

Esse mapeamento pode ser exportado como JSON para seu pipeline de billing, criando um loop fechado entre infraestrutura como código e alocação de custo. Se o nome do recurso muda, o mapeamento muda. Se alguém cria recurso fora do Terraform, quebra o mapeamento, e isso é feature, não bug.

Números que você vai encontrar em produção

Com tagging puro, empresas tipicamente conseguem atribuir entre 40% e 60% dos custos totais. Os outros 4060% ficam como "Untagged" ou "Shared". Em uma empresa com R$ 2 milhões de conta mensal de cloud, isso significa R$ 800 mil a R$ 1,2 milhão que ninguém assume.

Com um modelo de camadas bem estruturado (inventário + mapeamento dinâmico + rateio de shared), empresas do porte de 100300 engenheiros tipicamente alcançam 8592% de atribuição. Os 815% restantes são custos residuais genuínos (taxas de transferência crossregion que não dá para isolar, por exemplo) e devem ser tratados como overhead operacional, não escondidos.

O impacto no comportamento é mensurável. Em um cliente que implementou chargeback real (não showback) com alocação granular, o squad de ML reduziu uso de GPU spot em 34% em um trimestre não por obrigação, mas porque o custo aparecia no board review do líder. O squad de platform consolidou 7 clusters EKS em 3 depois de ver o custo de management por cluster vs. economia de escala. Esses são os resultados que importam.

Armadilhas comuns e como evitálas

Custo por unidade inconsistente. Você mostra para o squad de dados que cada TB de S3 custa R$ 0,023/GB/mês, mas o CFO está sendo cobrado R$ 0,031/GB por causa de taxas de região eGlacier. Nunca mostre preço de lista ao squad se o que você paga é diferente. Use custo real, sempre.

Janela de análise desalinhada. Se o billing export tem 2448h de delay e você está mostrando custos no dia 5 do mês para um período que fechou no dia 1, você está criando confusão. Defina claramente: "Dados do dia X, com X dias de delay." Use um job que recalcule todo o histórico quando corrigir mapeamentos.

Modelo que muda no meio do jogo. Se em janeiro você alocou NAT Gateways por CPUhour e em fevereiro mudou para por request count, os squads não conseguem trend analysis. Versione seu modelo de alocação. Documente mudanças. Dê 30 dias de aviso antes de mudar política.

Ignorar custo de FinOps. Se seu time de FinOps tem 1 pessoa para 15 squads, o modelo vai degringolar. Estime: cada squad precisa de ~4h/mês de atenção do FinOps para, corrigir mapeamentos, revisar anomalias. Com 15 squads, são 60h/mês, quase 2 FTEs. Se você só tem 1 pessoa, ou automatize mais, ou priorize os squads críticos.

Checklist: seu modelo de chargeback está pronto?

• Billing export diário configurado e particionado por dia em storage durável
• Inventário de recursos sincronizado com IaC (Terraform state ou API)
• Mapeamento recurso → squad automatizado, não manual
• Recursos compartilhados identificados e política de rateio documentada
• Dashboard por squad publicado com breakdown por service e tendência
• Alertas de anomalia configurados (threshold baseado em baseline histórico)
• Modelo de alocação versionado e comunicada a política de mudanças
• Processos de correção de mapeamento documentados e tiempos de SLA definidos
• Review mensal com Finance para validar numbers e alinhar expectativas
• Migration path de showback para chargeback definido (se aplicável)

Chargeback não é projeto, é processo. Você vai calibrar, errar, corrigir e iterar. O importante é que cada iteração seja mais justa que a anterior, e que os squads a percebam como tal. Tagging é o chão do porão. Você merece subir as escadas.

Se sua empresa ainda mede FinOps em tags e planilhas, estamos a uma conversa de 30 minutos de estruturar um modelo que realmente funciona. Sem compromisso.

Fale com um especialista da Eficify