O problema

A dor era clara: a falta de um ambiente imutável para rollback. Nosso processo de deploy, que dependia do ambiente de QA para um swap seguro, estava vulnerável. Se algo desse errado em produção, a versão em QA poderia não ser a versão estável anterior, impossibilitando um rollback rápido e seguro. Precisávamos de um "porto seguro", um slot de deploy que guardasse a versão estável da produção, intocável, para qualquer eventualidade.

A investigação

Minha primeira dedução foi que precisávamos de um novo slot de implantação, dedicado exclusivamente para ser um fallback. Sem rota configurada, sem uso para testes, apenas um guardião da versão estável. A jornada começou na Azure, nosso provedor de serviços em nuvem. Naveguei até o App Service, onde nossas aplicações residem, e então para os slots de implantação da aplicação em questão. Tudo via interface gráfica, um legado que ainda estamos trabalhando para modernizar com IaC, mas que, por enquanto, é o caminho.

Criei o slot e o batizei de fallback. A ideia era que ele serviria apenas para subir a versão nova e fazer o swap para produção. Em caso de necessidade de rollback, ele estaria lá, imutável, com a versão que estava em produção antes do deploy. Parecia um plano sólido.

Com o slot criado, o próximo passo era ajustar o Azure DevOps. Nossas configurações de swap ainda apontavam para QA, e isso precisava mudar. Fui em Releases, selecionei a release que estávamos trabalhando (ainda em modo clássico, outro ponto para futuras melhorias com YAML) e cliquei em editar. Para agilizar, clonei o stage de deploy para QA, mas o deixei sem trigger, para ser executado apenas manualmente. O ponto crucial aqui foi trocar o Slot de QA para fallback.

Em seguida, na task que realiza o swap para produção, alterei o Source Slot de QA para fallback. Confirmei que o checkbox Swap with Production estava ativo. Nesse momento, senti que estávamos no caminho certo. Salvei as alterações e o trabalho, por enquanto, estava feito. Agora era esperar a próxima entrega para validar se tudo funcionaria como o esperado.

Chegou a segunda-feira, dia da entrega. 8:40 da manhã, o deploy agendado para as 09:00. Dei uma última lida na documentação que havíamos feito, para me certificar de que não havia esquecido de nada. O plano era claro: verificar a versão em produção, subir a nova versão no slot fallback, fazer o swap para produção e, por fim, verificar se a versão havia sido trocada. Acontece kkk, que a teoria é uma coisa, a prática é outra.

O Microsoft Azure App Service, no processo de swap, troca o código (artefato) e algumas configurações (dependendo do que está marcado como "slot setting"). A lógica é:

Com o plano em mãos, executei os passos. Subi o projeto no slot fallback e, em seguida, realizei o swap.

Ufa, deu certo! A versão foi atualizada com sucesso e o slot fallback agora continha a versão anterior, pronta para um rollback caso necessário. A tensão diminuiu, e a sensação de ter resolvido um problema crítico foi gratificante.

Ficou em aberto

Embora a solução para o problema do slot de fallback tenha sido implementada com sucesso, ainda há um caminho a percorrer. A dependência da interface gráfica da Azure e o uso de releases em modo clássico no Azure DevOps são pontos que precisam ser endereçados. A transição para IaC (Infrastructure as Code) e a conversão das releases para arquivos YAML versionados são os próximos passos para modernizar nossa infraestrutura e processos, garantindo maior automação e controle.

Referências

• Azure App Service - Slots de Implantação - documentação oficial sobre como configurar e realizar o swap entre slots de produção e staging

• Azure DevOps - Release Pipelines (Clássico) - guia sobre a criação e edição de pipelines de release no modo clássico

• Azure App Service - Configurações de Slot - detalhes técnicos sobre quais configurações de artefatos e variáveis são trocadas durante o swap

Vinicius Aguilar — DevOps Engineer

Me avisaram que a pipeline de um projeto tinha quebrado. Abri e fui direto na task que havia falhado e a mensagem era clara:

Antes de qualquer coisa, avisei no grupo do time que a pipeline estava com problema e que eu estava verificando.

