Posts

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. ...

No post anterior eu expliquei o que é MCP e como um agent decide sozinho a sequência de chamadas a partir das tools que tem disponíveis. Agora vamos construir um caso de uso real, pequeno o bastante para terminar em um fim de semana: um MCP server que observa o consumo de tokens do seu deployment de Azure OpenAI / AI Foundry e avisa no Slack ou por email antes do 429 acontecer. Não depois, quando o cliente já engoliu o erro em produção. ...

Você mudou o system prompt. O time de ML acha que ficou melhor. Mas “achar” não é métrica. Em infra, você não faz deploy sem rodar tests. Em AI, o equivalente é evals. LLM Evals são testes automatizados que medem a qualidade das respostas do modelo. É o seu test suite pro AI. Sem evals, toda mudança no pipeline (prompt, modelo, RAG, chunking) é um deploy no escuro. tl;dr: Evals são o baseline que separa melhoria real de opinião. Monte um golden dataset pequeno, rode métricas simples primeiro e compare toda mudança de prompt, modelo ou RAG antes de subir pra produção. ...

Você monta um pipeline de RAG, conecta no Azure OpenAI, e as respostas saem meia-boca. Genéricas. Às vezes o modelo ignora o contexto. Às vezes inventa. O modelo pode ser ótimo, mas a forma como você monta o input pesa muito no resultado. Context engineering é a disciplina de montar esse input de forma que o modelo entregue o que você precisa. Não é só “prompt engineering” com nome bonito. É trabalho de estrutura, constraints e trade-offs. ...

Três anos atrás, a pergunta que eu mais ouvia era: “qual é o melhor prompt?” Dois anos atrás, mudou pra: “como faço RAG?” Ano passado: “como construo um agent?” Esse ano, a conversa mudou de tamanho. Ninguém está perguntando só como fazer um chatbot melhor. A pergunta agora é como uma empresa inteira opera com agents, com governança, observabilidade e permissões de verdade. Essa sequência conta uma história boa sobre maturidade. E vale conectar os pontos porque ela explica por que tanta gente ainda discute o problema errado. ...

O VP de produto chega na daily: “Quero que o chatbot responda perguntas sobre nossa documentação interna. Tem 2000 páginas de runbooks, políticas, e procedimentos. O ChatGPT não sabe nada disso.” O time de ML responde: “Vamos implementar RAG.” Todo mundo faz que sim com a cabeça. Você fica com a tarefa de provisionar a infra. Antes de subir recurso, vale entender o que RAG realmente faz por dentro. tl;dr: RAG é pipeline de indexação + retrieval + prompt. O que mais quebra em produção é chunk ruim, busca ruim e custo do LLM, não falta de fine-tuning. ...

Em algum momento nos últimos meses, alguém do seu time apareceu falando sobre um “AI agent” ou um “MCP server” e pediu acesso, um deploy ou uma explicação para o CISO sobre por que agora existe um processo não determinístico com permissão para encostar no cluster de produção. Este post é o modelo mental que eu gostaria de ter tido antes de tocar nisso pela primeira vez. Sem hype e com um exemplo real rodando no Azure ao longo do caminho. ...