Skip to content
Da Vibe Coding à Engenharia Agêntica

Capítulo 18 — Falha, rollback e recuperação

O objetivo não é eliminar toda falha

Section titled “O objetivo não é eliminar toda falha”

Em sistemas complexos, falha precisa ser tratada como parte do desenho operacional.

A pergunta deste capítulo é:

como dar autonomia sem transformar cada erro em uma mudança irreversível?

O princípio central é:

quanto maior o blast radius e menor a reversibilidade, mais estreito deve ser o envelope de autonomia.

Hassan liga explicitamente reversibilidade à calibração de autonomia: ações com recovery path claro suportam delegação mais ampla do que migrations, deleções ou ações externas difíceis de desfazer. 1

Reversible world

Section titled “Reversible world”

Software oferece vários mecanismos de reversibilidade:

  • Git history;
  • immutable artifacts;
  • containers rebuildable;
  • infrastructure as code;
  • feature flags;
  • backups;
  • snapshots;
  • compensating actions.

Mas reversibilidade não é binária.

Podemos classificar ações como:

  • fully reversible;
  • reversible with cost;
  • partially reversible;
  • operationally irreversible.

Isso é método deste livro.

Blast radius

Section titled “Blast radius”

Blast radius responde:

quanto do sistema, dos dados ou dos usuários pode ser afetado por uma falha?

Pode ser limitado por:

  • canary;
  • tenant isolation;
  • rate limit;
  • feature flag;
  • scoped credentials;
  • circuit breaker;
  • queue partition;
  • approval boundary.

Detect → contain → recover → verify

Section titled “Detect → contain → recover → verify”

O ciclo operacional deste capítulo é:

Detect
  ↓
Contain
  ↓
Recover
  ↓
Verify
  ↓
Learn

O erro mais comum é parar em Recover.

Hassan ressalta que executar um rollback não basta: é preciso verificar que o sistema voltou ao estado esperado. 2

Detect

Section titled “Detect”

Detecção pode vir de:

  • alert;
  • health check;
  • SLO breach;
  • anomaly;
  • user report;
  • synthetic check;
  • business metric;
  • security signal.

A detecção precisa identificar:

  • quando começou;
  • qual release;
  • qual scope;
  • qual severidade.

Contain

Section titled “Contain”

Containment busca impedir propagação.

Mecanismos:

  • disable feature flag;
  • stop rollout;
  • isolate tenant;
  • revoke credential;
  • disable integration;
  • circuit breaker;
  • rate limit;
  • pause queue consumer;
  • narrow autonomy.

Recovery

Section titled “Recovery”

Recovery restaura capacidade aceitável de operação.

Pode significar:

  • rollback;
  • restore;
  • failover;
  • forward fix;
  • compensating transaction;
  • degraded mode.

Recovery não precisa necessariamente restaurar o estado ideal imediatamente.

Primeiro objetivo pode ser voltar a um estado seguro.

Rollback

Section titled “Rollback”

Adkins et al. tratam rollback para um estado conhecido como bom como mecanismo central de mitigação de incidentes, ao mesmo tempo em que destacam o risco de reintroduzir vulnerabilidades antigas. 3

Portanto:

rollback também tem policy.

Não é simplesmente “voltar qualquer versão”.

Last known good

Section titled “Last known good”

Um rollback útil precisa saber:

  • qual versão era estável;
  • qual artifact;
  • qual schema;
  • qual configuration;
  • quais dependencies.

“Versão anterior” e “last known good” não são necessariamente a mesma coisa.

Rollback de código

Section titled “Rollback de código”

Pode envolver:

  • revert commit;
  • previous container image;
  • traffic swap;
  • feature flag off.

É frequentemente a camada mais simples.

Rollback de dados

Section titled “Rollback de dados”

Mais difícil.

Migration pode:

  • apagar coluna;
  • transformar valores;
  • mudar semântica;
  • gerar side effects externos.

