Operar e recuperar: DR, retries, ensaio de falha, runbook e postmortem

Esta aula assume que o servidor já está conectado ao seu agente (Módulo 1) e que você sabe ler um resultado: o campo kind diz o que a ferramenta devolveu, limitation diz o que ela não garante e nextTools sugere o passo seguinte. Nada disso muda aqui. O que muda é o momento: as ferramentas anteriores serviam para decidir antes de construir; estas servem para o dia em que o pager toca.

São cinco ferramentas do grupo "Reliability, operations and FinOps" e duas do grupo "Architecture and decisions", todas funções puras: entram números e fatos, saem cálculos, tabelas e documentos. Nenhuma delas toca na sua conta, replica dado, injeta falha ou abre incidente. dr_strategy compara tiers de recuperação com o seu RTO e RPO. retry_policy calcula a agenda de backoff e o pior caso de espera. failure_rehearsal desenha um ensaio de falha e nunca o executa. runbook e postmortem montam o documento e apontam o que ficou faltando. implementation_plan e migration_plan colocam portões de evidência entre a decisão e a produção.

Dois prompts organizam a sequência: dr_planning e incident_recovery. O modelo do seu cliente conduz a conversa, pergunta o que falta e chama as ferramentas na ordem; o servidor só calcula. Quem já atendeu um alerta às 3 da manhã sabe por que isso importa: naquele momento você não quer criatividade, quer um número que já estava calculado e um passo que já estava escrito.

A plataforma de pedidos aceita ficar fora por até 60 minutos (RTO) e perder no máximo 5 minutos de dados (RPO). Tem 120 GB de estado, 200 Mbps de banda para replicação, residência no Brasil e três componentes com estado: o banco de pedidos em PostgreSQL, a fila de eventos de pedido e o armazenamento de objetos das notas fiscais. É isso que entra em dr_strategy.

A ferramenta carrega os quatro tiers do whitepaper de DR da AWS com suas faixas típicas e aplica uma regra simples: um tier é viável quando o seu RTO é maior ou igual ao mínimo típico do tier, e o mesmo para o RPO. Com RTO de 1 hora e RPO de 0,083 hora, o resultado é:

• backup-and-restore: RTO típico de 4 a 72 horas. Falha nos dois objetivos, feasible: false.
• pilot-light: RTO típico de 0,5 a 4 horas, passa. RPO típico começa em 0,1 hora, ou seja, 6 minutos. Seu RPO é 5. meetsRto: true, meetsRpo: false, feasible: false.
• warm-standby: RTO de 0,1 a 0,5 hora e RPO de 0,01 a 0,1 hora. Viável, custo relativo medium.
• multi-site-active-active: viável, custo relativo highest.

recommendedStartingPoint é literalmente "warm-standby: the lowest-cost tier whose typical range covers the objectives; confirm with a timed rehearsal". initialFullCopyHours: 1.37 vem de 120 GB × 8 × 1024 / 200 Mbps / 3600: a cópia inicial, não o atraso de replicação em regime.

Repare em um detalhe que vale uma reunião: se o negócio aceitar RPO de 6 minutos em vez de 5, pilot-light entra na tabela como viável e o custo relativo cai de medium para low. Com equipe de 4 e orçamento de US$ 1.500 por mês, essa é a conversa a ter com quem definiu o RPO, antes de assinar um warm-standby. Os checks lembram o resto: ensaiar o failover de ponta a ponta e medir o RTO real, porque faixa típica não é evidência; o RPO é limitado pelo atraso de replicação, não pela agenda de backup; cada componente com estado precisa do próprio plano de replicação e consistência; a região de recuperação precisa atender à residência no Brasil; e identidade, DNS, segredos e CI/CD também precisam existir lá.

Toda chamada que a plataforma faz para fora, pagamento, antifraude, nota fiscal, vai falhar em algum momento. A pergunta não é se repete, é quantas vezes, com que espera e dentro de qual prazo. retry_policy responde com aritmética.

O exemplo do repositório usa baseDelayMs: 200, factor: 2, capMs: 5000, maxAttempts: 5, jitter: "full", deadlineMs: 15000 e operationIdempotent: true. O resultado lista as 4 retentativas depois da primeira tentativa (por isso 5 tentativas geram 4 linhas): 200, 400, 800 e 1600 ms. Com jitter completo, cada espera cai entre 0 e esse valor, o que espalha os clientes em vez de sincronizá-los. worstCaseWaitMs: 3000 é a soma; attemptsThatFitDeadline: 5 diz que as cinco cabem nos 15 segundos. O teto de 5000 ms nem chegou a ser usado: a próxima espera seria 3200.

A parte que mais importa está em guidance, e ela muda com um único campo. Com operationIdempotent: true, a linha é "Idempotent operation: retries are safe when the server deduplicates by key". Com false, vira "NOT idempotent: do not retry blindly; verify the outcome at the target or use an idempotency key before retrying". Capturar um pagamento é o caso clássico de false: repetir sem verificar é cobrar duas vezes.

As outras linhas são as que eu repito em toda revisão: só repita em erro transitório (timeout, 429, 5xx), nunca em erro de validação ou autorização; abra o circuit breaker depois de 5 falhas consecutivas ou mais de 50% de erro na janela, com sondas half-open a cada intervalo do teto; e propague o prazo restante para baixo, porque com 3 saltos de 3 segundos de pior caso cada um, a 300 pedidos por minuto, a retentativa aninhada multiplica a espera e transforma um soluço em fila.

