Criar é a parte fotogênica. O trabalho adulto começa quando cada artefato recebe prazo, responsável, proteção e uma forma segura de sair de cena.

TL;DR

Automatizar a criação sem automatizar o ciclo de vida transfere custo, risco e confusão para o futuro. Imagens de containers, versões temporárias para avaliação, branches — versões de trabalho separadas —, artefatos de construção e backups não deveriam existir para sempre apenas porque ninguém definiu o fim. Limpeza segura não é apagar tudo que parece velho: é consultar uma fonte de verdade, proteger produção, manter um caminho de volta para uma versão que já funcionava — o rollback —, aplicar uma política de retenção, simular antes de remover, exigir evidência de desuso e preservar uma forma de recuperação. Se a automação não sabe distinguir memória operacional de abandono, ela ainda não está completa.

Hoje voltei a encontrar uma cena que não tem nada de rara na tecnologia.

Uma operação continuava pagando para armazenar imagens de software que não eram usadas havia mais de cinco anos.

Não porque alguém tivesse decidido preservar cinco anos de histórico. Não porque existisse uma exigência de auditoria, uma janela de recuperação ou uma versão antiga que ainda pudesse salvar a produção.

Elas continuavam ali porque ninguém sabia afirmar, com segurança, o que podia ser apagado.

Então ninguém apagava.

É uma forma curiosa de governança: a dúvida vira política de retenção e a fatura vira documentação.

A esteira ganhou automação. O depósito, não

Somos muito bons em automatizar começos.

Uma nova alteração versionada — um commit — dispara a construção automatizada, ou build. A construção gera um pacote. O pacote vira uma imagem. A imagem recebe uma etiqueta, ou tag: um nome como 1.4 ou latest que referencia seu manifest no registro de imagens. A versão temporária ganha um endereço de avaliação, o preview. O teste produz relatório, registro de execução — o log —, cópias temporárias para acelerar a próxima execução — o cache — e outros artefatos. Tudo acontece em minutos, às vezes em segundos.

Depois o trabalho termina — para nós.

Para a infraestrutura, ele apenas começou a ocupar espaço.

Cada execução bem-sucedida deixa alguma coisa para trás. Uma única sobra parece irrelevante. Milhares delas, atravessando anos, começam a cobrar armazenamento, dificultar inventário, preservar componentes que talvez precisassem ser retirados por segurança e tornar qualquer limpeza futura mais assustadora.

O problema aparece porque tratamos criação como fluxo e descarte como faxina.

Só que limpeza operacional, frequentemente chamada de cleanup, não deveria ser o mutirão constrangido que acontece quando o disco enche. Ela deveria ser parte do mesmo ciclo de vida que autorizou o artefato a existir.

Se uma automação sabe criar dez versões por dia, mas não sabe quando nove delas deixam de ter função, ela não eliminou trabalho.

Mandou a conta para o futuro com juros de contexto perdido.

Velho não é sinônimo de inútil

A resposta preguiçosa seria escolher uma idade e apagar tudo que a ultrapassasse.

Seria rápida. Também seria uma maneira eficiente de descobrir, tarde demais, que a versão “velha” era a última versão funcional disponível para rollback, que uma filial ainda dependia dela ou que o backup guardado com carinho não restaurava coisa nenhuma.

Idade é um sinal. Não é uma decisão.

Uma retenção pode ser necessária por razões diferentes:

• continuidade: manter a versão em produção e algumas versões comprovadamente utilizáveis para voltar atrás;
• rastreabilidade: preservar o artefato ligado a uma entrega, incidente ou decisão que ainda precisa ser auditada;
• obrigação: cumprir uma regra legal, contratual ou interna com prazo e responsável definidos;
• recuperação: guardar dados e configuração pelo período em que uma restauração ainda faz sentido;
• investigação: conservar evidência enquanto uma falha ou incidente permanece aberto.

Isso é retenção.

Outra coisa é encontrar centenas de versões sem consumidor conhecido, dono, data de expiração ou prova de que alguém conseguiria usá-las.

Isso não é memória institucional.

É abandono com redundância geográfica.

A imagem de um container não é uma caixa isolada

Quando falo em imagens, não estou falando de fotografias. Uma imagem de container é o pacote reproduzível usado para iniciar uma aplicação com suas dependências e sua configuração de sistema.

Ela também não é necessariamente um bloco independente.

