A complexidade das arquiteturas modernas em nuvem traz um desafio inevitável: como garantir que seus sistemas realmente se comportam conforme esperado quando uma falha acontece? Você configurou redundância, alta disponibilidade, failover automático, mas já testou se tudo isso funciona de verdade, sob pressão, em condições reais?

É exatamente essa a proposta da Engenharia de Caos (Chaos Engineering): injetar falhas controladas na infraestrutura para validar a resiliência antes que incidentes reais exponham fragilidades. E no Azure, a ferramenta nativa para isso é o Azure Chaos Studio.

Neste artigo, vamos explorar como o Azure Chaos Studio funciona, como estruturar experimentos de caos de forma segura e como integrá-lo ao ciclo de vida de aplicações críticas no Azure.

---

O que é Engenharia de Caos?

Engenharia de Caos é uma disciplina que nasceu no Netflix (com o famoso Chaos Monkey) e se tornou prática essencial em organizações que operam sistemas distribuídos em larga escala. A ideia central é simples:

Se você não testa falhas de forma intencional, a primeira vez que seu sistema vai ser testado será durante um incidente real e provavelmente no pior momento possível.

Os princípios fundamentais incluem:

• Definir o estado estável: entender como o sistema se comporta em condições normais (métricas de latência, throughput, taxa de erro).
• Formular hipóteses: "se o banco de dados primário ficar indisponível, o failover para a réplica deve ocorrer em menos de 30 segundos".
• Injetar falhas controladas: simular cenários como queda de VM, partição de rede, alta latência ou esgotamento de CPU.
• Observar e aprender: comparar o comportamento real com a hipótese e corrigir as lacunas encontradas.

---

Azure Chaos Studio: visão geral

O Azure Chaos Studio é um serviço gerenciado do Azure que permite criar, gerenciar e executar experimentos de caos contra recursos do Azure (e também contra aplicações rodando em VMs ou contêineres).

Conceitos principais

Conceito	Descrição
Experimento	A unidade principal de execução. Define quais falhas serão injetadas, contra quais recursos, por quanto tempo e em que ordem.
Fault (Falha)	A ação de caos propriamente dita, por exemplo, desligar uma VM, adicionar latência de rede ou derrubar um pod no AKS.
Target (Alvo)	O recurso do Azure que será afetado pelo experimento (VM, VMSS, AKS, Cosmos DB, App Service, etc.).
Capability	A falha específica que pode ser executada contra um alvo. Cada tipo de recurso tem suas capabilities disponíveis.
Selector	Um filtro que define quais instâncias específicas do alvo serão afetadas.
Branch e Step	Permitem organizar falhas em paralelo (branches) e em sequência (steps) dentro de um experimento.

Dois modelos de falha

O Chaos Studio oferece dois modelos de injeção de falha:

1. Service-direct faults: falhas executadas diretamente contra recursos do Azure por meio da API do plano de controle. Não exigem agente instalado. Exemplos:

   • Failover do Cosmos DB
   • Desligar/reiniciar uma VM
   • Alterar regras de NSG para simular partição de rede
   • Failover do Azure SQL Database
   • Desabilitar uma réplica do Azure Cache for Redis

2. Agent-based faults: falhas executadas por um agente instalado dentro da VM ou contêiner. Permitem simulações mais granulares no nível do sistema operacional:

   • Estresse de CPU, memória ou disco
   • Latência ou perda de pacotes de rede (via tc no Linux ou filtros no Windows)
   • Parar/reiniciar processos específicos
   • Simular pressão de DNS

---

Configurando o Azure Chaos Studio

Pré-requisitos

Antes de criar experimentos, você precisa:

1. Registrar o provider: o namespace Microsoft.Chaos precisa estar registrado na subscription.

az provider register --namespace Microsoft.Chaos
az provider show --namespace Microsoft.Chaos --query "registrationState"

2. Habilitar targets: cada recurso que será alvo de experimentos precisa ser habilitado como target no Chaos Studio.

# Habilitar uma VM como target para falhas service-direct
az chaos target create \
  --resource-group meu-rg \
  --target-type Microsoft-VirtualMachine \
  --resource-name minha-vm \
  --resource-type Microsoft.Compute/virtualMachines \
  --location brazilsouth

# Habilitar capabilities para a VM
az chaos capability create \
  --resource-group meu-rg \
  --target-type Microsoft-VirtualMachine \
  --resource-name minha-vm \
  --resource-type Microsoft.Compute/virtualMachines \
  --capability-name Shutdown-1.0 \
  --location brazilsouth

