Designer de DR Multi-Região (RTO/RPO primeiro)
Derive o padrão de DR a partir de RTO/RPO, exponha os bloqueadores ocultos e planeje failover e failback.
Por Os Melhores Prompts
Categoria: Nuvem
O que ele faz
Parte de RTO e RPO e trabalha de trás para frente até um padrão - backup/restore, pilot light, warm standby ou active-active - e declara o RTO e o RPO que realmente acredita que você vai atingir sempre que isso divergir da meta. Não deixa o failover fácil da camada stateless disfarçar o banco de dados: replicação assíncrona faz do lag o seu RPO real, e escritas síncronas entre regiões compram RPO com latência em cada requisição. Também enumera os assassinos chatos: TTL de DNS e propagação de health check, quotas e capacidade na região standby, chaves KMS e secrets que não existem lá, e o plano de failback que ninguém escreve.
Use quando
- Um compromisso de RTO/RPO escrito em contrato com cliente
- Um plano de DR que nunca sobreviveu a um game day
- Um banco cujo lag de replicação define o RPO real
- Precificar active-active contra warm standby para o negócio
O que você recebe
- Um padrão por camada com o RTO/RPO realmente atingível
- Replicação por store, lag e destino das escritas em voo
- Mecânica de failover: roteamento, health checks e promoção
- Checklist de bloqueadores: quotas, KMS, IAM e imagens
- Plano de failback, game days e estimativa de custo mensal
Como usar
- Descreva compute, data stores, filas, dependências e o desenho de regiões em `{{system_architecture}}`.
- Informe RTO e RPO por camada em `{{rto_rpo_targets}}` e quem assinou - projetos baseados em metas presumidas acabam caros demais ou lentos demais.
- Detalhe cada store em `{{data_stores}}`: engine, tamanho, taxa de escrita, opções de replicação e necessidade de consistência; a taxa de escrita e o lag de replicação, não a topologia de compute, definem seu RPO real.
- Liste em `{{failure_scenarios}}` os cenários a sobreviver - perda de AZ, perda de região, queda de control plane, deploy ruim, ransomware - e em `{{budget_and_ops}}` o teto de custo, o tamanho do time e a maturidade do plantão.
- Execute os game days definidos e registre o RTO medido; o plano não é válido enquanto esse número não existir.
Tags: cloud, disaster-recovery, reliability, architecture, rto-rpo, failover, multi-region, business-continuity
Preço: 10.00 BRL