SRE No Azure

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. 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. Policies essenciais para um IDP # 1. Exigir tags obrigatórias em todos os recursos az policy assignment create \ --name "require-platform-tags" \ --policy "/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b590-94f262ecfa99" \ --params '{"tagName": {"value": "managedBy"}, "tagValue": {"value": "deployment-environments"}}' \ --scope "/subscriptions/<sub-id>" # 2. Bloquear SKUs não permitidos (evitar VMs caras em dev) az policy assignment create \ --name "restrict-vm-skus-dev" \ --policy "/providers/Microsoft.Authorization/policyDefinitions/cccc23c7-8427-4f53-ad12-b6a63eb452b3" \ --params '{"listOfAllowedSKUs": {"value": ["Standard_B1ms", "Standard_B2ms", "Standard_B4ms", "Standard_D2ds_v4"]}}' \ --scope "/subscriptions/<dev-sub-id>" # 3. Exigir HTTPS em todos os App Services az policy assignment create \ --name "enforce-https" \ --policy "/providers/Microsoft.Authorization/policyDefinitions/a4af4a39-4135-47fb-b175-47fbdf85311d" \ --scope "/subscriptions/<sub-id>" Policy customizada: expiração automática de ambientes dev Um problema clássico de plataformas é o acúmulo de ambientes abandonados. Vamos criar uma policy que marca ambientes dev criados há mais de 14 dias para exclusão: ...

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. 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. Criando um work item para registrar postmortems Você pode usar tipos existentes como Bug ou criar um Work Item personalizado com campos específicos: ...

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