Game Days & Resilience Drills

Em 2004, a Autoridade de Aviação Civil do Reino Unido publicou um relatório sobre acidentes aéreos e treinamento de pilotos que capturou um padrão recorrente: em situações de emergência, pilotos executavam procedimentos memorizados incorretamente sob stress — mesmo quando os mesmos procedimentos eram executados corretamente em condições normais. A conclusão era que treinamento em condições normais não transferia para desempenho sob stress. A solução era simuladores de voo com falhas injetadas — forçando pilotos a tomar decisões sob pressão, repetidamente, até que a resposta correta fosse automática.

Game days de software aplicam o mesmo raciocínio. Um time de engenharia que nunca praticou resposta a incidentes em condições controladas vai, em um incidente real às 3h da manhã, cometer erros que treinamento teria evitado: demorar para escalar, comunicar de forma confusa, aplicar a ação errada por pressa. Um game day bem conduzido é a diferença entre um time que improvisa e um time que executa.

O game day difere do chaos experiment isolado em escopo: um chaos experiment testa se o sistema sobrevive a uma falha específica. Um game day testa se o time completo — sistema, runbooks, comunicação, escalação — funciona sob condições adversas. É um exercício organizacional, não apenas técnico.

Estrutura de um game day

Um game day bem estruturado tem três fases claramente separadas, cada uma com papéis definidos:

Fase 1 — Prepare (preparação)

A preparação acontece sem o conhecimento do time de on-call. O time facilitador define:

• O cenário: qual falha será injetada, em qual componente, com qual magnitude. Exemplos: "serviço de banco de dados primário cai", "network partition entre regiões", "deploy ruim com memory leak crescente".
• O steady state: como verificar que o sistema está funcionando antes e depois.
• As métricas de sucesso do game day: não do sistema, mas do time. Tempo para detectar, tempo para escalar, qualidade da comunicação, ação correta aplicada.
• Os limites de segurança: abort conditions para o game day em si — se algo sair muito do controle, o facilitador aborta e revela o cenário imediatamente.

Importante: o time de on-call sabe que haverá um game day (para garantir disponibilidade), mas não sabe o cenário específico. Isso simula a surpresa real de um incidente sem a desorientação total.

Fase 2 — Execute (execução)

O facilitador injeta a falha no tempo definido e o time de on-call responde como faria em um incidente real. O facilitador observa (sem intervir, exceto por razões de segurança) e registra:

• Tempo até o primeiro alerta disparar
• Tempo até o primeiro engenheiro reconhecer o alerta
• Tempo até a hipótese de diagnóstico correta ser formulada
• Tempo até a ação mitigadora ser aplicada
• Qualidade da comunicação em cada etapa
• Uso (ou não) de runbooks e documentação

O time de on-call não recebe dicas. Se demorarem 20 minutos para detectar que o banco de dados caiu quando um dashboard simples mostraria isso em 30 segundos — esse é o dado mais valioso do exercício. O game day revelou que o dashboard não está na rotina de monitoramento do time.

Fase 3 — Debrief (retrospectiva)

O debrief acontece imediatamente após a resolução, enquanto o contexto está fresco. O facilitador revela o cenário completo (se ainda não estava óbvio) e conduz uma retrospectiva estruturada em quatro perguntas:

1. O que funcionou bem?
2. O que poderia ter funcionado melhor?
3. O que foi surpreendente (o sistema se comportou diferente do esperado)?
4. Quais são os action items — com owner e data de entrega?

O debrief deve ser completamente blameless. "O banco caiu e ninguém estava olhando para o dashboard correto" é um problema de processo e instrumentação — não de negligência individual.

Tabletop exercises — simulação sem injeção real

Para times que ainda não têm maturidade para game days com injeção real, ou para cenários onde injeção real seria excessivamente arriscada (falha de datacenter inteiro, por exemplo), o tabletop exercise é uma alternativa valiosa. Não há injeção de falha — apenas simulação verbal.

O facilitador descreve o cenário em tempo real: "São 14h30 de uma sexta. Você recebe um alerta: taxa de erro no checkout chegou a 15%. O que você faz?" O time responde verbalmente: "Vou ao dashboard de erros para ver onde está concentrado." O facilitador descreve o que eles veriam: "O dashboard mostra que os erros estão todos em chamadas ao serviço de pagamento, que está retornando 500." O time responde à nova informação.

Tabletop exercises são ótimos para:

