DEV Community: William Scussel

A aplicação estava saudável. O negócio estava parado.

William Scussel — Wed, 02 Sep 2026 19:24:14 +0000

Uma aplicação de produção começou a devolver erros de autenticação para usuários reais.

O primeiro impulso foi procurar uma queda de servidor, um processo travado ou algum problema no banco.

Nada disso tinha acontecido.

Os servidores estavam ativos. Os processos estavam rodando. O container continuava respondendo ao health check.

Mesmo assim, a operação estava parcialmente parada.

O teste que parecia inofensivo

Durante uma atividade normal de desenvolvimento, foi gerado um novo login contra um ERP externo.

A integração usava tokens de sessão fornecidos por esse ERP. A aplicação mantinha esses tokens em cache para não precisar autenticar a cada chamada.

O detalhe perigoso era que desenvolvimento e produção usavam a mesma credencial externa.

O fornecedor não tratava cada ambiente como uma identidade isolada. Um novo login podia invalidar ou deslocar uma sessão que a produção ainda estava usando.

Poucos minutos depois, a aplicação começou a receber respostas equivalentes a “login ou senha inválido” em várias operações do ERP.

O erro aparecia em massa, para usuários diferentes. Isso era um sinal importante: não era um registro específico nem um problema isolado de usuário. Era a autenticação da aplicação contra a dependência externa.

O servidor estava saudável

Esse tipo de incidente é perigoso porque os indicadores tradicionais continuam verdes.

O processo não caiu. O container não reiniciou. O endpoint de health check respondeu. O banco continuou disponível.

Mas a função principal da integração estava quebrada.

Em uma ocorrência, usuários perceberam o problema rapidamente e abriram chamados. Em outra, o erro ficou silencioso por dias. Os jobs continuavam executando, mas uma etapa importante retornava zero registros. Como não havia um alerta para esse resultado de negócio, a infraestrutura continuava reportando saúde.

Essa diferença merece uma definição explícita:

Saúde técnica significa que o sistema está executando.

Saúde operacional significa que ele está entregando o resultado esperado.

Uma não garante a outra.

A cadeia causal

O incidente não tinha uma única causa isolada. Ele era uma cadeia de decisões razoáveis que, combinadas, criaram um risco grande:

Ambientes diferentes compartilhavam uma credencial externa.
O fornecedor tinha regras de sessão concorrente que não estavam sob nosso controle.
A aplicação reutilizava um token em cache e não tinha recuperação automática confiável.
O token existia em mais de um lugar, como arquivo de ambiente, CI e Secret Manager.
O deploy podia recriar configurações antigas.
O health check verificava o processo, não a integração crítica.
Os jobs não tinham alerta específico para volume de resultado inesperadamente zerado.

O primeiro incidente sugeriu que o fornecedor permitia apenas uma sessão por credencial. Testes posteriores indicaram uma hipótese mais cuidadosa: poderia existir um limite ou pool pequeno de sessões, com invalidação dos tokens mais antigos quando novas sessões eram criadas.

O tamanho exato desse limite não foi provado. Para a operação, porém, o efeito era o mesmo: gerar sessões novas contra uma credencial compartilhada podia derrubar uma sessão ainda usada pela produção.

Essa distinção é importante. Uma boa análise não transforma uma hipótese conveniente em fato só porque ela explica o primeiro sintoma.

O conserto emergencial

A recuperação imediata foi operacional:

Gerar tokens novos usando credenciais de autenticação mais estáveis.
Validar esses tokens contra endpoints reais antes de aplicá-los.
Atualizar as configurações do ambiente legado, do CI e do ambiente em nuvem.
Reiniciar os processos para que carregassem os valores novos.
Observar chamadas bem-sucedidas durante um período de estabilização.

Isso restaurou o serviço, mas ainda era um band-aid. Trocar o valor de um segredo não remove o risco de ele ser revogado novamente.

Também havia um problema de distribuição. Atualizar apenas o .env do servidor não bastava se o próximo deploy recriasse o arquivo a partir de um parâmetro antigo do CI.

A correção estrutural

O desenho da correção precisava eliminar a dependência de intervenção manual:

1. Separar ambientes de verdade

Desenvolvimento, homologação e produção precisam de credenciais externas diferentes sempre que o fornecedor permitir.

Quando isso não for possível, a restrição deve ser tratada como um risco formal, com procedimento de diagnóstico e controles explícitos.

2. Reautenticar automaticamente

A aplicação não deve depender indefinidamente de um token de sessão salvo no ambiente. Quando o token expira ou é rejeitado, o sistema precisa obter outro de maneira controlada.

3. Compartilhar o cache entre processos

Um cache em memória cria uma sessão diferente para cada processo. Com vários workers, cron e containers, a própria aplicação pode gerar sessões demais.