Estratégias:

  • backward-compatible migrations;
  • snapshots;
  • backup/restore;
  • dual write temporário;
  • compensating transformation;
  • forward fix.

Compensating action

Section titled “Compensating action”

Nem todo efeito pode ser “desfeito”.

Exemplo:

  • email enviado;
  • pagamento capturado;
  • mensagem publicada;
  • webhook externo.

Nesse caso, recovery pode exigir ação compensatória.

Degraded mode

Section titled “Degraded mode”

Quando full recovery não é imediata, o sistema pode operar em modo degradado.

Exemplos:

  • read-only;
  • fila em vez de processamento síncrono;
  • fallback provider;
  • desabilitar feature secundária;
  • limitar carga.

O objetivo é preservar função crítica enquanto reduz risco.

Safe failure

Section titled “Safe failure”

método deste livro:

Quando possível, desenhe falhas para terminar em estado previsível.

Exemplos:

  • timeout explícito em vez de hang;
  • transaction rollback em vez de state parcial;
  • idempotency em retries;
  • deny-by-default em auth;
  • queue dead-letter em vez de perda silenciosa.

Incident severity

Section titled “Incident severity”

Nem toda anomalia exige o mesmo ritual.

Podemos classificar por:

  • user impact;
  • data impact;
  • security impact;
  • duration;
  • blast radius;
  • reversibility.

Severity orienta:

  • escalonamento;
  • comunicação;
  • autorização;
  • postmortem.

INCIDENT.md

Section titled “INCIDENT.md”

Artefato operacional deste capítulo.

# Incident


## Summary
## Detection
## Impact
## Timeline
## Suspected Change
## Containment
## Recovery
## Verification
## Open Risks
## Evidence
## Follow-up

Timeline

Section titled “Timeline”

Timeline deve ser factual.

Exemplo:

14:03 deploy completed
14:07 error_rate crossed threshold
14:09 rollout paused
14:12 previous artifact restored
14:16 smoke PASS
14:20 error rate returned to baseline

Recovery verification

Section titled “Recovery verification”

Após rollback/restore, verificar:

  • version correta;
  • health;
  • critical flows;
  • data integrity;
  • error rate;
  • latency;
  • business signal.

Isso implementa o princípio de que rollback executado não equivale a recovery comprovada. 2

Evidência de recuperação

Section titled “Evidência de recuperação”

Pode incluir:

  • rollback command/output;
  • artifact digest;
  • restore log;
  • health checks;
  • runtime metrics;
  • smoke test;
  • screenshots quando relevantes;
  • operator/agent decision record.

Rollback drill

Section titled “Rollback drill”

Se recovery é importante, deve ser exercitável.

Um drill pode validar:

  • permissões;
  • comando;
  • artifact availability;
  • restore time;
  • runbook accuracy;
  • dependencies.

RTO e RPO

Section titled “RTO e RPO”

Quando aplicável:

RTO

Section titled “RTO”

Quanto tempo podemos levar para restaurar serviço aceitável?

RPO

Section titled “RPO”

Quanto estado/dado podemos perder?

Neste livro, usamos os conceitos como parâmetros operacionais de recovery, sem exigir framework formal em todo projeto.

Recovery readiness

Section titled “Recovery readiness”

método deste livro:

Uma mudança de alto risco deveria responder antes do deploy:

  • como detectar falha?
  • como conter?
  • como voltar?
  • quanto demora?
  • quem autoriza?
  • como confirmar recuperação?

Autonomia baseada em recovery

Section titled “Autonomia baseada em recovery”

A capacidade de desfazer muda o cálculo de delegação. 1

Exemplo:

Baixo risco

Section titled “Baixo risco”

Editar documentação em Git.

Médio

Section titled “Médio”

Deploy com feature flag e previous artifact disponível.

Alto

Section titled “Alto”

Migration destrutiva sem restore testado.

