Azure

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

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

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

Último post da série. No anterior, a gente montou o framework de adoção em 6 fases. Agora vem a cola final. Você já fala infraestrutura com fluência. AI não é idioma alienígena. É um dialeto com nome ruim e sigla demais. Este glossário faz a ponte entre os termos de AI e os conceitos de infra que você já usa todo dia. tl;dr: Use este post como tabela de tradução rápida. Se um termo de AI travar a conversa, volte aqui e mapeie para o equivalente de infra antes de discutir ferramenta ou arquitetura. ...

Décimo quarto post da série. No anterior, a gente usou AI no próprio trabalho de infra. Agora o escopo aumenta: como levar uma organização inteira do “vamos usar AI” pra uma plataforma governada e escalável. tl;dr: Adoção de AI sem framework vira custo espalhado, segurança frouxa e GPU ociosa. As 6 fases (assessment, foundation, pilot, scale, govern, optimize) evitam repetir os mesmos erros de cloud adoption. As melhores intenções, os piores resultados Seu CTO entra no all-hands e manda: “vamos com tudo em AI”. A sala anima. Antes do fim da reunião já tem thread no Slack sobre GPU, copiloto, agente e orçamento que ninguém pediu. ...