Posts

Seu agent de diagnóstico vai bem numa interação. Aí o mesmo alerta volta na semana seguinte e ele zera a memória. Não lembra que já investigou. Não lembra que a causa raiz era aquele cronjob que explode memória toda quarta às 3h da manhã. Agent sem memória é como engenheiro que perde o caderno toda segunda. Sabe trabalhar. Só reaprende as mesmas coisas o tempo todo. O mapa pro profissional de infra Conceito de Memória O que faz Equivalente em infra Short-term memory Contexto da conversa atual Buffer de request (dados in-flight) Long-term memory Informações que persistem entre sessões Database, persistent storage Episodic memory Lembranças de interações passadas Logs, audit trail Semantic memory Conhecimento geral acumulado Knowledge base, wiki Working memory O que está “ativo” na cabeça do agent Cache, working set State Configuração atual do agent Estado do pod, configmap Consistency Garantia de que memória é correta Consistency model do banco Por que memória é difícil em agents LLMs são stateless. Cada request é independente. O modelo não “lembra” nada entre chamadas. Toda memória é simulada via contexto. ...

No post anterior, eu destrinchei como agents funcionam: LLM, tools e loop. Agora a conversa muda de nível. O problema não é fazer um demo de 5 minutos. É projetar um agent que aguente produção, rode 24/7 e não precise de babá. Continua sendo design de sistema, com as perguntas de sempre: quais são os requisitos, quais os failure modes, como escala e como monitora? As 5 decisões de design Projetar um agent normalmente vira 5 decisões: ...

Meu Watch Later tinha 302 vídeos. Tutoriais de Azure, receita de panqueca japonesa, debates teológicos, vídeo de hamster escapando de labirinto. Tudo junto, tudo misturado, completamente inútil como lista. Eu nunca ia assistir aquilo daquele jeito. Ninguém assiste. O Watch Later do YouTube é onde vídeo vai pra morrer. Resolvi limpar a bagunça inteira sem instalar extensão, sem dar permissão pra app de terceiro, sem arrastar vídeo por vídeo. Só JavaScript no console do navegador e uma IA pra categorizar. ...

Terça-feira, 14h. Seu colega mostra um demo: ele pede pro “agent” verificar o status de 5 servidores, identificar qual tem mais CPU usage, e criar um ticket pra investigação. O agent faz tudo sozinho. Sem scripts. Sem runbooks. Seu primeiro pensamento: “Isso é só um LLM chamando APIs, certo?” Sim. E não. O conceito é simples. A parte trabalhosa é fazer isso funcionar com segurança e previsibilidade em produção. É aí que mora a engenharia de verdade. ...

No post anterior, o watchdog de quota do Azure OpenAI era um script com if pct_of_tpm > 0.8: alert. Funciona, mas carrega um problema que qualquer pessoa que já configurou alerta de monitoramento conhece de cor: threshold fixo não entende contexto. Um batch job que sempre consome 90% de TPM por 10 minutos no fechamento do mês e depois volta ao normal é, para o script, o mesmo evento que algum agent solto no ambiente entrando em loop e queimando tokens sem parar. Os dois cruzam o mesmo threshold; só um deles merece acordar alguém. ...

Na Parte 1, montamos a base do Internal Developer Platform: Dev Center, templates Bicep para provisionamento self-service e AKS como runtime compartilhado com multi-tenancy. Aqui entram as camadas que deixam a plataforma segura, observável e governada. tl;dr: Governança com Azure Policy, observabilidade com App Insights + Grafana, e segurança com Workload Identity e Entra ID. Sem essas camadas, o IDP vira self-service sem controle. Governança: Azure Policy como guardrail A plataforma precisa garantir que, independente do que o desenvolvedor faça dentro do seu namespace ou resource group, certos padrões sejam mantidos. Azure Policy é a ferramenta para isso. ...

Você já implementou SLIs, SLOs e Error Budgets, automatizou resposta a incidentes, validou resiliência com Engenharia de Caos e até conduziu investigações cross-cloud. Mas quando um novo desenvolvedor entra no time e precisa provisionar um ambiente completo para começar a codar, quanto tempo leva? Dias? Semanas? Se a resposta for mais que minutos, você tem um problema de plataforma. Platform Engineering é isso: criar uma camada de abstração para que desenvolvedores trabalhem com autonomia sem virar especialistas em infraestrutura. Em vez de abrir ticket para o time de DevOps pedindo “um cluster com banco e fila”, o desenvolvedor entra num portal self-service, escolhe um template e, em minutos, tem um ambiente completo dentro dos padrões da organização. ...

Na Parte 1, falamos de cultura blameless, template de postmortem, queries KQL e automação com Logic Apps. Aqui, o foco é ligar o postmortem ao fluxo de engenharia: Azure DevOps, métricas de eficácia, cenários avançados e reuniões de revisão. tl;dr: O postmortem sem rastreamento vira documento esquecido. Ligue ao Azure DevOps para action items, use Workbooks para métricas de eficácia e vincule ao Error Budget para decidir congelamento de deploys. Integrando postmortems com Azure DevOps O Azure DevOps é o lugar natural para rastrear action items de postmortems. A chave é conectar os insights do postmortem diretamente ao backlog de engenharia. ...

Você já automatizou alertas e runbooks, definiu SLIs, SLOs e Error Budgets e validou resiliência com Engenharia de Caos. Mas quando o incidente termina, o que acontece? Na maioria das organizações, nada. O alerta é resolvido e todo mundo segue a vida. Até o mesmo problema voltar. Sem uma análise pós-incidente decente, a organização repete os mesmos erros. O postmortem blameless transforma falhas em aprendizado e evita que incidentes recorrentes continuem corroendo seu Error Budget. ...

O time de ML treinou um modelo que funciona no notebook. Accuracy de 94%. Todo mundo comemora. Aí vem a parte menos glamourosa: colocar isso em produção. “Dá pra colocar isso numa API com 99.9% de uptime, latência < 200ms e 10K requests por segundo?” É aqui que system design de ML cai no colo de infra. A boa notícia é que a maior parte do problema parece familiar. Serving, rollout, observabilidade e capacity planning continuam sendo trabalho de sistema distribuído. O pedaço realmente diferente existe, mas é menor do que o hype sugere. ...