A fatura conta o que aconteceu, não porquê
Todos os meses chega a fatura do fornecedor cloud. Traz um total, um detalhe por serviço e milhares de linhas de utilização. É exata e, mesmo assim, quase nunca responde à pergunta que importa quando o valor sobe: porquê?
A fatura foi pensada para cobrar, não para decidir. Agrupa pelo que o fornecedor vende (horas de computação, gigabytes armazenados, pedidos), não pelo que a sua organização faz (produtos, equipas, clientes). Enquanto o custo for lido apenas a partir da fatura, cada aumento acaba na mesma reunião: alguém olha para o total, ninguém sabe o que mudou e a conclusão é "é preciso cortar", sem saber onde.
Três perguntas que a fatura não responde
Quem o consome? Um mesmo serviço de base de dados pode estar a servir três aplicações de três equipas diferentes. A fatura mostra-o como uma única linha.
Para que produto ou cliente? Se não sabe quanto custa servir um produto, não sabe se esse produto é rentável. Também não consegue explicar porque é que o custo cresceu quando o negócio cresceu, ou se cresceu sem que o negócio o fizesse.
Quanto deveria custar? Sem uma referência, qualquer valor parece razoável ou alarmante consoante o dia. O custo só se compreende quando comparado com algo: o mês anterior, uma estimativa feita antes da implementação ou o custo por unidade de negócio (por utilizador, por transação, por cliente).
O que muda quando o custo é normalizado
O primeiro obstáculo é técnico: cada fornecedor descreve a sua faturação com o seu próprio formato, as suas próprias colunas e os seus próprios nomes. Comparar AWS com Azure ou com GCP, ou simplesmente somá-los, obriga a traduzir à mão.
O FOCUS (FinOps Open Cost and Usage Specification) é a norma aberta da FinOps Foundation que resolve isso: define um formato comum para os dados de custo e utilização, de modo que a faturação de diferentes fornecedores possa ser lida com as mesmas colunas e as mesmas regras. Os grandes fornecedores já oferecem exportações nesse formato, ou estão a incorporá-lo.
Com o custo normalizado, as três perguntas deixam de ser impossíveis:
- Quem o consome resulta da atribuição: etiquetas e contas que atribuem cada recurso a uma equipa e a uma aplicação.
- Para que produto resulta de agrupar essa atribuição por aquilo que a organização vende.
- Quanto deveria custar resulta de comparar com uma estimativa prévia e de medir o custo por unidade.
Por onde começar
Não é preciso uma plataforma para dar o primeiro passo. É preciso ordem:
- Inventário de contas e exportações. Saber que contas, subscrições e projetos existem em cada cloud e ativar a exportação detalhada da faturação em todas.
- Normalizar com FOCUS. Levar essas exportações para um formato comum, num só sítio, para as poder somar e comparar.
- Atribuir responsáveis. Etiquetar recursos por aplicação e equipa, e decidir o que fazer com o que não tem etiqueta (que, no início, será muito).
- Escolher uma métrica de unidade e revê-la todos os meses. Uma só, ligada ao negócio, com um responsável que a explique quando se mexer.
O objetivo não é gastar menos a qualquer preço. É que cada aumento do custo tenha uma explicação, e que essa explicação chegue antes da fatura seguinte.
Em resumo
A fatura cloud é um documento de cobrança. Para decidir é preciso outra coisa: o custo normalizado, atribuído e comparado. Quando isso existe, a conversa deixa de ser "porque é que subiu?" e passa a ser "vale o que custa?".
Se o seu custo cloud cresce sem que ninguém saiba porquê, em Engenharia FinOps está a forma como o abordamos.