Azure-Openai

No post anterior, eu desenhei um assistente que consulta runbooks, mantém contexto e chama ferramentas de infraestrutura. A arquitetura fazia sentido, mas ainda tinha um problema: os exemplos eram recortes. Faltavam os arquivos que conectam uma parte à outra. Neste post, parto de uma aplicação que roda localmente sem Azure e levo a mesma vertical slice para Container Apps, Azure OpenAI e Azure AI Search. O código está no repositório agentic-infra-handbook, em labs/personal-assistant. O README do lab também traz um passo a passo independente para executar o projeto localmente e fazer o deploy no Azure, incluindo App Registration, configuração do AZD, callback de autenticação, validação e limpeza dos recursos. ...

Até aqui, a série construiu duas coisas separadas: no post 1, um agent que fala com AKS via aks-mcp para diagnosticar o cluster; nos posts 2 e 3, um watchdog que observa o consumo de TPM no Azure OpenAI e decide o quão urgente um alerta deve ser. Os dois funcionam isoladamente, e isolados já entregam valor. Mas, separados, eles também deixam sem resposta a pergunta mais óbvia de todas: quando o consumo de tokens dispara do nada, a primeira coisa que qualquer SRE pergunta é “alguém fez deploy?”. Hoje essa resposta ainda é manual, alguém olhando o alerta do watchdog em uma aba e o dashboard do AKS em outra. ...

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

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

Décimo segundo post da série. No anterior, operamos Azure OpenAI com HA e retry decente. Agora vem a parte menos charmosa: quando o diagrama bonito encosta na vida real. Este post está organizado em cenários reais de falha. Cada um segue: Sintomas → Diagnóstico → Root cause → Resolução → Prevenção. Leia uma vez pra formar repertório. Depois deixa salvo. Você ainda vai voltar aqui. tl;dr: Este playbook cobre cinco falhas comuns em workloads de AI: driver, CUDA OOM, pod Pending, 429 e latência. A meta é reduzir o tempo entre sintoma, hipótese e ação segura. ...

Décimo primeiro post da série. No anterior, a gente montou a plataforma de AI self-service com multi-tenancy e scheduling. Agora vem o serviço que todo mundo quer usar: Azure OpenAI, e como rodar isso sem tomar 429 na cara. tl;dr: Em produção, Azure OpenAI pede conta de TPM e RPM, retry com jitter e rota de escape entre deployments e regiões. Se você trata 429 como azar, o problema volta no próximo pico. ...

Nono post da série. No anterior, blindamos a plataforma contra prompt injection e data leakage. Agora: como não falir no processo. tl;dr: GPU cara sem controle vira incidente financeiro. Resolva com auto-shutdown, right-sizing, Spot, budgets e escolha certa entre Standard e PTU. A segunda-feira de R$650.000 Segunda de manhã. Café na mão, e-mail do financeiro no subject line: “URGENTE: fatura Azure $127.000, explicar.” Forecast era $42.000. Dois VMs ND96isr_H100_v5, provisionados três semanas atrás pra um “experimento rápido”, nunca desligados. A ~$98/hora cada, rodando 24/7 por três semanas: $33.000 em GPU parada. Ninguém usando. Ninguém lembrava que existiam. ...

Sétimo post da série. No anterior, colocamos modelos em produção com pipelines CI/CD. Agora: como saber se estão saudáveis? tl;dr: Dashboard verde não basta. Você precisa observar GPU, custo, modelo, segurança, rede e dados ao mesmo tempo. A falha silenciosa Seu endpoint Azure OpenAI retorna 200 OK em todo request. Latência normal, P95 abaixo de 800ms. CPU e memória dentro dos thresholds. Kubernetes mostra pods saudáveis, sem restarts. Por toda métrica de infra que você confia, o sistema está perfeito. ...