O problema

Bom, a mensagem de erro dizia que o agente não encontrou o diretório de templates de email. Bem tranquilo de entender, mas o contexto ajudou muito. No dia anterior, o dev tinha mandado no grupo:

Galera, esse projeto aqui fica os templates de email. Se alterar o arquivo por outro projeto, os commits serão bloqueados. Quando precisar alterar, altere no repositório real e depois atualize nos outros projetos.

Com isso, eu já tinha uma hipótese antes de abrir os arquivos: algum teste novo passou a depender desses templates na hora de rodar.

A investigação

Entendendo o template de pipeline

A task de testes vinha de um template centralizado que eu mesmo montei:

Fui até o repositório central, para relembrar o que o template faz. Ele descobre automaticamente os projetos de teste procurando por arquivos .csproj, e para cada um monta e executa o dotnet test. Se qualquer projeto crítico falha, a pipeline inteira cai com exit 1.

Nada suspeito aqui. Mas foi importante para ter contexto. Quanto mais contexto eu absorvo, mais rápido consigo fechar o diagnóstico.

O que mudou na PR

Fui olhar a PR que havia sido mergeada antes da falha. Tinha vários testes novos. Peguei qualquer um e encontrei:

Fui até onde TemplatesRootPath era definido:

Olha que interessante, cinco .. navegando para fora do diretório. O dev provavelmente construiu o caminho com base na estrutura de pastas da máquina dele.

Na máquina dele, subindo cinco níveis a partir do BaseDirectory, chegava no repositório oficial dos templates. No agente de CI, esse caminho não existe. Daí o DirectoryNotFoundException. Isso bateu com a mensagem do dia anterior no grupo. O código não estava tentando chegar na pasta réplica usada no agente. Estava tentando alcançar o repositório oficial dos templates, do jeito que existe na estrutura local do dev.

Não era problema de pipeline. Era problema de código.

A solução: variável de ambiente com fallback

O dev é tech lead e tem uma pipeline parada. Não era hora de questionar a arquitetura da solução local dele. A saída mais rápida e menos invasiva: fazer o código consultar uma variável de ambiente antes de tentar o caminho relativo, e configurar essa variável no grupo de variáveis compartilhado já existente, apontando para a pasta réplica correta no agente.

Primeiro, o ajuste no TemplatesRootPath:

Depois, no grupo de variáveis, adicionei EMAIL_TEMPLATES_PATH apontando para AppData/SharedFiles. E no template da pipeline, passei a variável para o step de testes:

Rodei. Os erros de DirectoryNotFoundException sumiram. Mas a pipeline ainda falhou, agora com 6 testes quebrando onde antes eram 25.

Lendo os logs do xUnit sem enlouquecer

Uma dica que vale guardar: o xUnit roda testes em paralelo, então o output fica entrelaçado. O padrão é mais ou menos assim:

É muito fácil se confundir. A dica é dar um Ctrl+F e procurar por Failed. Ignore os blocos [xUnit.net], principalmente os que aparecem no meio das explicações: eles são só avisos que interrompem o output de outro teste. Não sei por que é assim xD, é muito ruim. Mas sabendo disso, fica gerenciável.

E sobre o stack trace: leia de baixo para cima. Ignore tudo que começa com System. ou Microsoft., isso é infraestrutura do .NET que você não controla. Foca na primeira linha que aponta para um arquivo do seu projeto.

Quando o valor não nasce no arquivo que eu estou olhando, eu já sei que ele veio de fora. E aí o stack trace vira mapa: eu subo uma chamada por vez até encontrar a origem.

Os 6 erros restantes: todos a mesma causa

Erros 1, 2 e 3 (AppDataUnitTest.cs)

Os três apontavam para variações do mesmo padrão: um método GetSharedFilesPath dentro dos testes usando os mesmos cinco .. para montar o caminho. O dev copiou a lógica do TemplatesRootPath que já havíamos corrigido. A correção foi idêntica: ler de EMAIL_TEMPLATES_PATH com fallback para o caminho relativo.

