APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
O desenho de resiliência começa com o serviço que tem de voltar a funcionar. Define quais operações e dependências fazem parte do critério de recuperação. RTO limita o tempo para recuperar; RPO define o ponto temporal dos dados que se pretende recuperar. Não são medidas intercambiáveis. Um restauro de quarenta minutos seguido de trinta de validação sequencial demora setenta minutos até à aceitação dada. Se o objetivo é sessenta, existe uma lacuna. Em contrapartida, instantes medidos desde a falha não se somam como durações. A arquitetura deve ainda expor falhas comuns: aplicações em regiões diferentes podem continuar dependentes do mesmo serviço de identidade ou da mesma chave.
Aplicação guiada
Num ensaio fictício, o último ponto recuperável às catorze horas é das treze e quarenta e dois. São dezoito minutos de perda potencial, acima de um RPO de dez. Regista o desvio sem o esconder pela rapidez do arranque. Para backups imutáveis, distingue modos e condições. Em AWS Backup, compliance mode após a carência impede remover o lock enquanto persistem recovery points abrangidos; governance tem comportamento de autorização diferente. Novos limites de retenção não reescrevem automaticamente os lifecycles existentes. Verifica também por onde passam os controlos: um gateway de entrada não inspeciona automaticamente tráfego lateral. O ensaio deve atravessar filas, autenticação, chaves e reconciliação, com evidência de resultados e ações para as lacunas encontradas.
Portal pronto aos 35, identidade aos 55 e batch aos 80: cadeia completa aos 80 minutos.
Armadilhas comuns
Somar timestamps; confundir RPO com RTO; distribuir compute sem dependências; lock como restauro testado.
Tópicos relacionados: Governance, risco e exceções · Fornecedores, dados e ameaças · Identidade, zero trust e cloud
Mede a cadeia acordada e testa os modos de falha relevantes.
Referência: Contingency planning, RTO and RPO · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17