O cenário: o pedido já foi gravado, o serviço chama o provedor de pagamento para capturar o valor, o provedor captura, e o processo morre antes de registrar o recibo. Do lado da orquestração o estado é "desconhecido". Do lado do provedor o dinheiro já saiu. Uma retentativa cega cobra o cliente duas vezes; não fazer nada deixa um pedido pago sem confirmação. Esse é o after-write-crash, e é a falha que eu mais quero ver ensaiada antes de ir para produção.

failure_rehearsal recebe operation: "Capture payment after order persisted", target: "payment provider" e failure: "after-write-crash" (os outros valores aceitos são timeout, duplicate, drift, revocation e dependency-outage). Ela devolve um desenho de ensaio, nunca o executa: kind é heuristic-design-aid e validated é false.

As precondições vêm antes de qualquer injeção: ambiente descartável ou alvo sintético; operador autorizado, limite de custo, condição de parada e dono da recuperação definidos; digest da entrada, versão do alvo e ID de execução capturados. Os passos são cinco: registrar o estado esperado e a evidência independente de sucesso; injetar o after-write-crash numa fronteira documentada; observar o estado do alvo independentemente do estado da orquestração; reconciliar antes de qualquer retentativa e bloquear resultados desconhecidos; registrar o resultado e restaurar o ambiente. A aceitação tem quatro linhas: nenhuma mudança não autorizada, nenhum efeito colateral duplicado, resultados incertos visíveis e bloqueando replay cego, evidência que identifica a versão testada e as limitações.

O terceiro passo é o coração da aula: o estado que vale é o do alvo, lido por um canal independente (a consulta de transação do provedor, não o seu log). É por isso que dr_planning diz que um tier só é aceito depois de um ensaio cronometrado, e por isso dr_strategy lista failure_rehearsal em nextTools.

runbook recebe fatos do serviço e devolve o documento em Markdown. No exemplo, o serviço é Orders API, dono orders-team, dois alertas (HighErrorRate, 5xx acima de 2% por 5 minutos; QueueBacklog, mensagem mais antiga da fila OrderPlaced acima de 600 segundos), três diagnósticos (último deploy versus início do erro, pool de conexões do banco, página de status do provedor de pagamento), três remediações (voltar a imagem anterior se o erro começou no deploy, escalar consumidores se o backlog cresce com erros saudáveis, ligar a flag de modo degradado do pagamento), rollback em dois passos, escalonamento em 15 e 30 minutos e um dashboard.

A saída tem uma seção First 10 minutes fixa (reconhecer o alerta e abrir o canal, checar dashboards, confirmar escopo de clientes, regiões e operações), uma Verification fixa (erro e latência na linha de base por 15 minutos, sem backlog crescendo, confirmação do lado do cliente) e um After the incident que aponta para postmortem. O campo missing saiu vazio porque o exemplo preencheu tudo; omita rollback e ele devolve ["rollback procedure"] e grava um TODO na seção. O documento não finge que a informação existe.

postmortem é mais rígido. Exige quatro timestamps ordenados, startedAt <= detectedAt <= mitigatedAt <= resolvedAt, e lança erro se a ordem quebrar. Cada item de ação precisa de owner, due e kind (prevent, detect, mitigate ou process), senão o esquema rejeita. No exemplo "Checkout failures after dependency upgrade", sev2, as métricas saem calculadas: 32 minutos para detectar (de 13:10 a 13:42), 23 para mitigar, 140 para resolver. coverage conta 2 itens de prevenção, 1 de detecção, 0 de mitigação e 0 de processo. E warnings traz "Detection took more than 30 minutes; prioritize a detect action item": o suporte percebeu antes do alerta, e a ferramenta não deixa isso passar sem um item de detecção.

implementation_plan fecha o ciclo. Entra uma decisão (no exemplo, "Adopt SQS FIFO per tenant for order events with idempotent consumers") e a lista de entregáveis; sai uma sequência de cinco portões, cada um com a evidência que libera o próximo: design (ADR, modelo de ameaças, cenário de custo datado), build (IaC versionada, políticas de privilégio mínimo, testes unitários e de contrato), verify (testes de integração, ensaio de falha, checagens operacionais), release (change set revisado, procedimento de rollback, monitoramento e limites de custo) e operate (dono do SLO, runbook de incidente, data de revisão e critério de aposentadoria). Repare que failure_rehearsal e runbook aparecem como evidência de portão: as ferramentas desta aula são o que prova que a decisão da aula anterior pode ir para produção.

migration_plan faz o mesmo para mudar de lugar: fases discover, pilot, migrate, cutover e optimize, cada uma com critério de saída. A que eu sublinho é migrate: "a reconciliação prova completude dos dados; a janela de rollback continua aberta". Mesmo princípio, outro contexto.

Os dois prompts organizam o uso. dr_planning instrui o modelo a perguntar RTO, RPO, componentes com estado, volume de dados e residência, chamar dr_strategy, depois failure_rehearsal para o ensaio de failover e cost_model para o tier escolhido, e aceitar o tier só depois de um ensaio cronometrado. incident_recovery começa por impacto, escopo e linha do tempo, preserva evidência e limites de autorização, usa failure_rehearsal e agent_tool_contract para planejar a verificação independente de estado antes de repetir, e escreve o postmortem com postmortem. No seu cliente, prompts MCP aparecem na lista de prompts do servidor moretes-architect; selecione um e o modelo assume a sequência.