Game day: resposta coordenada e ações de postmortem verificáveis

Em vez de repetir o conceito de postmortem, vamos ensaiar o ciclo completo. Um game day é uma simulação planejada para testar pessoas, processos e ferramentas. Use o CloudShop de laboratório; defina previamente cenário, duração, responsáveis e condição de parada em docs/game-day.md.

Comece estabelecendo limites de segurança: ambiente isolado, dados sintéticos, autorização e um observador com poder de abortar. Uma simulação que toca produção por engano já é um incidente real. Confirme o contexto com kubectl config current-context antes de qualquer operação.

Ao detectar a degradação, nomeie um coordenador do incidente. Ele mantém prioridades e evita intervenções conflitantes; outra pessoa investiga e outra comunica. Em uma equipe pequena, uma pessoa pode acumular papéis, mas precisa anunciar essa limitação e registrar decisões no canal inc-cloudshop.

Escreva a primeira atualização com impacto, horário e próximo retorno, mesmo sem causa conhecida. Diga o que foi observado e o que ainda é hipótese: “checkout apresenta erros desde 14:02 UTC; próxima atualização às 14:12”. Não prometa uma restauração em 5m sem evidência.

A mitigação vem antes da explicação definitiva. Se o início coincide com um deploy, compare a revisão atual e a anterior e avalie rollback; uma migração incompatível pode impedir essa opção. Registre alternativa, risco, autorização e sinal que comprovará melhora antes de executar a mudança.

O exemplo usa uma revisão explícita para reduzir ambiguidades, mas só deve ser executado após a avaliação de compatibilidade. rollout status informa progresso do Deployment, não a recuperação da experiência. Confira também a jornada sintética de compra, a taxa de erros e o tempo de resposta.

Após estabilizar, preserve a linha do tempo factual: detecção, decisões, mudanças e recuperação, com horários em UTC. No postmortem, diferencie gatilho de condições contribuintes. “Deploy iniciou a falha” não explica por que testes, revisão e mecanismos de recuperação não a impediram.

Termine com ações verificáveis, não promessas vagas. Troque “melhorar testes” por “adicionar teste de exaustão do pool que falha na versão defeituosa”, com responsável, prazo e evidência. Agende novo exercício para comprovar a mudança e só encerre o item quando o critério de aceite estiver cumprido.