Um cache compartilhado reduz esse comportamento e torna o estado da autenticação visível para todos os processos.

4. Coordenar a reautenticação

Se vários processos perceberem o token inválido ao mesmo tempo, todos podem tentar fazer login. Isso cria uma nova rajada de sessões justamente no momento em que o sistema está se recuperando.

Um lock distribuído permite que apenas um processo faça a reautenticação. Os demais aguardam o novo token aparecer no cache compartilhado.

5. Monitorar o resultado do negócio

O health check precisa responder perguntas além de “o processo está vivo?”

A autenticação com o ERP está funcionando?
A última importação trouxe registros dentro do esperado?
A fila recebeu itens quando deveria?
A taxa de erro da dependência externa mudou abruptamente?

Nem toda checagem precisa ser uma chamada pesada em produção. Métricas de resultado, idade do último sucesso e alertas de volume anormal já capturam uma classe importante de falhas silenciosas.

O que esse incidente ensinou

O erro mais fácil de apontar seria o login manual. Ele foi o gatilho de uma ocorrência, mas não explica sozinho por que a produção era vulnerável.

O risco real estava na combinação de:

credencial compartilhada;
sessão externa com regras pouco conhecidas;
token sem renovação automática;
configuração replicada em vários lugares;
monitoramento sem visão do resultado operacional.

Esse padrão aparece em muitos contextos. Pode ser um ERP, uma API bancária, um gateway de pagamentos ou qualquer fornecedor que use sessões, tokens e limites próprios.

Quando uma integração é crítica, disponibilidade não pode ser medida apenas pelo estado do servidor.

Checklist para evitar o mesmo problema

Use credenciais distintas por ambiente.
Nunca gere login de desenvolvimento contra uma credencial de produção.
Documente se o fornecedor limita sessões ou invalida tokens antigos.
Tenha refresh ou reautenticação automática.
Use cache compartilhado quando houver múltiplos processos.
Coordene a recuperação com lock distribuído.
Mantenha uma fonte única para secrets e parâmetros de deploy.
Alimente alertas com métricas de negócio.
Teste também o caminho de falha da dependência externa.
Diferencie health check técnico de health check operacional.

A aplicação estava saudável. O negócio estava parado.

O objetivo da arquitetura e da operação é garantir que essas duas frases nunca mais possam ser verdadeiras ao mesmo tempo.

Parei de usar IA como chatbot. Virei ela em infraestrutura.

William Scussel — Thu, 02 Jul 2026 11:14:03 +0000

A maioria usa IA assim: abre o chat, cola a pergunta, copia a resposta, volta pro editor, repete. A IA não sabe nada do seu mundo. Toda conversa começa do zero.

Há um tempo parei de fazer isso. Hoje a IA vive no meu terminal, lê meus repositórios, conhece meus clientes, roda meus scripts e abre pull request. O contexto já está lá quando eu chego.

Não é sobre achar o prompt mágico perfeito. É sobre montar um sistema em volta da IA: contexto, ferramentas e um loop que se repete. Vou mostrar como isso se parece na prática.

A base: meu mundo num repositório versionado

Tudo começa com um repositório que guarda o contexto que a IA lê. Versionado, porque evolui comigo, não vive na minha cabeça nem some quando troco de máquina.

tools/
├─ AI_DEFAULT.md    # instruções centrais, toda IA lê
├─ CLAUDE.md        # aponta p/ AI_DEFAULT
├─ projects.yml     # registro: alias de cliente → repo certo
├─ TOOLS.md         # catálogo de todos os scripts
├─ RUNBOOK.md       # deploy, settings, troubleshooting
├─ brand/           # cores, fontes, logos, templates
├─ clickup/         # tasks via terminal
└─ media/           # scripts de slides e vídeo

A peça central é um arquivo de instruções que toda IA lê antes de trabalhar: como fazer commit, convenções de branch, tom de voz, onde mora cada coisa. Escrevo a regra uma vez, ela vale pra sempre.

Frente 1: tarefa chata vira script

Toda repetição manual virou comando. E foi a própria IA que escreveu e mantém esses scripts.

Um resumo do meu dia (tarefas + agenda) cai no meu WhatsApp toda manhã, sozinho.
Crio e consulto tasks direto do terminal, sem abrir o navegador.
Scaffolds geram um projeto de infra ou uma apresentação inteira em um comando.

A regra que sigo: se fiz à mão duas vezes, a terceira é um script.

Frente 2: eu estendo a própria IA

Comandos e agents customizados ensinam a IA a trabalhar do meu jeito. Os que mais uso:

/implement pega uma task, cria a branch, escreve o código e abre o PR.
code-reviewer é um agent que revisa o diff antes de cada commit.
Comandos pequenos pro trivial: criar lembrete, resolver um alias de cliente.