• Identificar gaps em runbooks antes de testá-los em produção
• Treinar novos membros do time em procedimentos de resposta a incidentes
• Simular cenários de alto impacto que seriam perigosos injetar em produção
• Avaliar o processo de escalação e comunicação sem risco técnico

DiRT — Disaster Recovery Testing no Google

O Google usa DiRT (Disaster Recovery Testing) desde 2006 — simulações anuais de falhas catastróficas em escala de datacenter. A motivação, descrita por Kripa Krishnan em "Weathering the Unexpected" (ACM Queue, 2012), é que planos de recuperação a desastres que não são testados regularmente frequentemente falham quando são necessários — por obsolescência, por suposições incorretas, ou por dependências que mudaram sem que o plano fosse atualizado.

O DiRT incluiu ao longo dos anos simulações de perda de acesso a um data center inteiro por dias, desconexão de redes entre regiões, e falha de serviços de comunicação interna. O que o DiRT revelou consistentemente é que os maiores problemas não eram técnicos — eram humanos: procedimentos que dependiam de ferramentas que ficaram indisponíveis na falha, escalações que não funcionavam porque contatos estavam desatualizados, runbooks escritos assumindo que certos serviços estariam disponíveis quando não estavam.

Frequência e cadência de game days

Não há uma frequência universal correta para game days, mas algumas referências da indústria:

Netflix: experimentos de chaos contínuos (automatizados), game days com injeção manual trimestralmente, simulações de incidente para novos membros do time como parte do onboarding.

Google: DiRT anual para cenários catastróficos; game days trimestrais por equipe para cenários de rotina; tabletop exercises mensais para novos engenheiros de on-call.

Time médio: um game day por trimestre, com tabletop exercise mensal, é razoável. Menos que isso, e o time não desenvolve memória muscular. Mais que isso sem infraestrutura adequada, e o overhead supera o aprendizado.

Documentando o game day

Um game day deve produzir um documento de resultado que pode ser consultado futuramente. A estrutura mínima:

GAME DAY — Checkout API
Data: 2026-04-15 | Facilitador: Ana Silva
Cenário: Falha do banco de dados primário

STEADY STATE PRÉ-EXPERIMENTO:
  - taxa_erro: 0.08%
  - p99_latência: 280ms
  - throughput: 450 req/s

INJEÇÃO: 14:02 — failover do banco primário
  para réplica simulado via DNS update

LINHA DO TEMPO:
  14:02 — Injeção realizada (oculta ao time)
  14:04 — Alerta de taxa de erro > 1% disparado
  14:05 — On-call reconhece alerta
  14:09 — Hipótese: problema no banco
  14:12 — Confirmado via logs: conexões recusadas
  14:15 — Ação: forçar reconexão via health check
  14:17 — Sistema recuperado

MÉTRICAS DE RESPOSTA:
  Detecção: 2 minutos
  Diagnóstico: 7 minutos
  Mitigação: 5 minutos
  Total: 15 minutos vs SLO de 20 minutos ✓

SURPRESAS:
  - Dashboard de banco não estava no runbook de on-call
  - A ação de reconexão não estava documentada

ACTION ITEMS:
  - Adicionar link para dashboard de banco no runbook (owner: Carlos, due: 2026-04-22)
  - Documentar procedimento de forçar reconexão (owner: Ana, due: 2026-04-22)
  - Calibrar alerta de taxa de erro para disparar em 30s não 120s (owner: DevOps, due: 2026-04-29)

Como praticar

1. Conduzir um tabletop exercise. Reúna o time por 60 minutos. Escolha um cenário recente de incidente real (ou inventado com base nos riscos mais prováveis do serviço). Conduza como roleplay verbal: facilitador descreve o estado do sistema, time responde com ações, facilitador descreve as consequências das ações. Identifique os gaps em runbooks e escalação. Documente action items antes de encerrar.
2. Planejar o primeiro game day com injeção real. Defina: o cenário (escolha o mais simples possível para o primeiro), o steady state, as métricas de sucesso do time, e as abort conditions. Agende com pelo menos 2 semanas de antecedência para preparar o ambiente e garantir disponibilidade. Execute apenas em staging ou em horário de baixo tráfego se for em produção.
3. Revisar runbooks após o game day. Use os gaps identificados no game day para atualizar runbooks. Um bom critério de completude: o runbook deve permitir que um engenheiro sem contexto histórico execute o procedimento de recuperação correto em menos de 10 minutos. Se não consegue, o runbook está incompleto.