Erros 4, 5 e 6 (RenderPDFUnitTest.cs --> invoice.cshtml, invoice-email.cshtml, invoice-usd.cshtml)

Stack trace idêntico para os três, só mudava o arquivo de template. A rota era:

O teste passava um caminho montado com GetSharedFilesPath usando os mesmos cinco ... O GetRazorEngineCompiledTemplate tentava o caminho direto, não achava, caía no GetFilePath, que também não achava, e estourava. Mesma raiz, mesma correção: aplicar o padrão de variável de ambiente com fallback no GetSharedFilesPath do RenderPDFUnitTest.

No total: três arquivos de teste, mesma lógica copiada, mesma correção aplicada em cada um.

Subi as correções, rodei a pipeline. Build finalizado com sucesso. Abri a PR, avisei o dev, ela foi mergeada. Rodei a branch develop para validar uma última vez.

O real problema estava no código do teste. A pipeline foi só o mensageiro.

Ficou em aberto

A lógica dos cinco .. está correta na máquina do dev? Não investiguei se a estrutura de diretórios local realmente funciona como o código assume. Pode ser que funcione, pode ser que o dev nunca tenha rodado esses testes localmente de verdade.

Existe uma abordagem melhor para referenciar arquivos compartilhados em testes? A variável de ambiente com fallback resolve o problema de pipeline, mas o padrão de navegar para fora do projeto para achar um arquivo irmão em repositório diferente tem cheiro de problema esperando para acontecer de novo. Uma solução mais robusta provavelmente envolveria copiar os templates como parte do build de teste, ou usar um fixture de teste que isola esse caminho. Não avaliei isso a fundo.

Quantos outros lugares no projeto usam a mesma lógica? Corrigi três arquivos. Pode haver mais. Não fiz uma busca global por "..", "..", "..", "..", ".." no repositório.

Referências

• xUnit - Parallelism in MSBuild - documentação sobre execução paralela e por que o output fica entrelaçado

• Azure DevOps - Variable Groups - como configurar variáveis compartilhadas entre pipelines

• Azure Pipelines - Template parameters - como passar variáveis de ambiente via parâmetros de template

Vinicius Aguilar — DevOps Engineer

A pipeline de build de uma aplicação Angular parou de funcionar. O famoso "DO NADA".

Um dev me pingou: "tá dando um erro estranho na pipe, consegue dar uma olhada?" Pensei: não teve mudança recente na pipeline, nem na VM. Estranho. Mas como o assunto é fluxo do time, então é prioridade. Parei o que estava fazendo e fui verificar.

O problema

Acessei o build e de primeira já verifiquei que todos falhavam no mesmo ponto: a etapa de instalação do Angular CLI. Isso já me deu o palpite de que podia ser um problema na VM, pois essa pipeline usa um agente self-hosted.

A investigação

Abri a task de instalação do Angular CLI no Azure DevOps. A primeira coisa que saltou foi ##[error]Error: Npm failed with return code: 217:

Uma pesquisa rápida e descubro que é um erro genérico, ou seja, pode ser qualquer coisa. Tudo bem, mas isso significa que a resposta não estava ali. Voltei para o log, continuei lendo o que estava antes do 217 e encontrei a mensagem: directory not empty, rename '.../cli' -> '.../cli-Xuqet0PR'

Perfeito. Agora eu tinha uma pista. A própria mensagem de erro é intuitiva, o npm tentou instalar o Angular CLI e, para fazer isso, primeiro tenta renomear o diretório atual (cli) para um temporário (.cli-Xuqet0PR). Só que esse temporário já existia com conteúdo. O rename falhou, o processo morreu, o build foi junto.

A grande pergunta não era o que quebrou. Era por que isso estava ali.

Me fazer essa pergunta me fez enxergar a origem do problema em vez de sair procurando solução cegamente. Fui na lista de builds no Azure DevOps, procurei o último lote de builds com sucesso e identifiquei o momento exato em que as falhas começaram. Abri o build correspondente, acessei a PR em andamento e encontrei uma alteração no YAML da pipeline: o dev tinha removido a etapa de instalação do Angular.

