Alocação de custos na cloud: da etiquetagem à responsabilidade

Cloud · 3 min

Uma fatura de cloud só apoia decisões quando cada custo tem responsável. Saiba como definir metadados, tratar custos partilhados e escolher entre *showback* e *chargeback*.

Alocação de custos na cloud: da etiquetagem à responsabilidade

TL;DR

A alocação de custos na cloud é uma questão de governação: associar cada despesa a quem a pode influenciar.
A etiquetagem é o mecanismo mais comum, mas o seu valor depende da consistência e não costuma recuperar o histórico.
Um dicionário curto de chaves obrigatórias, com valores controlados e ligado a fontes de referência, é uma boa prática.
Os custos partilhados exigem critérios de repartição explícitos e aceites pelas equipas.
O showback dá visibilidade sobre os custos; o chargeback acrescenta imputação financeira e deve ser adotado quando fizer sentido para a organização.

Uma fatura consolidada não mostra quem decide

Com a adoção de cloud pública e híbrida, a fatura mensal tende a agregar dezenas ou centenas de serviços, subscrições e projetos numa única despesa. Para a direção financeira, o total pode ser suficiente, para quem gere TI, raramente é. Sem saber que aplicação, equipa ou ambiente gerou cada custo, torna-se difícil discutir otimização, prever orçamentos ou justificar investimento. A questão central é, por isso, organizacional antes de ser técnica: como associar cada euro gasto em cloud a quem tem capacidade para o influenciar. Na disciplina conhecida como *FinOps*, que junta finanças, tecnologia e negócio na gestão do consumo de cloud, esta prática designa-se alocação.

A etiquetagem falha sobretudo por falta de consistência

A etiquetagem de recursos, através de *tags* na AWS e no Azure ou de *labels* na Google Cloud, é o mecanismo mais comum para associar metadados de negócio aos custos. A documentação da Google Cloud dá exemplos como centro de custo, serviço e ambiente, e indica que as etiquetas são exportadas com os dados de faturação para análise. O desafio raramente está na funcionalidade, está na consistência. Chaves escritas de formas diferentes, valores livres e recursos criados sem etiqueta produzem relatórios em que uma parte relevante da despesa fica por atribuir. Acresce que, pelo menos na Google Cloud, os custos associados a uma etiqueta só são contabilizados a partir da data em que foi aplicada, pelo que uma correção tardia não recupera o histórico.

Um dicionário curto vale mais do que muitas etiquetas

A *FinOps Foundation* recomenda consolidar as normas de etiquetagem existentes, estabelecer convenções de nomes consistentes e sobrepor metadados organizacionais, como identificadores de aplicação, projeto ou centro de custo. Constitui uma boa prática começar com um conjunto reduzido de chaves obrigatórias, por exemplo responsável, aplicação, ambiente e centro de custo, com valores controlados. No Cloud Adoption Framework, a Microsoft recomenda que a estratégia de etiquetagem complemente a convenção de nomes e sirva de base à gestão de custos, à governação e à automação. Sempre que possível, os valores devem vir de uma fonte de referência, como o inventário de aplicações ou a [CMDB](/pt/blog/cmdb-gerir-dependencias-antes-do-incidente).

A política deve atuar no momento da criação

A consistência dificilmente se mantém com revisões manuais. As plataformas de cloud disponibilizam diferentes mecanismos de governação e automatização que podem ser utilizados para promover ou impor o cumprimento das políticas de etiquetagem durante o aprovisionamento de recursos. Em ambientes híbridos, a mesma identificação deve estender-se aos recursos locais e, quando aplicável, aos contratos de SaaS, para que os relatórios comparem realidades equivalentes. Uma plataforma de [gestão de cloud híbrida](/pt/solucoes/hybrid-cloud-management) pode ajudar a centralizar essa visão. Resta o problema dos custos partilhados, como conectividade, suporte, ferramentas transversais ou clusters comuns. Aqui, a decisão é de critério: repartir proporcionalmente ao consumo, aplicar uma percentagem fixa ou manter o custo numa rubrica central. Em plataformas de contentores, uma repartição credível depende de pedidos e limites de recursos bem definidos, tema desenvolvido em [gestão de capacidades no Kubernetes](/pt/blog/governacao-capacidade-kubernetes).

Showback e chargeback exigem maturidades diferentes

Com os custos atribuídos, falta decidir o que fazer com eles. No modelo de *showback*, cada equipa recebe informação sobre o que consumiu, sem impacto orçamental direto. No *chargeback*, o custo é efetivamente imputado ao orçamento da unidade. O segundo cria incentivos mais fortes, mas exige dados fiáveis, regras de repartição aceites e um processo para contestar valores. Aplicado cedo demais, pode desviar a discussão para a exatidão dos números em vez de a centrar nas decisões de consumo. Muitas organizações podem começar por showback para criar visibilidade e responsabilização. A evolução para chargeback não é, contudo, obrigatória: depende das políticas financeiras, da qualidade dos dados e do modelo de responsabilização pretendido. Há também limites a reconhecer: descontos por compromisso, créditos e alguns encargos não se associam facilmente a um recurso, e a alocação não substitui a otimização técnica nem a revisão do [licenciamento em cloud híbrida](/pt/blog/licenciamento-software-cloud-hibrida).

Atribuir custos é atribuir decisões

A alocação de custos na cloud é, sobretudo, um exercício de governação: transforma uma despesa agregada em informação que pode ser discutida por quem a gera. A etiquetagem é o meio mais comum, mas o seu valor depende de um dicionário curto, de valores controlados, de aplicação automática e de critérios explícitos para custos partilhados. O modelo adequado deve ser avaliado caso a caso, em função da maturidade dos dados, da cultura financeira e da estrutura da organização. Dificilmente uma fatura se torna totalmente atribuível, mas uma alocação consistente pode contribuir para decisões de consumo mais informadas e para conversas mais objetivas entre TI e finanças.