O mesmo agente pode receber autonomia diferente em cada cenário.

Narrow after incident

Section titled “Narrow after incident”

Após incidente, autonomia pode ser temporariamente reduzida.

Exemplo:

  • agent pode continuar diagnosticar;
  • não pode promover produção;
  • precisa de approval para mutações;
  • pode recuperar evidência read-only.

A expansão volta quando critérios explícitos forem satisfeitos.

Circuit breaker

Section titled “Circuit breaker”

Circuit breaker limita propagação de falhas em dependências.

Pode abrir quando:

  • timeout cresce;
  • failure rate passa threshold;
  • dependency fica indisponível.

O objetivo é falhar de forma controlada em vez de amplificar o incidente.

Kill switch

Section titled “Kill switch”

Uma feature ou integração crítica pode ter kill switch.

Ele precisa ser:

  • conhecido;
  • autorizado;
  • testado;
  • rápido;
  • auditável.

Case evidência: PCC

Section titled “Case evidência: PCC”

No estudo longitudinal deste livro, um gate pré-produção detectou uma dependência ausente na imagem do Project Command Center, bloqueou a promoção, levou a hotfix e apenas a revisão corrigida foi promovida com health check e rollback disponíveis. 4

O ponto importante não é o bug específico.

É o comportamento do sistema de engenharia:

failure detected before promotion
  ↓
promotion blocked
  ↓
fix produced
  ↓
evidência regenerated
  ↓
corrected revision promoted

Prevention é mais barata que recovery

Section titled “Prevention é mais barata que recovery”

Recovery é necessária, mas não deve ser usada para justificar descuido.

A cadeia ideal tem camadas:

  • prevent;
  • detect;
  • contain;
  • recover;
  • verify.

Anti-pattern: rollback sem artifact

Section titled “Anti-pattern: rollback sem artifact”

Runbook diz “voltar versão anterior”, mas imagem anterior não existe mais.

Isso é recovery fictícia.

Anti-pattern: backup nunca restaurado

Section titled “Anti-pattern: backup nunca restaurado”

Backup sem restore test é hipótese.

Evidência de recuperação exige, quando o risco justificar, demonstração de restauração.

Anti-pattern: rollback global para incidente local

Section titled “Anti-pattern: rollback global para incidente local”

Containment deve tentar reduzir blast radius.

Se um tenant está afetado, talvez não seja necessário derrubar todo sistema.

Anti-pattern: recovery sem comunicação

Section titled “Anti-pattern: recovery sem comunicação”

Incidentes críticos também exigem coordenação.

Quem precisa saber:

  • operator;
  • owner;
  • security;
  • customer support;
  • stakeholder.

A comunicação deve seguir severity e contexto.

Anti-pattern: apagar evidência durante recovery

Section titled “Anti-pattern: apagar evidência durante recovery”

Na pressa de corrigir, não destrua logs, traces e state necessários para investigação.

Containment deve preservar forensic value quando possível.

Anti-pattern: nunca permitir rollback

Section titled “Anti-pattern: nunca permitir rollback”

Adkins et al. mostram que bloquear qualquer rollback elimina uma rota importante de retorno a estado estável. 3

Ao mesmo tempo, rollback não pode reintroduzir vulnerabilidade conhecida sem policy explícita.

Recovery decision tree

Section titled “Recovery decision tree”

método deste livro:

Is the failure still propagating?
  yes → contain


Is previous state safe?
  yes → rollback candidate
  no  → forward fix / degraded mode


Are data effects reversible?
  yes → restore/revert
  no  → compensate


After action:
  verify runtime state

Recovery metrics

Section titled “Recovery metrics”

Métricas úteis:

  • MTTD — detect;
  • MTTC — contain;
  • MTTR — recover;
  • rollback success rate;
  • restore drill success;
  • incident recurrence.

O foco é saber se os mecanismos realmente reduzem tempo e blast radius.