Por que esse dev precisou retirar isso? Esse tipo de mudança na pipeline normalmente é um sinal de que o problema foi interpretado sem contexto suficiente.

Antes de investigar mais a fundo, preciso liberar o fluxo

Pipeline parada é prioridade máxima. Como DevOps, minha função é acelerar o ciclo de entrega do time, e build travado é o oposto disso.

Dei um change request na PR, chamei o dev no privado para avisar sobre o erro e comuniquei ao time no grupo que havia um problema na pipeline e que eu já estava investigando. Com isso feito, ativei a VPN e acessei a VM via SSH.

Tava lá. O diretório temporário abandonado, exatamente onde o erro dizia.

Antes de rodar qualquer comando, fui pesquisar o que era esse .cli-Xuqet0PR. Uma regra de ouro aqui é sempre questionar as próprias decisões. Sair apagando arquivos sem entender o impacto é pedir para ter problema. Fiz a pesquisa e retornou essa resposta:

O diretório temporário que o npm utiliza durante uma instalação global serve como um espaço de trabalho intermediário para processar o pacote antes de movê-lo para o local definitivo no sistema.

Ótimo. O fluxo normal do npm é criar o temporário (.cli-xxxxx), processar o pacote nele e mover tudo para o diretório definitivo (cli). Se o processo é interrompido no meio, o temporário fica lá. Na próxima execução, quando o npm tenta criar de novo, encontra um diretório não vazio e explode com ENOTEMPTY.

Agora que entendi o processo e sei qual é o problema, a solução é deletar as duas pastas, a cli e a temporária.

Rodei a pipeline de novo e passou. Fui conferir a pasta na VM logo após o step de instalação do Angular CLI concluir e apenas o diretório cli estava lá, sozinho. Ou seja, o temporário foi criado, extraiu o pacote e depois foi renomeado para cli. Problema resolvido, time avisado no grupo. Agora que o fluxo do time voltou, podemos entender o que causou isso.

Quem interrompeu o processo?

Um princípio que carrego pra sempre na minha carreira é que nada acontece do nada.

De cara, minha dedução foi que o problema estava na alteração do YAML feita pelo dev. Mas fui checar o histórico da PR e notei que ele só removeu a instalação do Angular no terceiro commit. O erro 217 já estava quebrando a pipeline antes disso. O que provavelmente aconteceu? Sem saber como resolver o problema original, ele colou o log na IA. Ela, completamente sem contexto da nossa aplicação, deu a solução mais genérica possível: mandar apagar a instalação do Angular CLI.

Descartada a primeira ideia, pensei que uma possível causa fosse o processo de instalação ter sido abortado no meio. O diretório temporário ficou órfão lá no agente de build. Todos os pipelines seguintes tentavam fazer o rename e quebravam justamente porque esbarravam num destino que já não estava vazio. Mas quem pode ter interrompido a execução, se não tem build anterior ao que falhou?

Fui ver nos logs do agente na VM. Aqui aprendi algo que eu não sabia na prática: a VM está em UTC e eu estou em UTC-3. O build que eu via no Azure DevOps como falho às 08:53 correspondia a 11:53 na VM. Isso importa na hora de correlacionar logs.

Dei um cat nos arquivos de logs do agente e o arquivo era enorme, sem chance de ficar procurando linha por linha. Pedi ajuda a uma IA para refinar o comando, e ela sugeriu filtrar pelo Running job:

Esse comando retornava os logs de todas as vezes que um build foi iniciado usando o agente da VM. Aqui foi fundamental entender a diferença de fuso horário, porque a máquina roda em UTC. Eu precisava isolar os logs e encontrar o primeiro build do dia.

Comecei a caçar pela data e esbarrei em vários logs antes das 11:53, que era o horário da nossa falha. Precisei analisar um por um por processo de eliminação. Primeiro, vi três execuções às 01:00 UTC. Por que eles rodaram antes da primeira pipeline do dia? Simples, foi por conta do fuso (UTC-3), esses builds na verdade rodaram às 22:00 do dia anterior no meu horário local. Eram jobs de outra pipeline que utiliza também esse agente.