A IA não é uma caixa fechada. É uma plataforma que dá pra programar.

Frente 3: IA no código de verdade, não em brinquedo

Isso roda em código de cliente, não em projeto de fim de semana. Por isso o fluxo tem trava:

Implementação de front e back em paralelo a partir de uma task.
Um gate de qualidade bloqueante: nada entra no repo sem o agent revisar.
Commits pequenos e focados, uma mudança lógica por commit.
PR pronto pra review, sem rastro de "isso foi IA".

O ponto não é a IA escrever rápido. É ela escrever dentro das minhas regras.

Frente 4: a IA conhece meu mundo

Planos e documentação ficam onde a IA lê e escreve.
Um registro de workspace resolve "fala do cliente X" pro repositório certo na hora.
Memória persistente: ela lembra decisões entre sessões.
Runbooks deixam a operação documentada e reutilizável.

Eu digo um apelido. Ela resolve o cliente, acha os repos certos e já sabe o que é front e o que é back. Zero explicação.

O padrão por trás de tudo

As quatro frentes parecem diferentes, mas são a mesma receita:

Contexto: a IA enxerga seu mundo (repos, docs, clientes, memória).
Ferramentas: ela executa (scripts, git, APIs). Não só fala, faz.
Loop: faz, verifica, corrige, com gate de qualidade fechando o ciclo.

Acerte os três e qualquer tarefa repetitiva vira automação. Erre um e você volta pro chatbot.

O efeito composto

São cerca de 5 horas por semana que voltam pra mim, dezenas de PRs abertos por um único comando, e o número cresce toda semana porque cada automação libera tempo pra construir a próxima.

Como você começa hoje

Não precisa replicar meu setup. Comece com um passo:

Escolha uma tarefa chata que você repete toda semana.
Peça pra IA virar script e versione no repositório.
Dê contexto: um arquivo de instruções que ela lê sempre.
Feche o loop: deixe ela rodar, verificar e corrigir.
Repita. Cada automação paga a próxima.

A pergunta não é "a IA consegue?". É "o que eu paro de fazer à mão hoje?".

O bug de 16 minutos: quando 'dado faltando' é uma corrida contra o relógio

William Scussel — Wed, 24 Jun 2026 19:51:59 +0000

"Seu sistema está perdendo dados"

Um cliente abriu o chamado, convicto. O relatório de retorno bancário enviado por e-mail toda manhã tinha 423 linhas. O mesmo relatório, gerado sob demanda no portal, tinha 1.351.

928 linhas, sumidas. É o tipo de número que faz você presumir o pior.

No fim, nada foi perdido. O bug tinha 16 minutos de largura.

Passo 1: comparar antes de debugar

Nada de código ainda. Primeiro dei um diff nos dois arquivos.

Mesmo dia.
Mesmo banco.
Mesmo filtro de status.
Toda linha do arquivo do e-mail estava contida no arquivo do portal.

Ou seja, o dado não estava errado. Estava ausente. Problema diferente.

Passo 2: matar hipóteses com prova, não com opinião

Três causas plausíveis, cada uma derrubada em produção com queries read-only:

"Está dividido entre bancos / anexos."
Não. Todas as 1.351 linhas pertenciam ao mesmo código de banco.

"O dedup contra o dia anterior é agressivo demais."
O relatório subtrai faturas já vistas no dia anterior:

$diff = array_diff(
    array_column($hoje, 'invoice'),
    array_column($ontem, 'invoice')
);

Repliquei contra os dados de produção. Removeu zero linhas. Não era o culpado.

"Os dois relatórios filtram colunas de data diferentes."
Não. Os dois filtravam a mesma coluna transaction_created_at, para a mesma data.

Passo 3: a mesma query, rodada agora, retorna tudo

Foi aqui que a ficha caiu. Com os filtros exatos que o job do e-mail usa:

SELECT COUNT(DISTINCT invoice)
FROM   bank_returns
WHERE  DATE(occurrence_date) = '2026-06-23'
  AND  bank_code = 33
  AND  credit_date IS NOT NULL;   -- "somente pagos"
-- → 1351

O e-mail tinha enviado 423. O banco de dados agora guarda 1.351. Com filtros idênticos. Nada na query mudou. Algo no tempo mudou.

Passo 4: seguir os timestamps

07:15:45  job do relatório roda, monta e envia o e-mail
07:31:02  sistema importa o arquivo de retorno do banco (~12.700 lançamentos do dia)

O relatório roda às 07:15. O arquivo com a maior parte das baixas confirmadas do dia chega às 07:31. O e-mail é gerado 16 minutos antes de o dado existir no banco.

Separe as faturas por esse corte e o gap bate exato:

-- importadas até 07:15  → o que o e-mail viu   → 423
-- importadas após 07:15 → "faltando"           → 928
-- total                                        → 1351

