CI/CD, containers e observabilidade raramente entram na empresa ao mesmo tempo. É comum o pipeline nascer primeiro, para acabar com o deploy manual; depois vêm os containers, para padronizar ambiente; e a observabilidade chega por último, geralmente depois do primeiro incidente que ninguém conseguiu explicar. Cada peça funciona isolada, mas o conjunto não fecha. O sintoma clássico é o time saber que algo quebrou sem conseguir dizer o que, onde e desde quando.

Quando cada peça conta uma história diferente

Um pipeline que apenas executa testes e sobe a aplicação não é um fluxo de entrega. Ele informa que o build passou, não o que efetivamente chegou em produção. Se a imagem do container é construída com tag móvel (latest ou o nome da branch), o artefato testado e o artefato publicado podem ser diferentes, e ninguém percebe até o comportamento divergir.

A observabilidade tem um problema parecido. Métricas de CPU, memória e disco dizem como o servidor está, não como o negócio está. Sem rastreamento de requisição e sem logs correlacionados, o time investiga incidente por tentativa e erro: reinicia o serviço, olha o gráfico, pergunta no grupo. Cada minuto disso é custo.

Os sinais mais comuns de que o fluxo está quebrado:

  • o pipeline fica verde, mas a versão em produção não corresponde ao commit aprovado;
  • o rollback existe no discurso e não no runbook, e ninguém o executou nos últimos meses;
  • alertas disparam sem indicar impacto (usuário afetado, jornada interrompida);
  • staging e produção divergem em configuração, e o teste de carga não representa o ambiente real;
  • o time não sabe dizer qual foi a última mudança antes do incidente.

O impacto na operação de uma distribuidora

Uma distribuidora de médio porte, com ERP próprio e portal de pedidos B2B, vivia esse cenário. O pipeline subia a aplicação em containers, o plantão recebia alertas de CPU, e o portal tinha picos de erro no fechamento de pedido. Quando o cliente reclamava, o time abria três frentes: logs da aplicação, logs do banco e o painel de infraestrutura. Nenhuma delas tinha o identificador do pedido, então a investigação começava do zero a cada chamado.

A correção não foi trocar de ferramenta. Foi amarrar as três pontas: tag imutável por commit, healthcheck e readiness no container, e um identificador de correlação propagado da requisição HTTP até a consulta ao banco. Com isso, um pedido com erro passou a ser rastreável de ponta a ponta. O efeito prático foi a janela de deploy deixar de ser noturna, porque o time passou a confiar no que o pipeline informava, e o diagnóstico de incidente deixou de depender de quem estava de plantão naquele dia.

Na prática

Para quem mantém software em produção, o fluxo DevOps se sustenta em decisões pequenas e verificáveis:

  1. Um artefato, um identificador. A imagem publicada deve ter tag imutável e carregar o commit que a originou. O que foi testado é o que vai ao ar.
  2. Todo serviço precisa de healthcheck e readiness. Container sem esses sinais faz o orquestrador enviar tráfego para instância que ainda não terminou de subir.
  3. Um identificador de correlação por requisição, propagado entre serviços e registrado nos logs. Sem isso, observabilidade vira coleção de gráficos.
  4. Alertas por sintoma de negócio, não apenas por recurso. "Pedido não fecha" é mais útil que "CPU em 80%".
  5. Rollback testado com a mesma frequência do deploy. Se ninguém executou, não existe.
  6. Revisão pós-incidente com uma ação concreta no pipeline ou no monitoramento, não apenas um documento.

O critério para investir é simples: se o time não consegue responder qual mudança entrou, quando entrou e qual usuário foi afetado, o fluxo ainda não está pronto, independentemente da ferramenta escolhida.