Phase 17 - Lesson 24

Engenharia de Caos para LLM em Produção

A engenharia de caos para LLMs é uma disciplina própria em 2026. Pré-requisitos antes de executar experimentos em produção: SLI/SLO definidos, observabilidade de rastreamento+métrica+log, rollback automatizado, runbooks e plantão. A arquitetura possui quatro planos: controle (agendador de experimentos), alvo (serviços, infraestrutura, armazenamentos de dados), segurança (proteções + aborto + filtros de tráfego), observabilidade (métricas + rastreamentos + logs) e feedback (para ajustes de SLO). As barreiras de proteção (guardrails) são obrigatórias: alertas de taxa de queima (burn-rate) pausam os experimentos se a queima diária do orçamento de erro for maior que duas vezes o esperado; janelas de supressão + correlação de ID de rastreamento eliminam ruídos de alerta. Cadência: pequeno canário semanal + revisão de SLO; game day mensal + pós-morte (postmortem); auditoria trimestral de resiliência entre equipes + mapeamento de dependências. Experimentos específicos de LLM: sobrecarga de memória, falhas de rede, interrupções de provedores, prompts malformados e tempestades de despejo (eviction storms) no KV cache. Ferramentas: Harness Chaos Engineering (recomendações derivadas de LLM, redução do raio de explosão, integração com ferramentas MCP); LitmusChaos (CNCF); Chaos Mesh (CNCF nativo de Kubernetes).

Tipo: Learn Linguagens: Python (stdlib, executor de experimentos de caos de brinquedo) Pré-requisitos: Phase 17 · 23 (SRE for AI), Phase 17 · 13 (Observability) Tempo: ~60 minutos

Objetivos de Aprendizagem

• Nomear os cinco pré-requisitos da engenharia de caos (SLI/SLO, observabilidade, rollback, runbooks, plantão) e explicar por que pular qualquer um deles interrompe a prática.
• Esquematizar os quatro planos (controle, alvo, segurança, observabilidade) e o ciclo de feedback para o SLO.
• Enumerar cinco experimentos específicos de LLM (sobrecarga de memória, falha de rede, indisponibilidade do provedor, prompt malformado, tempestade de despejo no KV cache).
• Escolher uma ferramenta — Harness, LitmusChaos ou Chaos Mesh — dada a pilha tecnológica.

O Problema

O teste de caos em pilhas tradicionais é consolidado. Pilhas de LLM adicionam novos modos de falha. Um prompt de 4K tokens com um caractere corrompido paralisa o tokenizador por 12 segundos. Um provedor upstream retorna 429; seu gateway tenta novamente; seu serviço sofre OOM devido à concorrência ampliada pelas tentativas de repetição. Uma tempestade de despejo no KV cache sob carga em rajadas causa cascatas de re-preenchimento inicial (re-prefill) que saturam a computação.

Nenhum desses problemas aparece em testes unitários. A engenharia de caos é a maneira de descobri-los antes dos usuários.

O Conceito

Pré-requisitos

Não execute caos em produção sem:

1. SLI/SLO — indicadores e objetivos de nível de serviço definidos.
2. Observabilidade — rastreamentos, métricas e logs conectados a painéis (dashboards).
3. Rollback automatizado — rollback de flag de política (Phase 17 · 20).
4. Runbooks — estruturados (Phase 17 · 23).
5. Plantão — alguém para responder.

A ausência de qualquer um deles significa que o caos se transformará em um incidente real.

Quatro planos + feedback

Plano de controle (control plane) — agendador de experimentos (fluxo de trabalho Litmus, agendamento do Chaos Mesh, interface do Harness).

Plano alvo (target plane) — serviços, pods, nós, balanceadores de carga, armazenamentos de dados.

Plano de segurança (safety plane) — botão de desligamento de emergência (kill switch), janelas de supressão, limites de raio de explosão, barreiras de orçamento de erro.

Plano de observabilidade (observability plane) — métricas normais + correlação de ID de rastreamento para distinguir falhas induzidas pelo caos das falhas naturais.

Ciclo de feedback — as descobertas alimentam ajustes de SLO, atualizações de runbooks e correções de código.