A especificação da Open Container Initiative (OCI) chama de manifest o descritor que aponta para a configuração da imagem e para seus blocos reutilizáveis de conteúdo, chamados camadas. Camadas iguais podem ser compartilhadas por várias versões. Por isso, remover uma etiqueta não significa automaticamente liberar todos os bytes que o painel parecia atribuir àquela versão.

Em um registro operado com o Distribution — software aberto da Cloud Native Computing Foundation (CNCF) para armazenar e distribuir imagens de containers —, a coleta de lixo (garbage collection) remove blocos que já não são referenciados por nenhum manifest. A documentação oficial oferece uma simulação (dry-run) justamente para mostrar o que seria elegível antes de remover dados.

Essa simulação, porém, não transforma a execução real numa operação segura enquanto o registro continua recebendo dados. O Distribution exige que o registro esteja em modo somente leitura ou completamente parado durante a coleta: um upload concorrente pode ter suas camadas apagadas por engano e terminar como uma imagem corrompida. Primeiro se interrompem as escritas; depois se coleta. Inverter essa ordem é fazer backup da esperança e chamar de procedimento.

Essa diferença técnica reforça uma ideia maior:

“parece sem uso” e “pode ser removido com segurança” não são a mesma frase.

O próprio Docker adota uma limpeza conservadora: objetos sem uso não desaparecem automaticamente, e os comandos de prune mudam de alcance conforme as opções escolhidas. A cautela da ferramenta não substitui a política da empresa. Ela apenas evita que um padrão agressivo tome uma decisão que a infraestrutura não consegue compreender sozinha.

Digitar um comando com --force — que, nesse comando do Docker, apenas pula a confirmação — não cria contexto.

Só remove a última oportunidade de a ferramenta perguntar se alguém pensou antes.

O mesmo lixo ganha nomes diferentes

Imagens de containers tornam o problema visível porque armazenamento aparece na fatura. Mas a mesma ausência de ciclo de vida se espalha pela operação:

• previews de avaliação: cada versão candidata ganha um endereço temporário, mesmo depois que a mudança foi encerrada;
• branches: versões de trabalho separadas permanecem no repositório depois que a decisão foi incorporada ou abandonada;
• artefatos de build: pacotes, relatórios, logs e resultados intermediários sobrevivem muito além de sua utilidade;
• caches: aceleram o próximo trabalho até se transformarem numa coleção cara de passados que nunca voltarão;
• ambientes temporários: nascem para um teste de dois dias e descobrem a imortalidade administrativa;
• backups: acumulam cópias sem classificação, teste de restauração, prazo ou relação clara com o sistema atual.

O GitHub permite definir períodos de retenção para artefatos produzidos por fluxos automatizados (workflows) e apagar automaticamente branches de mudanças já incorporadas. O Cloudflare Pages documenta como apagar previews antigos e preserva a versão mais recente ligada a uma branch.

As ferramentas oferecem mecanismos.

Nenhuma delas conhece, por conta própria, a política inteira da sua operação.

Um preview antigo pode ser lixo. Também pode ser a avaliação de uma mudança ainda aberta, vinculada a uma branch. Uma branch ligada a uma mudança encerrada pode ser descartável. Também pode servir de base para outra mudança. Um backup de ontem pode ser suficiente. Também pode ter copiado perfeitamente uma corrupção de anteontem.

Por isso, apagar por idade sem consultar o estado real é trocar acúmulo por roleta-russa.

Primeiro encontre a fonte de verdade

Antes de construir a vassoura, eu preciso saber onde está a verdade operacional.

Qual imagem está efetivamente implantada? Quais versões de produção existem? Que mudanças ainda estão abertas e quais branches estão associadas a elas? Qual preview representa cada mudança? Quais pacotes foram publicados como releases? Quais dessas versões ainda recebem suporte? Que restauração foi testada? Existe retenção legal? Há um incidente preservando evidência?

Essas respostas raramente vivem no mesmo lugar.

O erro comum é eleger um painel isolado como juiz universal. O registro de imagens sabe quais versões armazena, mas pode não saber o que roda em outro ambiente. O provedor de previews conhece as implantações (deployments), mas não necessariamente o estado da avaliação. O repositório conhece branches, porém não todos os consumidores de uma imagem.

Uma rotina segura precisa compor essas fontes.