Recovery verification

Section titled “Recovery verification”

Depois de uma ação de recovery, precisamos provar que o sistema retornou a um estado operacional aceitável.

recovery action
  ↓
observed state
  ↓
verified safe

Isso é diferente de runtime acceptance do Capítulo 17. Lá verificamos um estado recém-promovido. Aqui verificamos um estado restaurado, compensado ou degradado após falha.

A pergunta é mais estreita: a ação de recovery realmente reduziu o risco e restabeleceu o comportamento necessário?

Recovery não termina o incidente

Section titled “Recovery não termina o incidente”

Recuperar serviço encerra a fase aguda, não o ciclo de engenharia.

Depois da estabilização, ainda precisamos transformar o incidente em mudança durável:

  • que condição permitiu a falha?
  • que detection/gate faltou?
  • que Context, policy ou runbook estava errado?
  • que action item reduz recorrência?

O próximo capítulo não trata mais de voltar ao estado seguro. Trata de mudar o sistema para que ele saiba mais depois do incidente do que sabia antes: O sistema aprende.

Fronteira de confiança

Section titled “Fronteira de confiança”

Incident response frequentemente exige permissões elevadas. Breakglass, rollback, restore e credential actions devem ser scoped, auditáveis e limitadas à necessidade do incidente. Recuperação rápida não elimina a necessidade de controle.

Evidência exigida

Section titled “Evidência exigida”

Um incidente relevante precisa preservar evidência de detecção, impacto, containment, recovery e verification. Recovery só é considerada concluída quando o estado pós-ação foi verificado contra critérios operacionais.

Rollback e recuperação

Section titled “Rollback e recuperação”

Rollback é uma opção de recovery, não sinônimo de recovery. Data migrations, external side effects e security fixes podem exigir restore, compensation, degraded mode ou forward fix. A policy precisa considerar segurança e confiabilidade. 3

Proveniência das fontes

Section titled “Proveniência das fontes”

Rastreabilidade deste capítulo:

  • CLM-010 — evidência do caso do PCC: gate bloqueou promoção defeituosa e exigiu nova evidência;
  • CLM-062 — Hassan, reversible world e autonomia calibrada por reversibilidade/blast radius;
  • CLM-063 — Hassan, rollback precisa de verificação do estado restaurado;
  • CLM-064 — Adkins et al., rollback como mitigação com trade-off segurança/reliability.

Incident lifecycle Detect → Contain → Recover → Verify → Learn, recovery decision tree, recovery readiness e taxonomy de reversibilidade são método deste livro.

Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.

Recursos complementares

Section titled “Recursos complementares”

Recursos relacionados:

  • INCIDENT.md template;
  • rollback checklist;
  • recovery decision tree;
  • rollback drill worksheet;
  • degraded-mode checklist;
  • recovery verification template;
  • futura visualização PCC de incident → containment → recovery → verification.

Footnotes

Section titled “Footnotes”

  1. Ahmed E. Hassan, Agentic Software Engineering (2026), Core concept: the reversible world and delegation calibration, pp. 292–293. Rastreabilidade interna: CLM-062. ↩ ↩2

  2. Ahmed E. Hassan, Agentic Software Engineering (2026), Core concept: layered verification, p. 293. Rastreabilidade interna: CLM-063. ↩ ↩2

  3. Adkins et al., Building Secure & Reliable Systems (2020), Chapter 9: Design for Recovery — Rollbacks Represent a Tradeoff Between Security and Reliability, pp. 228–230. Rastreabilidade interna: CLM-064. ↩ ↩2 ↩3

  4. Evidência do estudo longitudinal, CE-2026-005; evidências EVID-CE-2026-005-01, EVID-CE-2026-005-02, EVID-CE-2026-005-03, EVID-CE-2026-005-04, EVID-CE-2026-005-05. Rastreabilidade interna: CLM-010. ↩