APRENDER. PRATICAR. EVOLUIR.Definir o serviço que tem de regressar
Para um serviço fictício de posições, recuperar não significa apenas ligar uma base de dados. Define quais leituras e escritas são aceites, que reconciliação confirma os saldos e quem autoriza reabrir o serviço. O RTO precisa de uma fronteira de medição acordada. Se começa na falha, deteção e decisão fazem parte da duração. O RPO descreve o ponto de dados tolerado e deve ser confrontado com evidência recuperável. Uma réplica configurada continuamente pode estar atrasada. Regista também mensagens em trânsito e operações de origem externa: um único timestamp de base de dados pode não explicar todo o estado do processo de negócio.
Encontrar dependências que atravessam regiões
Percorre a configuração do serviço de recuperação e identifica referências à região principal. Um segredo replicado não ajuda se a aplicação continua a consultar o endpoint original. Valida a cópia regional e o acesso à chave que a protege. Para multi-Region keys KMS, políticas e grants precisam de tratamento regional; material relacionado não significa autorização sincronizada. Acrescenta imagens, ficheiros de configuração e integrações externas à lista de dependências. Em cada linha, pergunta se o destino arranca quando a origem está indisponível. A resposta deve ser sustentada por um exercício apropriado, sem depender de credenciais mais amplas do que as previstas para produção.
Calcular a sequência com paralelismo explícito
No exercício didático, dados e rede começam juntos. Os dados demoram dezoito minutos e a rede sete. A configuração só começa quando ambos terminam e demora quatro; a validação seguinte demora seis. O tempo desse plano é max(18,7)+4+6, ou vinte e oito minutos. Se houve três minutos anteriores de deteção e decisão incluídos no RTO, a duração total é trinta e um. Não somes tarefas paralelas nem retires passos obrigatórios para melhorar o número. A medição identifica onde uma melhoria altera realmente o resultado: reduzir a rede de sete para quatro não encurta este caminho crítico.
Distinguir serviço funcional de capacidade suficiente
Um warm standby pode estar funcional com capacidade reduzida. No exemplo, suporta cento e vinte pedidos por segundo, mas o failover exige quatrocentos e aumentar capacidade demora doze minutos. A equipa precisa de antecipar capacidade ou acordar admissão e degradação controladas durante essa janela. Não concluas que todos os utilizadores podem entrar porque uma transação simples passou. Se o desenho exige criar componentes durante o incidente, identifica dependências do plano de controlo, quotas e disponibilidade de recursos. Pilot light e warm standby são escolhas a comprovar contra o objetivo do serviço, não rótulos que garantem automaticamente um RTO.
Proteger coerência antes de reabrir escritas
Uma mudança DNS não constitui, por si, promoção da base de dados nem exclusão de um writer antigo. Antes de abrir escritas, demonstra qual destino tem autoridade e como o outro fica impedido de produzir alterações incompatíveis. O mecanismo concreto depende da tecnologia e deve ser ensaiado. Se a falha é corrupção lógica já replicada, promover a cópia pode conservar o problema. A recuperação precisa então de um ponto limpo, reconciliação e tratamento de operações legítimas posteriores. Separa continuidade de acesso e correção do estado. Regista a decisão de negócio, porque restabelecer rapidamente um saldo incorreto não é recuperação aceite.
Comparar custos sob compromissos equivalentes
FINOPS propõe desligar componentes que passam pouco tempo ocupados. Antes de aceitar, mede o plano de recuperação resultante com o mesmo RTO, capacidade e dados exigidos. Num modelo fictício independente, A=10+0,05V e B=30+0,01V têm custo igual aos quinhentos GB. Abaixo desse volume A é mais barato; acima B é mais barato. A conclusão depende dos custos declarados e de requisitos equivalentes. Se um Resolver partilhado permanece necessário, retirar um consumidor não elimina toda a sua fatura. Fecha a análise com hipótese de volume, recursos realmente removíveis e data para rever consumo. O resumo combina duração completa, dados corretos, capacidade suficiente e custo marginal demonstrável.
Caso guiado: o serviço regressa em 31 minutos perante um RTO de 30. Reduzir rede não resolve o atraso, pois dados dominam a fase paralela. Propõe uma melhoria no caminho crítico sem retirar a validação funcional.
Armadilhas comuns
Omitir deteção do RTO; promover dados corrompidos; confundir DNS com fencing; reduzir custo fixo sem medir o novo arranque; considerar grants KMS globais.
Tópicos relacionados: RTO, RPO e caminho crítico · KMS e segredos regionais · Capacidade, FINOPS e reconciliação
A recuperação só está demonstrada quando o serviço volta com dados e capacidade aceitáveis dentro da janela acordada, usando dependências disponíveis.
Referência: Disaster recovery options in the cloud · SAA-C03