Resiliência e continuidade

TL;DR

Galho 20 da trilha Cloud, e o que fecha o Bloco 4 (Operar em produção). Os quatro galhos anteriores do bloco ensinaram a declarar a infraestrutura como código, enxergá-la com observabilidade, protegê-la com segurança em profundidade e controlar seu custo com FinOps — mas nenhum deles respondeu à pergunta que só aparece quando algo dá errado de verdade: o que acontece quando falha? Este galho responde com uma escada de camadas concêntricas — instância → zona de disponibilidade → região — e um vocabulário preciso (blast radius, SPOF, RTO, RPO) para decidir, workload por workload, quanto investir em sobreviver. Sobe de baixo pra cima: primeiro por que falha é estatística e não hipótese, depois alta disponibilidade (Multi-AZ, health check, auto-recovery, stateless design), depois RTO/RPO e as quatro estratégias de disaster recovery (Backup & Restore → Pilot Light → Warm Standby → Multi-Site Active/Active), depois multi-region a fundo (replicação de dado, roteamento de tráfego, active-passive vs active-active), depois backup, continuidade e teste (3-2-1, imutabilidade, chaos engineering, game day) — e fecha com o capstone do Bloco 4, aplicando as cinco notas à arquitetura de referência inteira. 6 notas, 3 fases, lente dupla AWS ↔ DigitalOcean, e uma honestidade central: a DO entrega HA sólida dentro de uma região e quase nada de DR cross-region de prateleira — o resto é você quem constrói.

Sobre este galho

Resiliência não é um recurso que se liga — é uma disciplina de decisões de arquitetura, cada uma com um preço, tomadas antes do incidente, não durante ele. O fio condutor deste galho sobe a mesma escada de redundância que a nota de abertura desenha: instância única → multi-instância → multi-AZ → multi-region → (raramente) multi-cloud, cada degrau mais caro e mais resiliente que o anterior, e cada um respondendo a um tipo diferente de falha.

Primeiro o porquê — falhas acontecem o tempo todo, blast radius é o conceito central, e “disponível” é uma escala de noves onde cada nove a mais custa desproporcionalmente mais. Depois a mecânica de dentro da região: alta disponibilidade via Multi-AZ, health checks, Auto Scaling, stateless design e graceful degradation (circuit breaker, retry, bulkhead) — o reflexo automático que resolve a queda de uma instância ou de uma zona em segundos, sem decisão humana. Depois o vocabulário e o cardápio de DR: RTO e RPO como os dois números que toda estratégia de continuidade precisa, e as quatro estratégias canônicas da AWS, cada uma um degrau de custo e velocidade. Depois o degrau mais caro: multi-region a fundo — como replicar dado entre regiões (S3 CRR, DynamoDB Global Tables, Aurora Global Database), como rotear tráfego (Route 53 failover, Global Accelerator), e a escolha entre active-passive e active-active. Depois a disciplina de testar: backup como estratégia (3-2-1, AWS Backup), imutabilidade (Vault Lock) e chaos engineering (game day, AWS Fault Injection Service) — porque um plano nunca exercitado é uma suposição, não uma garantia. E fecha com o capstone: a arquitetura de referência do Bloco 3 revisitada sob a lente de resiliência, separando o que já vem de graça do que exige uma decisão consciente de RTO/RPO — e amarrando IaC, Observabilidade, Segurança, FinOps e Resiliência na síntese do Bloco 4 inteiro.

Audiência primária: quem já sabe que “a nuvem cai às vezes” mas nunca formalizou a diferença entre alta disponibilidade e disaster recovery, nunca calculou um RTO/RPO de verdade, e acha que ter backup automático habilitado já é ter um plano de continuidade. Audiência secundária: quem já opera Multi-AZ mas nunca decidiu, com intenção, se um workload específico merece Pilot Light, Warm Standby ou Active-Active — e nunca testou se o plano de DR no papel de fato funciona sob pressão.

Fronteira

O conceito abstrato de replicar estado e distribuir carga geograficamente — independente de provedor — pertence ao domínio Engenharia/Arquitetura de Sistemas; aqui, em Cloud, tratamos a encarnação concreta de cada provedor. Detectar e responder a incidentes em tempo real — error budgets, alerting, runbooks, o processo de um incidente ao vivo, chaos engineering como disciplina contínua — é SRE, tratado em Operação. O custo de cada camada de redundância é a mesma pergunta que atravessa o galho de FinOps desta trilha. O Multi-AZ e réplicas de um banco gerenciado específico já foram cobertos a fundo no galho de Bancos gerenciados — este galho recicla esse conhecimento sob a lente de resiliência, não repete a mecânica. Este galho trata a arquitetura que você desenha antes do incidente: que redundância existe, que RTO/RPO você prometeu, que estratégia de DR está no papel — e linka essas fronteiras em vez de reexplicá-las.