Depois, achei mais três jobs às 02:00 UTC. Mesma lógica, eram das 23:00 da noite anterior, referentes aos agendamentos que configurei para rodar em três branches diferentes. Tudo certo até aqui.

Eliminando esse histórico noturno e o build das 11:53 que falhou, sobraram exatamente dois jobs nos logs (às 11:49 e 11:50) que simplesmente não apareciam na interface do Azure DevOps.

Foi só nesse momento que a minha ficha caiu e eu olhei para o número do build que havia falhado: #20000000.3. Estava na minha cara o tempo todo. O sufixo já indicava que era a terceira execução do dia. Eu não tinha prestado atenção nisso antes... mas acontece xD. Isso confirmava tudo, o log me levou na direção certa e realmente tínhamos dois builds perdidos.

Lendo os logs dos Workers

Na pasta _diag/ existem logs de Workers além dos logs do agente. Basicamente, um arquivo de log por build, mas com um detalhe muito útil: o nome do arquivo já contém o horário de início do build, em UTC.

Listei os arquivos e identifiquei esses dois na hora. Os segundos não batem exatamente, mas os minutos batem com 11:49 e 11:50 dos logs do agente, só podiam ser esses.

Rodei o comando para ver o conteúdo e percebi que era denso demais para ler direto. Copiei o log e perguntei para a IA: "o que aconteceu com esse build? Foi deletado, cancelado, crashou? E quem fez isso?" A IA retornou:

Agora eu sabia que os dois builds foram cancelados. Não foi crash, não foi a VM. Receberam um sinal externo limpo. Mas de quem?

O culpado

Ou seja, tínhamos builds cancelados e que sumiram da interface do Azure DevOps. Mas o rastro sempre fica na infraestrutura. Fui atrás e descobri que o Azure DevOps tem uma API REST que expõe justamente esses dados fantasmas. Abri a documentação, levantei os parâmetros necessários e usei a IA para me ajudar a montar a URL rapidão. Como eu já estava logado no portal, a chamada retornou um JSON gigantesco com os detalhes da execução. Joguei tudo num formatador online, dei um Ctrl+F pelo ID do build e a resposta estava lá:

Pois é. O culpado não era o dev novato. Não era a máquina. Não era ninguém do time. Foi o pr.autoCancel em ação... fazendo exatamente o que foi configurado pra fazer. O Azure cumpriu o contrato. O problema real é que a pipeline não estava preparada pra lidar com essa interrupção, e deixou rastro em disco.

Esse recurso cancela automaticamente qualquer build em andamento toda vez que a PR é atualizada. Então fui até a PR no Bitbucket para ver se a linha de pensamento estava certa, e quando cheguei lá vi o seguinte processo:

Feito, problema 100% rastreado.
O que aprendemos com tudo isso? O que aprendemos com tudo isso? A pipeline precisa ser resiliente o suficiente pra sobreviver a cancelamentos. xD

O que aconteceu aqui foi que a PR passou por varias etapas uma em seguida da outra. Ela foi aberta, passou para draft, mudou o título. O dev não percebeu que cada clique inofensivo dele na tela disparava um webhook que mandava o Azure DevOps executar o pr.autoCancel lá no servidor. É claro que a pipeline tem uma fragilidade por não saber limpar a sujeira que o npm deixou para trás. ..

PR é lugar de iterar. Abrir, ajustar o título, passar pra draft, receber review, commitar de novo... isso é o fluxo normal e esperado. O dev não fez nada errado ao atualizar a PR. O que falhou foi a pipeline assumir que o ambiente sempre estaria limpo, sem verificar o estado antes de instalar. É claro que entender que cada clique na interface pode disparar um webhook que impacta um processo rodando em disco lá na VM é um aprendizado valioso. Mas a lição principal aqui é sistêmica: job que não consegue sobreviver a uma interrupção vai quebrar cedo ou tarde.

Ficou em aberto

Por que o npm não faz cleanup ao receber o sinal de cancelamento? Dependendo de como o sinal é entregue e em que ponto exato do rename o processo estava, o cleanup pode não acontecer. Não investiguei isso a fundo. Mas é interessante...

