APRENDER. PRATICAR. EVOLUIR.Retries multiplicam trabalho
Um retry consome capacidade quando o serviço já pode estar degradado. Num exemplo com três camadas e três tentativas totais por chamada em cada camada, incluindo a inicial, uma operação pode gerar até 27 chamadas à dependência mais profunda. O limite é um cenário de falha persistente, não uma previsão para todos os pedidos. Define onde a repetição deve ocorrer, quais erros são recuperáveis e um orçamento total de tempo e tentativas. Backoff espaça chamadas; jitter dispersa clientes que, de outro modo, acordariam juntos. Regista a configuração efetiva da biblioteca, não apenas a intenção do runbook.
Timeout e resultado desconhecido
Um timeout pode ocorrer depois de o servidor ter aceite uma operação e antes de a resposta chegar. Para uma ordem fictícia, consulta o estado por identidade estável e aplica o contrato de idempotência. Repetir a mesma intenção com uma chave nova pode criar um segundo efeito. Reutilizar a chave com dados diferentes também pode violar o contrato. Confirma âmbito, prazo de retenção da chave e comportamento perante pedidos tardios. Não prometas exactly once apenas porque existe um campo de identificação. A recuperação deve distinguir resultado confirmado, rejeição confirmada e estado ainda por reconciliar.
Capacidade útil e dependências
Aumentar workers só ajuda se a dependência conseguir executar mais trabalho útil. Num incidente fictício, os consumidores sobem de 20 para 60, mas os commits por minuto caem e a espera JDBC aumenta. A alteração é evidência contra a hipótese de falta de consumidores, embora ainda seja necessário investigar a causa da espera. Interrompe a expansão segundo o plano e envolve o owner da dependência. Considera limitar admissão ou concorrência com impacto conhecido, protegendo trabalho crítico e mantendo backlog visível. Compara conclusões válidas por minuto, não apenas o número de processos ativos.
Estado de rollout não é rollback
Num Deployment Kubernetes, Available=True pode coexistir com Progressing=False e ProgressDeadlineExceeded. A primeira condição indica disponibilidade mínima segundo a estratégia; a segunda informa que o rollout não progrediu no prazo. O controlador não executa automaticamente rollback por essa condição. Um orchestrator superior pode fazê-lo se estiver configurado, o que exige evidência própria. Confirma cluster, namespace, revisão e eventos antes de preparar uma ação. Num exercício, quotas impedem novos Pods enquanto a versão anterior continua a servir. Corrigir a capacidade ou reverter são decisões diferentes; nenhuma se demonstra apenas pelo aviso.
Comparar canary e versão de referência
Um agregado pode esconder uma versão com falhas quando recebe uma pequena parte do tráfego. Define métricas, populações comparáveis e critérios antes de promover um canary. Num exemplo fictício, compara erros por operação, latência e validação funcional para a versão nova e a referência no mesmo intervalo. Verifica também se a amostra incluiu o fluxo crítico de fundos; poucos pedidos de health check não representam esse fluxo. Se o gate falhar, interrompe promoção e executa o plano autorizado, avaliando compatibilidade de dados e configuração. Um deploy tecnicamente concluído não substitui a aceitação do serviço.
Fechar com reconciliação e passagem para RUN
Aceitação operacional combina serviço, dados e capacidade de suporte. Num exercício de recuperação, a aplicação volta a responder, mas o ficheiro de valorização tem diferenças ainda sem explicação. Mantém a reconciliação aberta, identifica o universo esperado e regista exceções aprovadas. Entrega ao turno seguinte a revisão ativa, alterações temporárias, pedidos de repetição pendentes e critérios de fecho. O responsável de negócio deve conhecer o efeito no cutoff, sem receber uma garantia baseada apenas em métricas técnicas. Marca recuperação, reconciliação e prevenção como estados distintos para que o RUN saiba exatamente o que falta.
Num cenário fictício, a versão canary tem 12% de falhas e a anterior 0,2%. A média global continua baixa porque só 5% do tráfego usa a versão nova. Analisa as duas populações antes de promover.
Armadilhas comuns
Retry como operação gratuita; timeout como prova de não execução; Available como rollout completo; dashboard global como aceitação funcional.
Tópicos relacionados: Validar transferências e reconciliação · Medir impacto e confirmar recuperação · Transformar o incidente em melhoria verificável
Recupera capacidade e resultados, preservando identidade das operações e critérios de aceitação.
Referência: Timeouts, retries, backoff and jitter · DR Production Support L3 2026.4; Linux, JDK 25 HotSpot, OpenSSL 3.5 and Kubernetes examples require installed-version checks