A Maldição De Sísifo

O problema que ninguém resolve de verdade

Todo mundo conhece a história do Sísifo empurrando a pedra morro acima. O que pouca gente admite em público é que a maior parte do trabalho técnico atual se parece muito com isso. Você passa semanas consolidando algo, a infraestrutura ou o processo muda, e a pedra volta a rolar. Não é drama grego. É arquitetura. A maldição de sísifo não aparece só em mitos. Ela aparece quando você entrega um deploy, um relatório, uma migração, e no dia seguinte precisa reconstruir porque a validação não ficou selada no sistema. A sensação é específica: cansaço administrativo, não físico. A fadiga vem da repetição visível, não do esforço em si.

A maldição de sísifo na prática

Eu lido com isso todo dia. Em 2022, migrei um conjunto de jobs ETL para Airflow num ambiente que não tinha versionamento de DAGs nem controle de configuração. A cada atualização do Python da máquina virtual, o scheduler travava. Corrigia, rodava, o time mudava variáveis de ambiente sem avisar, e o ciclo recomeçava. Levei cerca de três semanas para perceber que o gargalo não era o código. Era a ausência de imutabilidade nos artefatos de deploy. A solução que funcionou foi simples e nada heroica. Travei as dependências com poetry.lock, separei o perfil de ambiente em arquivos estáticos, e passei a validar a DAG antes de qualquer merge com um check que conferia imports, variáveis obrigatórias e formato do schedule. O tempo de correção pós-merge caiu de horas para minutos. O ciclo ainda existe, mas agora ele tem bordas definidas. Diferença importante.

Como identificar quando você está no loop

A primeira coisa é parar de tratar o sintoma como progresso. Se você passa mais de dois dias corrigindo o mesmo problema em versões diferentes, não está avançando. Está apenas ocupado. Anota os dados. Mede o tempo entre o primeiro erro e a correção real. Se esse intervalo não diminuir com o tempo, o sistema está te cobrando um imposto de repetição. Outro indicador claro é a falta de estado visível. Quando uma saída depende de variáveis que não estão registradas em lugar nenhum, você não tem trabalho. Tem adivinhação. Mapeie cada dependência que seu processo exige. Se três delas são "apenas configuração do servidor", sua pedra vai rolar de novo. Sempre.

O plano que evita o colapso

Não existe cura. Existe contenção. Eu divido o trabalho em três camadas: definição, execução e registro. A maioria dos times falha na primeira e na terceira, porque consideram essas etapas " documentação", como se documentation fosse algo separado do produto. Na definição, você escreve o que o sistema precisa receber e devolver antes de tocar em código. Nada criativo. Uma lista de entradas, saídas, condições de erro e limites de tempo. Isso parece bobo até a terceira vez que um campo inesperado quebra seu job. Na execução, tudo vira artefato imutável. Container, imagem, pacote com lock. Se algo mudou, o novo artefato tem um identificador diferente. Nunca substitua o anterior. Substituir é o que faz a pedra rolar.

No registro, você anota o que falhou, por quê, e como foi resolvido. Esse registro precisa ser consultável e atrelado à versão que gerou o problema. Sem isso, você reaprende o mesmo erro a cada ciclo. Gasto real de tempo, não aprendizado.

O que funciona quando o sistema já está preso

Se você já está no meio do loop, corte o custo imediato. Desligue o que não é crítico. Isola a cadeia de dependência problemática e trate ela como sandbox separada. Roda tarefas manuais só enquanto você define um novo formato de entrega. Não tente consertar o legado inteiro de uma vez. Isso só cria mais repetição. Um detalhe que as pessoas ignoram: a ferramenta que você adota no meio do fogo tende a carregar os vícios do processo antigo. Se sua validação atual é informal, migrar para Terraform ou Airflow não resolve. A formalização tem que vir antes da ferramenta. Caso contrário, você só automatizou a pedra.

Sinais de que o método falhou

O sistema não escala se a carga de manutenção superar vinte por cento do tempo de desenvolvimento novo. Se seus relatórios de status mostram que a maior parte da semana é consumida por correções de configuração, o modelo está quebrado. Continue insistindo e você vai gerar mais débito técnico do que valor entregue. Também funciona mal em contextos onde os requisitos mudam por decisão externa direta. Se o negócio redefine entregáveis semanalmente sem registro estável, nenhuma camada de imutabilidade vai segurar o ciclo. Nesse caso, o remédio é reduzir o escopo do que é automatizado e tratar o resto como processo manual documentado. Automatizar caos só gera repetição rápida. O que resta não é esperança. É disciplina operativa. Quem sobrevive nesse tipo de trabalho não é o que trabalha mais horas. É o que consegue transformar o repetitivo em rastreável antes que o repetitivo vire padrão. O resto é só empurrar a pedra com mais força.