O pr.autoCancel tem configuração granular? Não verifiquei se é possível desativar por pipeline específica ou se é uma configuração global.

Dá para tornar o step idempotente? Adicionar uma limpeza antes do npm install -g eliminaria o problema independentemente de qualquer cancelamento futuro:

Não implementei ainda. Não sei se gera efeito colateral em builds paralelos no mesmo agente.

Referências

• Azure DevOps REST API - Builds - usado para consultar builds deletados e cancelados que não aparecem na UI

• Azure Pipelines - PR Triggers e autoCancel - documentação do comportamento de auto-cancelamento em PRs

• npm CLI - npm install - comportamento de instalação global e uso de diretórios temporários

Vinicius Aguilar — DevOps Engineer

Uma mentira que alimentamos...

Segunda-feira, 09h da manhã. Deploy em produção. Todos os devs na call e alguém solta: "Ninguém é insubstituível mesmo.". Todo mundo fica em silêncio... e a pessoa continua: chegou o e-mail do desligamento de um brother do time. Aquele silêncio pesado.

Pois é, e eu achava esse colega essencial no time. O problema é que dois meses depois, ninguém mais lembrava o nome dele...

Ora ou outra, ouvimos essa frase. E, sinceramente, em algumas situações ela nos faz acreditar nela. O principal setor que alimenta essa narrativa de que "ninguém é insubstituível" é o mercado de trabalho, porque não importa o quanto você atue, execute múltiplas tarefas, seja o primeiro a chegar e o último a sair: sempre haverá outra pessoa que consegue entregar o mesmo que você, ou até mais.

Um erro que eu cometi foi achar que, quando eu saísse de uma empresa (principalmente por falta de reconhecimento), ela iria sentir de alguma forma. E vamos ser sinceros: lá no fundo, existe um desejo de descobrir que a empresa passou por dificuldade depois que você saiu. E isso é puro ego. A verdade que dói é que não somos insubstituíveis no mercado de trabalho, e possivelmente a empresa nem sentiu a nossa falta. Com o tempo, a maturidade chega, e percebemos que, se a empresa não reconhecia nosso valor, talvez fosse simplesmente uma questão de alinhamento. Não é pessoal. É mercado.

Essa sempre foi a regra do jogo. Até que veio a inteligência artificial e reescreveu tudo.

O cenário assustador

Hoje, em tech, quem não usa IA está ficando pra trás em produtividade. Uma pessoa com conhecimento básico usando IA, possivelmente vai conseguir entregar mais do que um dev júnior que não usa IA.

Ao mesmo tempo, tem gente perdendo o emprego pelo mesmo motivo: uso da IA. Então fica a dúvida: como ser um bom profissional nesse cenário?

A lógica é simples: se eu não uso IA, fico para trás em produtividade e competitividade. Mas se eu me encosto nela de forma excessiva e sem critério, o risco de adquirir preguiça cognitiva e virar um simples copiador de prompts é gigante.

E qual o resultado prático disso no dia a dia? Sistemas sem integridade. Começa a entregar blocos de código que até rodam na superfície, mas que ignoram a arquitetura e atropelam as regras de negócio. No curto prazo, isso gera um ecossistema frágil e todo remendado. No longo prazo, você decreta a própria perda de relevância.

Pensa bem... se eu entrego um componente que não entendo a fundo e não sei explicar como funciona, minha mão de obra passa a ser facilmente substituível. Afinal de contas, fazer perguntas aleatórias para a IA qualquer um faz... agora, fazer as perguntas certas exige conhecimento técnico. Não tem atalho para isso.

Relutar contra a IA é fazer igual aquele cara da infra, de dez anos atrás, que se recusou a aprender Cloud. Aquele cara que dizia que configurar servidor na mão via SSH era o jeito ‘certo’, enquanto o mercado migrava pra infraestrutura como código. Hoje, ele leva uma semana pra fazer o que um pipeline resolve em minutos.

Relutar contra a IA é repetir esse erro. Não importa o quanto você seja bom ou rápido no teclado, você não vai ultrapassar a produtividade de uma IA, por mais básica que ela seja. Atualmente, velocidade virou pré-requisito, não diferencial.