Se ela não consegue confirmar o que está ativo, protegido ou ainda em avaliação, deve falhar de forma segura: o CWE-636 é um item da Common Weakness Enumeration — o catálogo da MITRE para classificar fraquezas de software —; neste contexto, o princípio significa não apagar nada e explicar qual evidência faltou, em vez de presumir que a ausência de dados autoriza a exclusão.

O incômodo de revisar um relatório é menor que a elegância de automatizar um desastre.

O contrato de uma limpeza em que eu confio

Eu não confio numa rotina de cleanup porque ela tem um agendamento automático — uma tarefa cron padronizada pela família POSIX (Portable Operating System Interface) — bonita ou porque liberou muito espaço num teste.

Confio quando ela consegue responder a estas perguntas:

1. Quem é o dono? Alguém responde pela política, pelas exceções e pela revisão periódica.
2. Qual é a fonte de verdade? Produção, versões suportadas, mudanças abertas e retenções obrigatórias são descobertas em sistemas definidos.
3. O que está protegido? Produção, última versão funcional conhecida, configuração e artefatos necessários para voltar a ela, releases mantidas e evidências em retenção formam uma lista que não depende apenas da idade.
4. Qual é a janela de retenção? Cada classe tem prazo próprio. Preview não precisa seguir a mesma regra de backup; log não precisa imitar release.
5. Existe evidência de desuso? A ausência de referência, implantação, branch existente ou consumidor pesa mais que “faz tempo”.
6. A primeira execução é uma simulação? A rotina lista o que removeria, por qual regra e com qual impacto estimado antes de tocar nos dados.
7. Há limite de impacto? Quantidade máxima, idade mínima, execução em lotes e pausa diante de divergência impedem uma falha de varrer tudo de uma vez.
8. Existe volta? Quando a plataforma oferece restauração, a janela precisa ser conhecida. Quando não oferece, o conjunto protegido deve ser suficiente para reconstruir.
9. Fica um rastro? A execução registra regra, identificador, motivo, horário e resultado sem despejar segredos em logs.
10. A política é reutilizável? Quando vários projetos compartilham o mesmo provedor e as mesmas proteções, a lógica deveria viver num fluxo central, testado e versionado, em vez de ganhar cópias divergentes.

O GitHub chama essa última capacidade de workflow reutilizável: um fluxo central pode ser chamado por vários repositórios, reduzindo duplicação e concentrando manutenção. Reutilizar não significa fingir que todos os projetos são iguais. Significa centralizar a lógica comum e tornar diferenças explícitas como entradas.

Uma política boa também começa pequena.

Primeiro, inventário. Depois, simulação. Em seguida, a remoção de uma classe de baixo risco, a observação do resultado e só então a ampliação do alcance.

Isso é menos cinematográfico que executar “limpar tudo”.

É também consideravelmente melhor para quem gostaria de continuar empregado na manhã seguinte.

Backup sem ciclo de vida também pode virar acúmulo

Eu defendo backup. Já escrevi que backup é método e liberdade para preservar opções.

Mas “guardar tudo para sempre” não é uma estratégia de recuperação.

Um conjunto de backups precisa dizer:

• o que foi copiado;
• com que frequência;
• por quanto tempo cada classe permanece;
• onde existe uma cópia independente;
• como integridade e restauração são testadas;
• que chaves, configuração e documentação são necessárias para recuperar;
• quando uma retenção especial impede o descarte normal.

Sem isso, o backup pode ocupar espaço indefinidamente e ainda falhar no único momento em que importa.

A distinção é simples: retenção preserva uma capacidade conhecida; acumulação preserva uma dúvida.

O ciclo de vida é parte da entrega

Durante muito tempo tratamos remoção como assunto secundário. A equipe boa seria a que coloca coisa no ar. A retirada ficaria para quando alguém tivesse tempo, o armazenamento reclamasse ou uma auditoria perguntasse por que ainda existia aquilo que todos juravam ter apagado.

Essa visão está incompleta.

Entregar um sistema também significa saber atualizar, observar, recuperar, aposentar e remover seus artefatos. Foi por atravessar a esteira inteira — requisito, arquitetura, implementação, infraestrutura, monitoramento, segurança, backup e continuidade — que aprendi a desconfiar de soluções que mostram apenas o nascimento.

Na i-9.ai, esse cuidado aparece como contrato operacional: o que a automação pode criar, como verificamos que ainda serve, quem decide sua retenção e em que condições ela pode sair sem levar a produção junto.

Não é uma obsessão por apagar.

É o contrário: é saber por que cada coisa continua existindo.