O portal "viu mais" por um motivo chato: foi consultado às 08:23, depois da importação.

O bug de verdade

Não é lógica. É acoplamento temporal entre uma tarefa agendada e a chegada de um dado externo. O relatório assume que os pagamentos de ontem já estão totalmente carregados às 07:15. O banco discorda.

Correções, da mais barata para a melhor:

Rodar o relatório depois da importação matinal.
Melhor: disparar o relatório ao fim da importação, em vez de um horário fixo.
Defensivo: o relatório validar que a importação esperada rodou antes de reportar.

A lição

"Menos linhas" quase nunca é "perdemos dados". Geralmente é "olhei no momento errado".

Antes de anexar um debugger, faça duas perguntas:

Quando esse dado nasce?
Quando eu o leio?

A maioria dos bugs de "dado faltando" morre aí mesmo.

[Boost]

William Scussel — Wed, 17 Dec 2025 13:20:25 +0000

Jenkins na AWS + Docker

William Scussel ・ Dec 3

#devops #jenkins #aws #docker

Jenkins na AWS + Docker

William Scussel — Wed, 03 Dec 2025 20:33:52 +0000

Olá, sou William Líder de squad na InnSpire.dev, quero começar a escrever sobre minhas experiencias no mundo da tecnologia, já que são mais de 20 anos trabalhando nessa area, quero compartilhar meus conhecimentos, sim, um pouco tarde para isso, mas como dizem: antes tarde do que mais tarde ainda.

E escolhi começar com uma das ferramentas que mais me deu dor de cabeça — e também as maiores vitórias: Jenkins.

Já perdi dados, já quebrei pipelines, já fiquei até de madrugada resolvendo build travado… mas hoje tenho uma infraestrutura estável, barata e eficiente rodando na AWS.

Neste artigo, quero mostrar como estruturamos Jenkins + Docker + AWS e talvez te dar alguns insights para montar algo parecido.

Bom vamos lá, atualmente nosso servidor está dentro da AWS, na região da Virginia, é uma instancia do tipo t3a.medium com 2vCPU e 4GB de memória, e dentro dela tenho uma instalação do Ubuntu 24.04 Server, gosto muito de trabalhar com essa distro em servidores, é muito versátil, mas isso pode ser um assunto para outro artigo quem sabe.

Como podem notar no print do servidor, já está rodando a algum tempo sem nenhuma interrupção, mas apesar da memória estar bem usada, todos os serviços que estão rodando dentro da maquina rodam bem, e está tudo dentro de containers, temos atualmente 21 containers rodando dentro deste servidor.

Dentro dos 21 containers que temos, 2 são para instalações do Jenkins, só que com jobs diferentes, propósitos diferentes, 2 para agentes de build do Jenkins (1 para cada instalação), e outros dois containers muito importantes para auxiliar nesse fluxo todo, Nginx para gerenciar o roteamento, e o Portainer para verificar a saude de todos os containers que estão no servidor.

A idéia de separar em dois containers diferentes, foi mais para dois times distintos conseguirem atuar de forma totalmente separada e poder destruir seu ambiente sem afetar o outro time, e com docker isso é muito mais simples.

Agora de fato sobre a configuração do Jenkins, no docker-compose eu tenho mapeado os diretórios que serão acessados pelo Jenkins e o agente, e uma peculiaridade é o mapeamento do arquivo docker.sock, isso foi necessário pois dentro de alguns jobs eu precisava fazer o restart de algum container, e sem isso não era possível acessar os containers 🫠

# docker-compose.yml

services:
  jenkins:
    build: .
    container_name: jenkins-innova
    restart: always
    privileged: true
    ports:
      - "3001:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - innova-network

  jenkins-innova-agent:
    image: jenkins/inbound-agent
    container_name: jenkins-innova-agent
    networks:
      - innova-network
    volumes:
      - /srv/jenkins-innova:/home/jenkins/agent-workspace
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      JENKINS_URL: "http://jenkins-innova:8080"
      JENKINS_AGENT_NAME: "agent"
      JENKINS_SECRET: "chave"
    restart: unless-stopped

volumes:
  jenkins_home:

networks:
  innova-network:
    external: true




# Dockerfile

FROM jenkins/jenkins:alpine3.21-jdk21

USER root

# Instalar dependências sem modificar o Java existente
RUN apk add --no-cache \
    sudo \
    docker-cli \
    git \
    bash \
    curl \
    ttf-dejavu

# Adicionar usuário Jenkins ao grupo Docker
RUN addgroup -S docker && adduser jenkins docker \
    && echo "jenkins ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/jenkins

USER jenkins

E daqui para frente é só sucesso, configurar e sair usando, se quiser que eu comente mais como são configurados os jobs que temos, comenta ai!