A jornada da equipe de desenvolvimento da AB180 na gestão de custos da AWS: da conferência da fatura à cultura de FinOps

Resumido com Gemini.

--

Operando a solução de mensuração de desempenho de marketing 'Airbridge', que processa enormes volumes de dados, construímos uma cultura estruturada de gestão de custos da AWS (FinOps). Compartilhamos as experiências e o know-how obtidos nesse processo.

Como a AB180 opera a gestão de custos:
Administramos os custos por meio dos seguintes processos.

• Dashboard baseado em Google Sheets: construímos um dashboard usando Google Sheets, que facilita o processamento e o compartilhamento dos dados. Além da situação de custos por tag, também exibimos o volume de dados coletados, que impacta diretamente os custos, para identificar de forma intuitiva as causas das variações. Também visualizamos a cobertura do Savings Plan e simulamos antecipadamente os resultados em caso de alteração contratual para apoiar decisões racionais.
• Verificação periódica e automatizada de custos: a cada duas semanas, revisamos as mudanças de custo em uma reunião curta de cerca de 30 minutos. Automatizamos ao máximo tarefas repetitivas, como geração do material da reunião, notificações no Slack e redação da ata, aumentando a eficiência. Quando a variação de custo é grande, o responsável analisa a causa e a compartilha por meio de comentários no Google Sheets, garantindo transparência.
• Estimativa de custos antes do desenvolvimento: ao desenvolver novas funcionalidades ou alterar a arquitetura, tornamos obrigatório calcular os custos previstos no documento de 'Tech Spec'. Isso permite tomar decisões técnicas melhores levando os custos em conta desde a fase de desenvolvimento.

Processo de evolução do sistema de gestão de custos:
O sistema atual não foi criado da noite para o dia. Ele evoluiu pelas seguintes etapas.

• Phase 0 (conferência da fatura): no início, nos limitávamos a verificar a fatura mensal.
• Phase 1 (classificação mínima): começamos a classificar minimamente os recursos usando a tag Name.
• Phase 2 (evolução da estratégia de tags): estabelecemos uma estratégia de tags baseada em políticas claras, como Team e Service. Como apenas distribuir um guia não era suficiente, vinculamos isso a políticas de IAM para obrigar a configuração de tags e criamos um mecanismo que envia alertas automáticos por bot no Slack para recursos sem tags. Como resultado, passamos a manter o custo de recursos sem tags abaixo de 1% do total.

Cinco lições aprendidas nessa jornada:

• Engenharia adequada ao contexto é importante. Em vez de buscar um sistema perfeito para controle de custos, é mais sensato construir gradualmente um modelo de gestão em um nível 'adequado' ao porte e à realidade da empresa.
• 'Controle' de custos e 'otimização' são coisas diferentes. 'Controle', que aumenta a previsibilidade dos custos, e 'otimização', que reduz o custo em si, são claramente distintos. É preciso decidir em qual deles focar de acordo com a prioridade do momento.
• É preciso automatizar com ousadia. Indo além da automação de tarefas repetitivas simples, a produtividade é maximizada quando se cria um ambiente de 'self-serve' em que os próprios colegas consultam os dados e identificam os problemas.
• É preciso criar 'mecanismos'. Em vez de dizer "vamos colocar as tags corretamente", é mais eficaz projetar 'dispositivos (mecanismos)' que obriguem o cumprimento da política, como não conceder permissões ao recurso se ele não tiver tags.
• FinOps é, no fim das contas, 'cultura'. O mais importante é trabalhar continuamente para criar uma cultura em que a gestão de custos não seja responsabilidade de uma pessoa específica, mas de todos que constroem o produto.

[tujuc]

Ah, entendi... então, se pelo menos aplicar as tags mais básicas, já ajuda bastante.. :)

Mas reduzir custos usando coisas como RI ou SP também entra no básico, né....
Imagino que definir mais ou menos qual tamanho faz sentido para usar na nossa infraestrutura seja mesmo uma parte que exige bastante reflexão...

[dongho42]

Isso até é mencionado no texto principal, mas eu criei separadamente um simulador de SP e, com base na carga de trabalho dos últimos n dias, calculava quanto SP adicional deveria comprar para minimizar a soma de "custo atual + custo que seria reduzido pela cobertura + custo que seria desperdiçado por se tornar recorrente"; foi assim que tomei a decisão.

[slave4salary]

Sou um funcionário atual da AWS kor.

Uma das formações mais importantes que ouvimos após entrar na empresa é pensar em maneiras de ajudar os clientes a gastar menos com custos de nuvem, e uma das formas mais eficazes é orientar sobre RI & SP.

[cocofather]

Por favor, reduzam a cobrança..

[toughrogrammer]

Mesmo que eu não conheça bem RI, no caso de SP ele pode ser aplicado a várias workloads, então, se houver um custo fixo recorrente, vale muito a pena considerar. Inclusive, nós chegamos a comprar já levando em conta até o momento previsto de otimização... rs Por exemplo, se em 9 meses a otimização já estiver concluída e parecer que o custo dos servidores vai cair pela metade, ainda assim comprar 1 ano inteiro antes pode sair mais vantajoso, e a gente fazia assim.