DEV Community

Francisco das Chagas
Francisco das Chagas

Posted on

Um terço da conta era para medir

Dois monitores numa mesa diante de racks de servidores: à esquerda, o pool de nós a 18% de CPU; à direita, os containers a 104% de memória, com o aviso de que o autoscaling dispara por CPU e não por memória. Na prancheta, o relatório de rateio aponta a observabilidade como cerca de um terço da conta.

Fiz o rateio da conta de infraestrutura por domínio de negócio.

O segundo maior item não era produto. Era observabilidade: cerca de um terço da conta, quase empatado com o produto principal.

E o que esse terço comprava:

  • 85,6% dos logs de produção não podiam ser atribuídos a nenhum serviço;
  • a ferramenta que media tudo não media a si mesma. Sem esse dado, o "um terço" podia ser 25% ou 44%, dependendo do tamanho real das máquinas dela.

No mesmo levantamento apareceu o outro lado:

  • as máquinas estavam a 18% de CPU, enquanto os containers passavam de 100% do próprio limite;
  • o autoscaling escalava por CPU um serviço que saturava por memória, então nunca acionou;
  • quase metade do ambiente de desenvolvimento ficava ociosa.

O gargalo não era falta de máquina. Era configuração, e corrigir configuração tem custo de licença zero.

A economia de maior retorno que encontrei não era trocar de ferramenta. Era corrigir o único ponto que gerava aqueles logs sem dono, com um alvo estimado de 30% a 40% do custo de observabilidade, sem perder nenhum sinal que alguém usa.

O que mudou a conversa com a gestão foi o custo por unidade de negócio. Todo negócio tem a sua: o pedido num e-commerce, a transação num banco, a consulta numa clínica, a entrega numa operação de logística, o aluno numa plataforma de ensino. "A infra custa X por mês" não leva a decisão nenhuma. "Cada unidade custa alguns centavos" leva. A pergunta "quanto custa atender mais um cliente?" passou a ter resposta.

Quanto a sua observabilidade custa em relação ao produto que ela observa?

Top comments (0)