3. Configurar permissões (RBAC): o experimento de caos é um recurso do Azure com uma Managed Identity. Essa identity precisa ter as permissões adequadas nos recursos-alvo.

# Atribuir role de contribuidor na VM alvo
az role assignment create \
  --role "Virtual Machine Contributor" \
  --assignee <chaos-experiment-principal-id> \
  --scope /subscriptions/<sub-id>/resourceGroups/meu-rg/providers/Microsoft.Compute/virtualMachines/minha-vm

Dica de segurança: use roles com escopo mínimo necessário. Evite atribuir Contributor no nível de subscription ou resource group inteiro.

---

Criando um experimento de caos

Vamos criar um experimento prático que simula um cenário comum: queda de uma VM em uma arquitetura com Load Balancer e múltiplas instâncias.

Hipótese

"Se uma das VMs do backend ficar indisponível, o Azure Load Balancer deve detectar a falha via health probe em até 15 segundos e redistribuir o tráfego para as VMs restantes, mantendo a taxa de erro abaixo de 1%."

Definição do experimento (JSON)

{
  "location": "brazilsouth",
  "identity": {
    "type": "SystemAssigned"
  },
  "properties": {
    "selectors": [
      {
        "type": "List",
        "id": "selector-vm-backend",
        "targets": [
          {
            "type": "ChaosTarget",
            "id": "/subscriptions/<sub-id>/resourceGroups/meu-rg/providers/Microsoft.Compute/virtualMachines/vm-backend-01/providers/Microsoft.Chaos/targets/Microsoft-VirtualMachine"
          }
        ]
      }
    ],
    "steps": [
      {
        "name": "Step1-Shutdown-VM",
        "branches": [
          {
            "name": "Branch1",
            "actions": [
              {
                "type": "continuous",
                "name": "urn:csci:microsoft:virtualMachine:shutdown/1.0",
                "duration": "PT10M",
                "parameters": [
                  {
                    "key": "abruptShutdown",
                    "value": "true"
                  }
                ],
                "selectorId": "selector-vm-backend"
              }
            ]
          }
        ]
      }
    ]
  }
}

Criando via CLI

az chaos experiment create \
  --resource-group meu-rg \
  --name exp-vm-shutdown-backend \
  --location brazilsouth \
  --chaos-experiment-file experiment.json

Executando o experimento

az chaos experiment start \
  --resource-group meu-rg \
  --name exp-vm-shutdown-backend

---

Cenários práticos de experimentos

1. Resiliência de AKS: matando pods e nós

Se você já leu o artigo sobre [AKS multi-cluster para IA], sabe que resiliência em Kubernetes exige mais do que apenas réplicas, é preciso validar que o cluster se recupera de falhas em nós e pods.

{
  "name": "urn:csci:microsoft:azureKubernetesServiceChaosMesh:podChaos/2.1",
  "duration": "PT5M",
  "parameters": [
    {
      "key": "jsonSpec",
      "value": "{\"action\":\"pod-kill\",\"mode\":\"fixed\",\"value\":\"2\",\"selector\":{\"namespaces\":[\"production\"],\"labelSelectors\":{\"app\":\"api-gateway\"}}}"
    }
  ]
}

O que observar:

• O Horizontal Pod Autoscaler (HPA) recria os pods dentro do tempo esperado?
• O Service do Kubernetes redistribui o tráfego corretamente?
• As métricas no Azure Monitor refletem o incidente?
• Os alertas configurados disparam conforme esperado?

2. Failover de banco de dados

Testar o failover do Cosmos DB ou Azure SQL para validar se a aplicação reconecta automaticamente:

# Cosmos DB failover (service-direct)
az chaos capability create \
  --resource-group meu-rg \
  --target-type Microsoft-CosmosDB \
  --resource-name meu-cosmos \
  --resource-type Microsoft.DocumentDB/databaseAccounts \
  --capability-name Failover-1.0

Hipótese: "O failover do Cosmos DB para a região secundária deve completar em menos de 60 segundos, e a aplicação deve reconectar automaticamente sem intervenção manual."

3. Simulação de degradação de rede

Usando falhas agent-based para injetar latência e perda de pacotes:

{
  "name": "urn:csci:microsoft:agent:networkLatency/1.0",
  "duration": "PT10M",
  "parameters": [
    {
      "key": "latencyInMilliseconds",
      "value": "300"
    },
    {
      "key": "destinationFilters",
      "value": "[{\"address\":\"10.0.1.0/24\",\"portRange\":\"443\"}]"
    }
  ]
}

O que observar:

• A aplicação lida graciosamente com latência elevada (timeouts configurados corretamente)?
• Circuit breakers são acionados conforme esperado?
• A experiência do usuário degrada de forma controlada (degradação graciosa)?

4. Estresse de recursos (CPU/Memória)

{
  "name": "urn:csci:microsoft:agent:cpuPressure/1.0",
  "duration": "PT5M",
  "parameters": [
    {
      "key": "pressureLevel",
      "value": "90"
    }
  ]
}

O que observar:

• O autoscaling (VMSS ou AKS) reage dentro do tempo esperado?
• Alertas de métricas são disparados?
• A aplicação prioriza operações críticas sob pressão?

---

Integrando Chaos Studio com Observabilidade

Um experimento de caos sem observabilidade é como dirigir com os olhos fechados. Você precisa de visibilidade total para avaliar o impacto das falhas injetadas.

Azure Monitor + Chaos Studio

Configure dashboards e alertas no Azure Monitor para acompanhar o experimento em tempo real:

// Query KQL para correlacionar eventos de caos com métricas da aplicação
let chaosStart = datetime(2026-03-10T14:00:00Z);
let chaosEnd = datetime(2026-03-10T14:10:00Z);
requests
| where timestamp between (chaosStart .. chaosEnd)
| summarize 
    totalRequests = count(),
    failedRequests = countif(success == false),
    avgDuration = avg(duration),
    p99Duration = percentile(duration, 99)
  by bin(timestamp, 30s)
| extend errorRate = round(100.0 * failedRequests / totalRequests, 2)
| order by timestamp asc

Criando um Workbook de Chaos Engineering

Se você já utiliza [Azure Workbooks] para visualização de dados, crie um workbook dedicado a experimentos de caos que inclua:

• Painel de estado estável: métricas baseline (latência P50/P95/P99, taxa de erro, throughput).
• Painel de impacto: as mesmas métricas durante e após a injeção de falha.
• Painel de recuperação: tempo até retorno ao estado estável (MTTR).
• Histórico de experimentos: resultados acumulados ao longo do tempo para medir a evolução da resiliência.

Alertas inteligentes

Configure alertas que diferenciem degradações esperadas (durante experimentos) de incidentes reais:

# Tag os recursos durante experimentos para suprimir alertas
az tag update \
  --resource-id <resource-id> \
  --operation merge \
  --tags chaos-experiment=active

# Nas alert rules, filtre pela ausência da tag
# Isso evita alertas falsos durante janelas de teste

---

Boas práticas para Engenharia de Caos no Azure

1. Comece pequeno e em ambientes não produtivos

Não comece injetando falhas em produção no primeiro dia. A jornada recomendada é:

Dev → Staging → Produção (horário de menor impacto) → Produção (horário de pico)

2. Sempre defina hipóteses antes de executar

Cada experimento deve ter:

• ✅ Uma hipótese clara e mensurável
• ✅ Métricas de sucesso/falha definidas
• ✅ Um plano de rollback (como interromper o experimento se algo der errado)
• ✅ Stakeholders informados

3. Use o conceito de "blast radius" controlado

O Chaos Studio permite limitar o raio de explosão dos experimentos:

• Selectors: afete apenas instâncias específicas, não todas.
• Duration: mantenha durações curtas inicialmente (5-10 min).
• Abort conditions: configure condições de parada automática se métricas críticas ultrapassarem um limiar.

4. Automatize no CI/CD

Integre experimentos de caos no pipeline de deployment para validar resiliência automaticamente:

# Exemplo com GitHub Actions
- name: Run Chaos Experiment
  uses: azure/cli@v2
  with:
    inlineScript: |
      # Iniciar experimento
      az chaos experiment start \
        --resource-group ${{ env.RG }} \
        --name exp-failover-validation

      # Aguardar conclusão
      az chaos experiment execution show \
        --resource-group ${{ env.RG }} \
        --experiment-name exp-failover-validation \
        --execution-id latest \
        --query "properties.status" -o tsv

      # Validar resultado
      STATUS=$(az chaos experiment execution show \
        --resource-group ${{ env.RG }} \
        --experiment-name exp-failover-validation \
        --execution-id latest \
        --query "properties.status" -o tsv)
      
      if [ "$STATUS" != "Success" ]; then
        echo "::error::Chaos experiment failed!"
        exit 1
      fi