Proteções são obrigatórias

• Alerta de taxa de queima (burn-rate): pausa o experimento se a queima diária do orçamento de erro exceder duas vezes o esperado.
• Janelas de supressão: silencia alertas que não sejam do experimento dentro do raio de explosão durante a execução.
• Correlação de ID de rastreamento (trace-ID correlation): todos os erros induzidos por experimentos carregam uma tag para que o plantonista possa desduplicá-los.

Cinco experimentos específicos de LLM

1. Sobrecarga de memória — força uma tempestade de preempção de KV cache enviando requisições de contexto longo com alta concorrência. Observe: o serviço descarta carga graciosamente ou trava?
2. Falha de rede — corta a conectividade entre o gateway de inferência e o provedor. Observe: o fallback entra em ação dentro do SLA? (Phase 17 · 19)
3. Simulação de indisponibilidade do provedor — 100% de 429 da OpenAI. Observe: o roteamento faz o failover para a Anthropic? (Phase 17 · 16, 19)
4. Prompt malformado — injeta carga útil que paralisa o tokenizador (por exemplo, unicode profundamente aninhado, ponto de código UTF-8 gigante). Observe: uma única requisição bloqueia um worker?
5. Tempestade de despejo no KV cache — força o despejo saturando o orçamento de blocos do vLLM. Observe: o LMCache se recupera ou o serviço degrada?

Cadência

• Semanal — pequenos experimentos canário no ambiente de staging, talvez 5% em produção.
• Mensal — game day agendado para um cenário específico; presença de várias equipes; pós-morte (postmortem).
• Trimestral — auditoria de resiliência entre equipes; atualização do mapa de dependências.

Ferramentas

• Harness Chaos Engineering — comercial; recomendações de experimentos derivadas de IA; redução do raio de explosão; integração com ferramentas MCP.
• LitmusChaos — graduado da CNCF; baseado em fluxos de trabalho do Kubernetes.
• Chaos Mesh — sandbox da CNCF; estilo CRD nativo de Kubernetes.
• Gremlin — comercial; amplo suporte.
• AWS FIS / Azure Chaos Studio — ofertas em nuvem gerenciada.

Começando pequeno

Primeiro experimento: derrube (pod-kill) uma réplica de decodificação sob tráfego estável. Observe o roteamento e a recuperação. Se isso funcionar e parecer seguro, passe para o caos de rede.

Primeiro experimento específico de LLM: injete erro 429 de um provedor por 5 minutos. Observe o fallback. A maioria das equipes descobre que seu fallback não foi totalmente testado.

Números que você deve lembrar

• Quatro planos: controle, alvo, segurança, observabilidade.
• Pausa por taxa de queima: 2x a queima diária esperada do orçamento.
• Cadência: canário semanal, game day mensal, auditoria trimestral.
• Cinco experimentos de LLM: memória, rede, provedor, prompt malformado, tempestade de KV cache.

Use

code/main.py simula três experimentos de caos com barreiras no plano de segurança. Relata quais experimentos acionariam o aborto por taxa de queima.

Entregue

Esta lição produz outputs/skill-chaos-plan.md. Dados a pilha e a maturidade, escolhe os três primeiros experimentos e as ferramentas.

Exercícios

1. Execute code/main.py. Qual experimento aciona a barreira da taxa de queima e por quê?
2. Projete os primeiros cinco experimentos de caos para um serviço de RAG baseado em vLLM. Inclua os critérios de sucesso.
3. Seu alerta de taxa de queima pausou um experimento. Como você determina a causa raiz — caos ou natural?
4. Argumente se o caos deve ser executado em produção ou apenas em staging. Quando produção é a resposta correta?
5. Nomeie três modos de falha específicos de LLM que o caos de rede genérico não consegue reproduzir.

Termos-Chave

Leituras Adicionais

• DevSecOps School — Chaos Engineering 2026 Guide
• Ankush Sharma — Observability for LLMs (book)
• LitmusChaos (CNCF)
• Chaos Mesh (CNCF)
• Harness Chaos Engineering
• AWS FIS