Azure

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

Azure AI Foundry: do zero à produção O que eu cubro quando um cliente pergunta “queremos construir aplicações com IA no Azure, por onde começamos?” TL;DR: Azure AI Foundry é a plataforma unificada para aplicações de IA no Azure. Comece com Standard PAYGO, use Priority Processing de forma seletiva quando latência importa mas o tráfego é variável, e migre a carga base previsível para PTU quando a utilização passar de 60-70%. Use o ptucalc.com (código no GitHub) para modelar custos antes de comprometer. ...

De bombeiro a engenheiro de plataforma: skills customizados para o Azure SRE Agent TL;DR: O Azure SRE Agent é excelente em resposta reativa a incidentes, mas não cobre operações proativas por padrão. Criei um pack open-source com 8 skills customizados que adicionam auditorias de governança, relatórios FinOps, capacity planning, postmortems, e mais. Combinados com Scheduled Investigations, eles movem suas operações de reativas para proativas. Como uma conversa com um cliente que nunca tinha ouvido falar de SRE Agent me levou a criar um pack de skills que transforma o agente de reativo para proativo. ...

Os quatro posts anteriores construíram agents desenhados por mim, em que eu sei exatamente o que cada tool faz e lembro de cabeça qual flag restringe o quê. Isso funciona até o momento em que outro time, sem ter lido esta série, sobe o próprio agent na mesma plataforma. A partir daí, a pergunta deixa de ser “essa tool é segura?” e passa a ser “como eu sei, no nível organizacional, o que está rodando e com quais permissões?”. É nesse momento que governança deixa de ser boa prática e vira pré-requisito. ...

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

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