APRENDER. PRATICAR. EVOLUIR.Define recuperação a partir do processo de negócio
Num serviço fictício, o fecho diário depende de ficheiros de posições, validação, aprovação e envio ao destinatário. O RTO de uma VM não descreve sozinho quando esse processo volta a funcionar. A BIA identifica impacto ao longo do tempo, dependências, prioridades e nível mínimo aceitável de operação. Define também o ponto de dados recuperável e quem pode aceitar perdas ou reconciliações. Na ficha, os 90 minutos são um alvo contratual fictício contado desde a interrupção, não um valor exigido por uma norma. Escreve a origem e o fim do relógio para evitar que equipas meçam fases diferentes e apresentem conclusões incompatíveis.
Percorre dependências em condições degradadas
As instâncias da aplicação estão em A e B, mas ambas usam uma base autogerida e um gateway em A. Perder A deixa a instância B sem a transação completa. Num segundo desenho, há dados e compute em B, mas as credenciais de recuperação, o repositório de imagens e a administração de DNS dependem de A. Um failover com A saudável não demonstra capacidade de arrancar em B quando A desaparece. Faz a revisão a partir de uma operação de negócio e distingue dependências do serviço já em execução de dependências para reconstrução e mudança de tráfego. A documentação AWS sobre localização apoia esta análise; não houve deployment ou falha induzida na AWS neste bloco.
Verifica tempo, ponto de dados e backlog separadamente
O plano fictício soma 10 minutos de deteção, 15 de decisão, 45 de restauro e 25 de validação: 95, cinco acima do alvo de 90. São fases sequenciais segundo o enunciado; só altera a soma se houver paralelismo demonstrado e dependências compatíveis. Para a interrupção às 10:00, o último commit recuperável é 09:42: são 18 minutos, acima do RPO de 10 definido no caso, sem logs adicionais validados. Por fim, processar 140 itens por minuto enquanto chegam 100 deixa capacidade líquida de 40 para um backlog de 1200: 30 minutos no modelo de taxas constantes. Nenhum destes cálculos é uma medição de desempenho ou garantia de recuperação; cada um responde a uma pergunta diferente.
Planeia o ensaio e a decisão de aceitação
Uma discussão tabletop pode revelar contactos em falta, dependências circulares e critérios ambíguos. Não demonstra que backups restauram, permissões funcionam ou a aplicação suporta carga. Define um ensaio autorizado com âmbito, dados adequados, condições de interrupção, responsáveis e evidência esperada. A validação deve incluir o ponto de dados e uma operação funcional representativa, além do estado dos processos técnicos. A equipa APS deve conseguir executar os passos com as suas identidades. Se o ensaio mantém uma dependência que o cenário diz indisponível, regista a exclusão e limita a conclusão. A aceitação deve separar o que foi observado do que continua estimado ou sujeito a decisão.
Inclui fornecedor, capacidade e regresso ao serviço normal
O fornecedor de recuperação promete quatro horas, mas a capacidade é partilhada e vários clientes estão na mesma zona de risco. Clarifica capacidade reservada, prioridade, acesso, comunicações e suporte antes de tratar a promessa como capacidade demonstrada. No orçamento, inclui ensaios, operação paralela, reconciliação e pessoal de prevenção. Recuperar em B também pode gerar dados novos que precisam de reconciliação antes de regressar a A. Se o local principal não puder ser reutilizado, define quem decide permanência ou migração. Resumo: o estado verde da infraestrutura é uma evidência parcial; o fecho exige serviço, dados, acessos e responsabilidades operacionais aceites. Relaciona esta aula com portabilidade, contratos e a matriz de autorização já estudada.
FICHA FICTÍCIA: aceitação da recuperação
Alvo desde interrupção: 90 min.
Fases sequenciais estimadas: deteção 10 + decisão 15 + restauro 45 + validação 25.
Interrupção: 10:00 UTC. Último commit recuperável: 09:42 UTC. RPO: 10 min.
Backlog: 1200 itens. Entrada: 100/min. Processamento total: 140/min. Taxas constantes, sem retries.
Entrega: cálculo | pressupostos | alvo cumprido? | evidência necessária no ensaio real.
Acrescenta identidade, imagens, DNS, dependências externas e decisor.O plano soma 95 minutos para um alvo de 90; o ponto de dados tem 18 minutos para um RPO de 10.
Armadilhas comuns
Contar componentes sem percursos; somar capacidade indisponível; tratar tabletop como ensaio técnico; confundir restauro com aceitação do serviço.
Tópicos relacionados: Continuidade e análise de impacto · Mudança, fornecedores e operação
Liga dependências, tempos, dados e capacidade aos critérios de recuperação do serviço.
Referência: Contingency Planning Guide for Federal Information Systems · CCSP examination outline effective 2026-08-01; January2026 V2 PDF