Porque, se toda esteira automatizada — todo pipeline — termina em “guardar para vermos depois”, o futuro deixa de ser uma direção.

Vira um depósito.

E depósito sem inventário é apenas uma fatura com corredores.

Para se aprofundar

Documentação oficial consultada em 30 de agosto de 2026:

• Open Container Initiative — Image Manifest Specification: estrutura técnica de manifests, configuração e camadas de uma imagem.
• Open Container Initiative — Distribution Specification: define como tags nomeadas referenciam manifests num registro; não determina a política de retenção de uma empresa.
• Git — git commit: como uma alteração versionada registra mudanças no histórico do repositório.
• GitHub Actions — Dependency caching: diferença entre cache reaproveitável e artefatos preservados após uma execução, incluindo binários construídos e logs de build.
• Docker Docs — Prune unused Docker objects: mecanismos e diferenças de alcance para limpar objetos Docker sem uso.
• Cloud Native Computing Foundation (CNCF) Distribution — Garbage collection: marcação de referências, objetos elegíveis, modo de simulação e a exigência de impedir escritas durante a coleta para evitar imagens corrompidas.
• The Open Group — crontab: especificação da família POSIX (Portable Operating System Interface), conjunto de padrões para interfaces portáveis de sistemas operacionais, aplicada ao agendamento de trabalhos periódicos.
• MITRE — CWE-636: Not Failing Securely: item 636 da Common Weakness Enumeration (CWE), catálogo de fraquezas de software mantido pela MITRE; explica o risco de uma falha conduzir o sistema a um estado menos seguro.
• Ubuntu — Release cycle: exemplo concreto de versões publicadas com janelas de suporte distintas, mostrando por que “foi lançado” e “ainda recebe suporte” são estados separados.
• Amazon Web Services (AWS) CodeDeploy — Redeploy and roll back a deployment: exemplo concreto de retorno a uma revisão da aplicação que já funcionava.
• GitHub Docs — Reusing workflow configurations: como centralizar fluxos repetíveis em workflows reutilizáveis.
• Cloudflare Pages — Preview deployments: ciclo de previews, endereços ligados a branches e exclusão de implantações antigas.

Referências e limites de uso

• A documentação do Docker sustenta que objetos sem uso não são removidos automaticamente e explica o alcance dos comandos de prune. Ela não define qual retenção é adequada para uma empresa específica.
• As documentações do Git e do GitHub Actions sustentam o vocabulário de commit, artefato, log e cache nos respectivos ecossistemas. Elas não definem o ciclo de vida de todas as ferramentas de construção e publicação.
• A especificação OCI e a documentação do Distribution sustentam a relação entre manifests, camadas referenciadas e coleta de lixo nesse software de registro, inclusive o risco de corrupção durante uploads concorrentes. Outros registros podem implementar exclusão, retenção e restauração de forma diferente.
• A especificação POSIX sustenta o significado de uma tarefa cron; ela não torna seguro o trabalho que foi agendado.
• O CWE-636 sustenta o princípio geral de não cair num estado menos seguro diante de uma falha. Sua aplicação a uma rotina de cleanup — recusar a exclusão quando falta evidência — é uma síntese operacional do artigo.
• O ciclo do Ubuntu ilustra que publicação e suporte têm datas e estados diferentes. Ele não define a política de ciclo de vida de todos os produtos.
• A documentação do AWS CodeDeploy sustenta o exemplo de voltar a uma revisão da aplicação que já funcionava. Ela não define um comportamento universal: o alcance e a forma de recuperação variam conforme a plataforma.
• A documentação do GitHub sustenta a configuração de retenção de artefatos, exclusão automática de branches associadas a mudanças incorporadas e reutilização de workflows. Ela não prova economia nem garante que uma regra genérica reconheça todos os consumidores externos.
• A documentação do Cloudflare sustenta o comportamento e a exclusão de previews do Pages. O exemplo não autoriza apagar uma avaliação cuja branch ou função operacional ainda esteja ativa.
• O caso de artefatos mantidos por mais de cinco anos é uma percepção autoral anonimizada. Ele ilustra ausência de ciclo de vida; não demonstra custo médio, desperdício universal nem retorno financeiro de uma rotina de cleanup.

Continue lendo

• Especialista em IA desde anteontem
• Escreveu, não leu: a IA não assina por você
• Sua empresa não precisa descobrir onde colocar IA