Identificando e mapeando recursos: o que funciona na prática
O que são recursos e por que a maioria erra na identificação inicial
Quando eu falo em quais são os recursos, estou me referindo aos itens tangíveis e intangíveis que uma infraestrutura ou projeto precisa para funcionar. Isso abrange desde máquinas virtuais, storage, largura de banda e endereços IP até licenças de software, tempo de equipe e orçamentos. A definição parece óbvia, mas na hora de catalogar, as pessoas costumam perder uns 30% dos itens porque pensam apenas no óbvio. Eu vi isso acontecer em pelo menos meia dúzia de projetos aqui.
O problema principal é que os recursos existem em camadas. Tem o recurso direto, que é aquela VM ou conta de storage que você vê no painel. Tem o recurso indireto, que é a rede subjacente, os serviços de DNS, os certificados SSL vinculados. Tem ainda o recurso dependente, que é algo que não aparece na interface mas que se você remover causa queda no serviço inteiro. É esse último que mais causa dor de cabeça.
Minha abordagem prática sempre começa com um inventário em três colunas: direto, indireto e dependente. Coluna um recebe tudo que aparece no console da nuvem ou ferramenta de gestão. Coluna dois recebe os serviços de suporte que você contratou mas não vê como item unitário. Coluna três exige que você pergunte a cada membro da equipe técnica: "o que vai quebrar se isso sumir?" As respostas dessa pergunta são o que alimenta a terceira coluna. Na primeira vez que fiz esse mapeamento em formato de planilha simples, encontrei doze recursos dependentes que ninguém tinha documentado em lugar nenhum. Dois deles eram críticos para continuidade de operação.
Como listar recursos de forma que realmente funcione
A lista pura não serve pra nada se você não tiver pelo menos quatro campos mínimos por item. Eu uso sempre: nome, tipo, proprietário, estado e custo mensal ou de licenciamento. O campo proprietário é o que mais falta nas planilhas que vejo. Sem dono claro, o recurso vira coisa abandonada dentro de seis meses. Coloquei isso como padrão porque aprendi na marra depois que um serviço de produção ficou sem ninguém responsável por renovação de licença e caiu por forty-eight horas.
Para recursos de nuvem, eu particularmente uso o export de tags como ponto de partida. A maioria dos provedores permite exportar tudo que está taggeado em CSV ou JSON. Aí você cruza com a lista de custos e filtra itens sem tag. Os itens sem tag são exatamente os que fogem do controle. Esse filtro sozinho já te mostra onde está o desperdício oculto, que geralmente corresponde a uns quinze a vinte por cento do gasto total em infra.
Se você está lidando com recursos on-premise, o caminho é diferente. O inventário via SNMP ou WMI funciona bem para hardware. Para software, o melhor é cruzar o ativo registrado no CMDB com a realidade vista pelo scanning de rede. A diferença entre os dois listados é que você provavelmente encontra duplicidade, versões desatualizadas rodando sem documentação e licenças pagas mas não aplicadas. Esse gap entre documentação e realidade é normal. O importante é ter ele visível.
Pegadinhas comuns ao catalogar recursos
A primeira pegadinha séria é confundir recurso com funcionalidade. Um bucket S3 é um recurso. O backup automático configurado nele é uma funcionalidade. Você cataloga o bucket e anota a funcionalidade como observação, mas não trata os dois como o mesmo tipo de item. Misturar isso gera confusão na hora de alocar custo e responsabilidade.
A segunda é ignorar recursos efêmeros. Instâncias que sobem e descem sozinhas, containers transitórios, jobs batch que rodam em windows específicos do calendário. Esses aparecem nos logs mas não ficam na lista estática de recursos. Se o seu processo de inventário é manual e roda mensalmente, você vai perder tudo que for temporário. A solução prática é atrelar o inventário automático ao ciclo de vida dos recursos, não a uma data fixa no calendário. Ferramentas de IaC como Terraform ajudam muito aqui porque a lista de recursos vive no código e atualiza sozinha.
Outro erro frequente é não separar recursos pagos dos gratuitos. Recursos em tier gratuito de cloud ainda têm limite de quota, limite de egresso e consequências se estourarem. Um bucket gratuito que vira storage padrão porque alguém esqueceu as configurações de lifecycle gera uma conta surpresa no final do mês. Anotar como "livre com restrições" resolve isso na cabeça de quem tá gerenciando.
Custo e gestão: o que realmente importa
Saber quais são os recursos é só o primeiro passo. O segundo é entender o custo real de cada um, incluindo os custos ocultos. Custo direto é fácil. Custo indireto é onde a maioria das empresas perde dinheiro sem perceber. Um exemplo simples: uma VM rodando com disco provisionado de 500GB que usa 40GB. O custo direto é pelo disco total. O custo indireto é o espaço que poderia estar alocado para outra coisa. Isso parece teórico mas em infra de médio porte, esse tipo de inefficiência acumulada chega a custar o equivalente a duas ou três VMs paradas por mês.
Para gestão diária, eu recomendo manter uma única fonte da verdade. Pode ser uma planilha, um CMDB ou um painel de custo no provedor de nuvem. O importante é que todo recurso listado tenha um vínculo com dono e com valor. Se um item não tem dono, ele deveria estar em revisão obrigatória. Se não tem valor associado, deveria ser sinalizado para eliminação. Esse processo de revisão mensal leva uns quinze minutos em setups pequenos e cerca de uma hora em setups maiores. O ganho é evitar que recursos órfãos acumulem custo sem ninguém notar.
Quando a catalogação não funciona
Não adianta tentar mapear tudo em ambientes hyperdinâmicos onde recursos mudam a cada deploy. Nesse caso, a lista estática vira mentirosa em horas. A saída é migar para catalogação baseada em eventos. Em vez de uma lista fixa, você usa logs de mudança e alerts de configuração drift. Ferramentas como AWS Config, Azure Resource Graph ou soluções equivalentes on-premise fazem esse trabalho de monitorar state versus desired state. O detalhe é que isso exige configuração prévia. Se você não teve esse cuidado antes, entrar nesse modo depois de alguns meses de operação bagunçada gera um volume enorme de dados para processar.
Também tem o caso de recursos legacy que não têm API de integração. Servidores antigos, equipamentos de rede sem Gerenciamento remoto, softwares personalizados que só rodam em máquinas específicas. Nesses casos, o inventário manual ainda é a única opção. Eu mantenho uma aba extra na planilha chamada "manual – revisar trimestralmente". Não é bonito mas funciona.
Recursos vs dependências: onde a coisa fica confusa
Muitas vezes o que você cataloga como recurso é na verdade uma dependência de outro recurso. Um certificado SSL vinculado a um load balancer é recurso? Sim. Mas ele também é dependência do LB. Se você não registrar essa relação, ao remover o certificado por achar que não tem uso, o LB para de funcionar. A relação é o que importa tanto quanto o item isolado. Por isso eu sempre adiciono uma quinta coluna: "depende de". Ela é simples mas evita a maior parte dos incidentes causados por remoção acidental.
Em projetos de migração, essa coluna ganha peso extra. Quando você move uma aplicação pra nova infraestrutura, os recursos vão junto mas as dependências às vezes não. A aplicação nova pede conexão com um banco que ainda tá no old cluster. O IP mudou mas o DNS não foi atualizado. Essas conexões invisíveis aparecem só quando a coisa quebra. Ter a coluna de dependências documentada antes da migração corta pelo menos metade dos problemas pós-movente.
Quais são os recursos que você precisa acompanhar primeiro
Se você tá começando agora e não sabe por onde investir tempo, priorize esses quatro grupos: storage, rede, compute e identidade. Storage porque é o que mais cresce sem controle. Rede porque é o que mais causa downtime silencioso. Compute porque é o que mais consome custo operacional. Identidade porque é o que mais causa brechas de segurança quando negligenciado. Se der pra manter esses quatro atualizados e documentados, o resto tende a cair junto.
Na prática, eu reviso esses grupos toda segunda-feira de manhã em quinze minutos. Consigo identificar mudanças novas, itens sem dono, e recursos que precisam de ação imediata. O hábito de quinze minutos diários evita reuniões de duas horas pra resolver bagunça acumulada. Não é método perfeito mas é sustentável e funciona de fato.