Tá, mas se eu não posso relutar contra a IA, terceirizar o cérebro pra ela é a solução? Longe disso. E é exatamente nesse ponto que o mercado separa o profissional genérico e o profissional com diferencial real.

O que a IA não consegue fazer

Raciocínio sistêmico. A capacidade de enxergar o todo, e não só a parte. De entender que cada componente de um sistema está conectado aos outros, e que uma ação em um ponto pode gerar consequências em cadeia em lugares que você nem estava olhando.

Vou te dar um exemplo prático: recebi um alerta crítico de latência alta numa aplicação em produção. A primeira reação de quem depende 100% de IA seria colar o log no chat. Ela devolveria o óbvio: otimize a query, ajuste o índice, escale a máquina. Mas o problema estava fora do radar dela.

Foi fazendo as perguntas certas, como "Isso começou quando?", "Teve deploy hoje?" e "Quem mais compartilha recursos com esse banco?", cheguei na raiz do problema. Um pipeline rodando em background travou as conexões do pool. Não era a query, era contenção de recurso causada por outra peça da infraestrutura. A IA não faz essa correlação sozinha. Ela não tem o contexto do todo. E com a pressão do sistema caindo, você não tem tempo de explicar isso pra ela.

Nesse cenário, o melhor foi não usar IA. Porque simplesmente não era necessário. Eu precisei somente me questionar com o básico para encontrar o problema raiz. Depois de entender a causa, se precisasse de algo mais minucioso, aí sim eu usaria a IA.

Esse tipo de raciocínio é o que responde a perguntas que a IA não sabe formular:

• Por que o sistema está se comportando assim na raiz do problema?

• Onde as falhas vão surgir quando escalar? Qual a previsibilidade?

• Como uma alteração mínima pode gerar um efeito dominó e causar um outage?

No fim das contas, o segredo é usar IA com profundidade técnica suficiente para saber quando ela está errando.

Quantas vezes você já jogou o erro no chat da IA sem nem ler a mensagem antes? É automático: deu erro, cola lá.

O profissional que se diferencia é o que para, lê, entende o contexto e só depois decide se precisa de ajuda. Ele percebe quando a IA está alucinando, presa em loop, ou dando uma volta ao mundo para algo que se resolve com um único comando. A primeira pergunta que ele se faz é: 'Isso faz sentido?'. Ele domina a regra de negócio e a arquitetura, conhece os gaps e não sai executando código às cegas.

O que mudou na minha cabeça

Essa clareza sobre IA e diferencial técnico é só metade do problema. A outra metade, que demorei mais para aceitar, é entender o meu real tamanho perante o mercado.

Trabalho como DevOps, tenho projetos bacanas. Mas sei que ainda tem um nível acima do que eu sou hoje e chegar lá exige mais. Durante muito tempo, caí na armadilha da "síndrome do protagonista", aquela ilusão de que somos o alecrim dourado, a exceção à regra, e de que o sucesso virá por atalhos ou de forma mágica. Mas quando você olha para a complexidade da nossa área, para a arquitetura dos sistemas e para a velocidade com que a IA evolui, a ficha cai: não há espaço para quem acha que sabe tudo.

Existe uma sensação silenciosa que assombra muitos profissionais de tech: por fora, tudo certo. Entregas acontecendo, reconhecimento vindo, destaque no time. Mas por dentro, uma pergunta que não sai da cabeça: o quanto disso fui realmente eu? Essa dúvida se intensifica com o uso da IA. Porque quando a ferramenta entrega rápido demais, fica difícil separar onde termina a IA e onde começa o seu raciocínio.

Perceber que não existe atalho, milagre ou ‘hack’ pra salvar a carreira é libertador. Isso elimina a ilusão de que você já sabe o suficiente e deixa apenas um caminho inevitável: estudar. Isso não é autopiedade, é autoconsciência.

Como já dizia o filósofo Clóvis de Barros Filho: 'Você tem brio?'. Aquele brio de olhar para um problema e pensar: 'Como pode alguém ter criado isso e eu não dar conta de entender? Não tem como'. E então sentar, ler, refazer uma, duas, três vezes até dominar. Sem atalho. Sem plano B.