5. Documente e compartilhe os resultados

Cada experimento deve gerar um relatório com:

• Hipótese original
• Configuração do experimento
• Resultados observados (métricas, logs, alertas)
• Lacunas encontradas
• Ações corretivas implementadas
• Data do próximo re-teste

Isso cria um ciclo contínuo de melhoria:

Hipótese → Experimento → Observação → Correção → Re-teste → ✅

---

Chaos Studio e conformidade

Uma preocupação comum é: "Engenharia de Caos não vai conflitar com requisitos de compliance?"

Na verdade, é o contrário. Frameworks como ISO 27001, SOC 2 e NIST recomendam testes de resiliência regulares. O Azure Chaos Studio facilita a conformidade porque:

• Todos os experimentos ficam registrados no Activity Log do Azure.
• Permissões são controladas via RBAC com Managed Identity.
• Os experimentos podem ser auditados e rastreados.
• É possível restringir quais tipos de falhas e quais recursos podem ser alvo usando Azure Policy.

# Exemplo: Policy para permitir Chaos Studio apenas em resource groups de staging
az policy assignment create \
  --name "restrict-chaos-to-staging" \
  --policy <policy-definition-id> \
  --scope /subscriptions/<sub-id> \
  --params '{"allowedResourceGroups": {"value": ["rg-staging", "rg-chaos-lab"]}}'

---

Custos

O Azure Chaos Studio segue um modelo de cobrança por ação-minuto. Cada minuto de falha injetada em um recurso conta como uma ação-minuto. O custo é relativamente baixo, especialmente quando comparado ao custo de um incidente real não testado.

Algumas dicas para otimizar custos:

• Mantenha experimentos com durações curtas (5-15 min são suficientes para a maioria dos cenários).
• Consolide múltiplas falhas em um único experimento usando branches paralelos.
• Execute em ambientes de staging com recursos menores (VMs de SKU inferior, menos réplicas).
• Use tags para rastrear custos de Chaos Studio separadamente via Cost Management.

---

Exemplo completo: Game Day de resiliência

Um Game Day é um evento estruturado onde a equipe executa múltiplos experimentos de caos para validar a resiliência de uma aplicação de ponta a ponta. Veja como estruturar um:

Preparação (1-2 semanas antes)

1. Definir o escopo: quais serviços serão testados.
2. Mapear dependências: entender o fluxo completo da aplicação.
3. Definir hipóteses para cada cenário.
4. Configurar observabilidade (dashboards, alertas, queries KQL).
5. Comunicar stakeholders e definir janela de execução.

Execução (dia do Game Day)

Hora	Cenário	Falha	Hipótese
10:00	Perda de VM	Shutdown de 1 VM no VMSS	LB redistribui em <15s
10:30	Failover de DB	Failover do Cosmos DB	Reconexão automática em <60s
11:00	Degradação de rede	300ms de latência adicional	Circuit breaker ativa em <10s
11:30	Estresse de CPU	90% de CPU por 5min	Autoscaling adiciona instância em <3min
14:00	Perda de zona	Desligar VMs na zona 1	Tráfego redireciona para zonas 2 e 3
14:30	Combinação	Latência + CPU + perda de pod	Sistema degrada graciosamente

Pós-execução

1. Documentar resultados de cada cenário.
2. Classificar falhas encontradas por severidade.
3. Criar work items para correções.
4. Agendar re-teste após correções.
5. Atualizar runbooks operacionais com aprendizados.

---

Conclusão

A Engenharia de Caos não é sobre "quebrar coisas por diversão", é sobre construir confiança real na resiliência dos seus sistemas. Com o Azure Chaos Studio, você tem uma ferramenta nativa, integrada ao ecossistema Azure, que permite validar de forma segura e controlada se suas arquiteturas realmente se comportam conforme projetado quando falhas acontecem.

Se você já investiu em alta disponibilidade, disaster recovery e observabilidade, o próximo passo natural é provar que tudo funciona. Chaos Studio é essa prova.

Comece com um cenário simples, desligue uma VM e observe. Evolua para failovers de banco de dados, degradação de rede e Game Days completos. A cada experimento, você não apenas encontra fragilidades: você constrói uma cultura de resiliência que beneficia toda a organização.