Iniciado

1. 01 — Por que resiliência — falhas acontecem, o tempo todo (Werner Vogels, “everything fails, all the time”); blast radius como conceito central; os níveis de redundância (instância → multi-instância → multi-AZ → multi-region → multi-cloud); disponibilidade como escala de noves e o custo de cada um; failure modes; caso prático da Black Friday; AWS (39 regiões/123 AZs) ↔ DigitalOcean (15 datacenters/12 regiões, sem AZ de primeira classe).

Adepto

2. 02 — Alta disponibilidade — HA como o reflexo automático dentro de uma região: zona de disponibilidade como unidade de isolamento, SPOF e redundância N+1, health checks + Auto Scaling + Route 53 failover, stateless design (por que a instância nova pode simplesmente assumir), graceful degradation (circuit breaker, retry com backoff, timeout, idempotência, bulkhead); a tensão com FinOps; Multi-AZ nativo da AWS vs a granularidade mais enxuta (e honesta) da DigitalOcean.
3. 03 — RTO, RPO e estratégias de DR — quando o failover automático não dispara: RTO e RPO como os dois números que definem tudo, tiers de criticidade, as quatro estratégias canônicas da AWS (Backup & Restore, Pilot Light, Warm Standby, Multi-Site Active/Active) com custo multiplicativo por região, caso prático de uma empresa com quatro tiers e quatro estratégias, AWS Resilience Hub para validar o plano; DR na DigitalOcean é construído à mão (backup no mesmo datacenter, sem produto de DR cross-region).
4. 04 — Multi-region a fundo — o degrau mais caro: por que replicação entre regiões é sempre assíncrona (velocidade da luz), S3 Cross-Region Replication, DynamoDB Global Tables (multi-master, MREC/MRSC, last-writer-wins), Aurora Global Database (switchover/failover, write forwarding); roteamento (Route 53 failover, Global Accelerator); active-passive vs active-active; compliance e residência de dados; a lacuna honesta da DigitalOcean (sem Global Tables, sem CRR nativo, rclone manual).
5. 05 — Backup, continuidade e teste — e se o dado em si estiver errado, apagado ou sequestrado? Regra 3-2-1, AWS Backup como orquestrador central (backup plans, tags, cross-region/cross-account), Vault Lock (Governance vs Compliance, imutabilidade que nem o root reverte), Business Continuity Plan além da infraestrutura, testar o DR (restore test, game day) e chaos engineering (AWS Fault Injection Service — actions, targets, stop conditions); a DigitalOcean sem orquestrador central, sem imutabilidade nativa, sem FIS.

Magus

6. 06 — Resiliência da arquitetura de referência — o que a arquitetura serverless de referência já ganha de graça (Lambda/S3/DynamoDB multi-AZ nativo dentro da região) vs onde ainda há um SPOF regional escondido; a árvore de decisão RTO/RPO → estratégia de DR aplicada camada por camada; o triângulo resiliência × custo × complexidade; a lente dupla AWS (kit completo de DR cross-region) vs DigitalOcean (HA sólida dentro da região, DR cross-region é engenharia própria); a síntese do Bloco 4 inteiro — IaC, Observabilidade, Segurança, FinOps e Resiliência como a interseção que define “operar em produção”. Capstone do galho e do Bloco 4; ponte para o Bloco 5 (Provedores e maestria).

Rotas alternativas

Completa

01 → 02 → 03 → 04 → 05 → 06. Percurso linear — o porquê, a alta disponibilidade dentro da região, o vocabulário e o cardápio de DR, o degrau multi-region, a disciplina de testar, e a síntese aplicada à arquitetura de referência.

Já tenho Multi-AZ, quero fechar o plano de continuidade

03 (RTO/RPO e as quatro estratégias — o vocabulário que toda decisão de DR usa) → 05 (backup como estratégia, imutabilidade e a disciplina de testar — sem isso, o plano de DR é suposição) → 06 (a árvore de decisão aplicada, camada por camada, a um sistema real).

Todas as notas

TABLE fase, status FROM "03-Dominios/Tecnologia/Cloud/20 - Resiliência e continuidade" WHERE type = "concept" SORT file.name ASC

Veja também

• Cloud (MOC do domínio)
• Bancos gerenciados — Galho 9, o Multi-AZ e as réplicas de banco que este galho recicla sob a lente de resiliência
• FinOps — Galho 19, a economia da nuvem que tensiona toda decisão de redundância e DR deste galho
• Operação — a disciplina de SRE (error budgets, alerting, runbooks, chaos engineering como programa contínuo) que responde ao incidente que este galho se prepara para sobreviver