Mas dominar a técnica através do estudo é só a base. O seu verdadeiro diferencial em relação a uma IA entra no passo seguinte: a sua capacidade de pensamento e tomada de decisão no mundo real. Infelizmente, não conseguimos mais criar um cluster Kubernetes mais rápido que uma IA. No entanto, nós temos o raciocínio sistêmico, a mentalidade de engenharia e, principalmente, o contexto vivido. A IA não sabe que aquele microsserviço de pagamento não pode ser reiniciado durante o fechamento do mês porque derruba a conciliação inteira. Ela não sabe que um cliente em particular não tolera nem 30 segundos de indisponibilidade. Ela não carrega o histórico de decisões ruins que o time tomou há dois anos e que assombram a arquitetura até hoje. Esse contexto não se prompta. Ele se constrói com tempo, atenção e presença. E é exatamente isso que te mantém no jogo.

A conclusão

"Ninguém é insubstituível." Eu comecei esse artigo com essa frase. E continuo acreditando nela. No mercado de trabalho, ninguém é. Mas descobri que a pergunta certa nunca foi "como ser insubstituível?". A pergunta certa é: "o que eu preciso dominar pra que me substituir custe caro demais?"

E a resposta não está em trabalhar mais horas, nem em abraçar a IA cegamente, nem em fingir que a IA não existe. Está em construir um raciocínio que a IA não replica, uma profundidade técnica que não se copia com prompt, e uma autoconsciência que te impede de estagnar.

Domine as tecnologias como pré-requisito. Mude sua forma de pensar como diferencial.

O caminho pra ter esse diferencial é mais simples do que parece. Você simplesmente precisa estudar e se colocar em problemas... Pensar fora da caixa em DevOps não é usar a ferramenta mais nova ou montar o pipeline mais elaborado. É questionar o que todo mundo aceita como verdade. Por que esse processo existe? Ele ainda faz sentido? Existe uma forma mais simples de resolver isso? O DevOps que pensa assim não espera o problema virar incidente, ele enxerga o atrito antes, propõe a solução antes, e entrega antes. Essa antecipação é o que nenhuma IA faz sozinha, porque ela responde a perguntas. Você formula as perguntas certas.

E caso você que está lendo precise de uma direção, eu tenho uma sugestão simples:

ESTUDA → DOCUMENTA → ENSINA → PUBLICA

1. Estuda. Tanto tecnologias quanto métodos. Se não sabe por onde começar, siga um roadmap.

2. Documenta tudo o que você aprende. O conhecimento que não está registrado se perde.

3. Ensina antes de se sentir pronto. Ensinar expõe as lacunas que você nem sabia que tinha e, como bônus, fixa o que aprendeu. Inclusive, esse artigo é o meu passo 3. Escrevi antes de me sentir pronto. E foi exatamente isso que me forçou a organizar o que eu realmente sabia e expôs o que eu ainda precisava entender melhor.

4. Entrega publicamente o que você está aprendendo. Compromisso público vira combustível. Posta. Mostra o seu trabalho. Porque essa é a única prova que você pode dar para o mercado de trabalho de que você realmente sabe o que diz que sabe. Ensine. Tem gente que só vai entender tal conceito com a sua forma de explicar. Poste vídeos, artigos, posts, suba projetos no GitHub, mas publique o que você anda fazendo.

Bom, esse é o meu primeiro artigo. E ele nasce exatamente do ponto onde eu parei de me enganar e comecei a construir de verdade, sem plano B, sem saída. Se algo aqui te incomodou, ótimo. Incômodo é o primeiro sinal de que você está prestando atenção.

Os próximos artigos vão ser diferentes desse. Menos reflexão, mais terminal. Cada tópico que eu estudar vira conteúdo aqui: com os comandos que rodei, os erros que cometi e o raciocínio que usei pra resolver. Se você quer aprender DevOps, sem filtros, pode me acompanhar nessa caminhada. Vai valer o seu tempo.

Vinicius Aguilar — DevOps Engineer