Desafio 25: projetar objetivos e estratégia de recuperação

Tempo Estimado e Custo

60-90 min | Custo estimado: $0-5 | Peso no Exame: 15-20%

Introdução

O Mercy Regional Health System opera uma rede de hospitais e clinicas atendendo 500.000 pacientes em três estados. Sua infraestrutura de TI suporta tudo, desde sistemas críticos de monitoramento de pacientes até funções administrativas rotineiras. Apos um recente incidente de ransomware em um sistema de saúde vizinho que causou uma interrupcao de 72 horas nos registros de pacientes, o conselho determinou uma estratégia abrangente de disaster recovery.

O CIO categorizou todas as cargas de trabalho em três níveis com base na análise de impacto nos negócios: Nível 1 (crítico) inclui o sistema de Prontuarios Eletronicos (EHR) e monitoramento de pacientes - estes devem recuperar em 1 minuto com zero perda de dados. Nível 2 (importante) inclui o sistema de agendamento, gerenciamento de farmacia e portal de resultados de laboratório - estes podem tolerar até 1 hora de inatividade e 15 minutos de perda de dados. Nível 3 (padrão) inclui RH/folha de pagamento, portais de treinamento e comúnicações internas - estes podem tolerar até 24 horas de inatividade e 4 horas de perda de dados.

O desafio é significativo: Mercy tem um orcamento de DR de apenas $5.000/mes para proteger todos os três níveis. Você deve projetar uma estratégia de recuperação que aloque adequadamente o orcamento entre os níveis, selecionando o padrão de recuperação correto (hot/warm/cold standby) para cada classe de carga de trabalho, comprovando que o SLA composto atende aos requisitos de disponibilidade.

Habilidades do exame cobertas

• Recomendar uma solução de recuperação para cargas de trabalho Azure e híbridas que atenda aos objetivos de recuperação

Tarefas de design

Parte 1: análise de impacto nos negócios e objetivos de recuperação

1. Para cada nível de carga de trabalho, defina formalmente os seguintes parametros de recuperação:

   • Recovery Time Objective (RTO)
   • Recovery Point Objective (RPO)
   • Recovery Level Objective (RLO) - qual nível de funcionalidade e aceitavel durante a recuperação
   • Maximum Tolerable Downtime (MTD) - o máximo absoluto antes que a viabilidade do negócio seja ameacada

2. Calcule a porcentagem de uptime necessária para cada nível:

   • Nível 1: RTO de 1 minuto implica qual porcentagem de SLA?
   • Nível 2: RTO de 1 hora implica qual porcentagem de SLA?
   • Nível 3: RTO de 24 horas implica qual porcentagem de SLA?

3. Documente o impacto nos negócios de exceder o RTO para cada nível (perda financeira por hora, risco a segurança do paciente, penalidades regulatorias).

Parte 2: seleção da estratégia de recuperação

4. Mapeie cada nível de carga de trabalho para o padrão de recuperação aprópriado:

   • Hot standby: Active-active ou active-passive com replicação em tempo real
   • Warm standby: Replica em escala reduzida que pode ser ampliada durante o failover
   • Cold standby: Infraestrutura definida como código, implantada sob demanda durante desastres
   • Backup only: Backups regulares com recuperação a partir do zero

5. Complete esta matriz de decisão para cada nível:

DR Strategy by Workload Tier

Click each cell to reveal the answer. Think about your answer first!

	Tier 1 (Critical)	Tier 2 (Important)	Tier 3 (Standard)
Recovery pattern	?	?	?
Monthly DR cost	?	?	?
Data replication method	?	?	?
Failover automation	?	?	?
Testing frequency	?	?	?

6. Justifique por que hot standby é necessário para o Nível 1, mas seria desperdicar recursos no Nível 3.

Parte 3: composicao de SLA e alocacao de orcamento

7. Calcule o SLA composto para uma carga de trabalho Nível 1 que depende de:

   • Azure Virtual Machines (99,99% com Availability Zones)
   • Azure SQL Database Business Critical (99,995%)
   • Azure Load Balancer (99,99%)
   • Azure ExpressRoute (99,95%)

   Use a formula: SLA Composto = SLA1 x SLA2 x SLA3 x SLA4

8. Determine se o SLA composto atende ao requisito do Nível 1. Se não, projete medidas compensatorias (multi-região, caminhos redundantes) para atingir a meta.

9. Aloque o orcamento de DR de $5.000/mes entre os níveis. Considere que hot standby custa aproximadamente 80-100% dos custos de produção, warm standby custa 30-50%, e cold standby custa 5-10%.

Parte 4: documentação da estratégia de recuperação

10. Crie um documento de estratégia de recuperação que mapeie serviços Azure para cada nível:

    • Nível 1: Quais serviços Azure fornecem RTO inferior a um minuto?
    • Nível 2: Quais serviços fornecem RTO de 1 hora com custo moderado?
    • Nível 3: Quais serviços permitem recuperação em 24 horas com custo mínimo?

11. Defina o cronograma de testes de DR e critérios de validação para cada nível.

Criterios de sucesso

• ⬜RTO, RPO, RLO, and MTD defined for all three workload tiers with business justification
• ⬜Apprópriate recovery pattern (hot/warm/cold) selected for each tier with cost analysis
• ⬜Composite SLA calculated correctly using multiplication formula
• ⬜Budget allocation across tiers documented with cost-per-tier breakdown totaling $5K/month
• ⬜Recovery strategy maps specific Azure services to each tier's requirements
• ⬜DR testing schedule defined with apprópriate frequency per tier

Dicas

Dica 1: Formula de Composicao de SLA

Quando serviços estao encadeados em serie (cada um depende do anterior), multiplique seus SLAs:

SLA Composto = 0,9999 x 0,99995 x 0,9999 x 0,9995 = 0,99925 (aproximadamente 99,925%)

Isso significa aproximadamente 6,5 horas de inatividade por ano. Para melhorar isso, adicione redundância (caminhos paralelos) onde:

Disponibilidade com redundância = 1 - (1 - SLA_A) x (1 - SLA_B)

Por exemplo, circuitos ExpressRoute duplos: 1 - (1 - 0,9995)^2 = 0,99999975

Dica 2: Estimativas de Custo por Padrão de Recuperação

Custos mensais aproximados para uma aplicação tipica de 3 camadas (web + app + DB):

• Hot standby (active-active): $3.000-4.000/mes (replica completa em execução)
• Warm standby (replica em escala reduzida): $800-1.500/mes (SKUs mínimos, pode escalar)
• Cold standby (IaC + backups): $100-300/mes (apenas armazenamento para backups/templates)
• Backup only: $50-150/mes (apenas armazenamento do vault de backup)

Sugestao de alocacao de orcamento: Nível 1 recebe 60-70%, Nível 2 recebe 20-30%, Nível 3 recebe 5-10%.

Dica 3: Serviços Azure por Velocidade de Recuperação

RTO inferior a um minuto (Nível 1):

• Azure SQL Database com failover groups (failover automático)
• Availability Zones para VMs (zone-redundant)
• Azure Front Door / Traffic Manager (failover baseado em DNS)
• Cosmos DB com multi-region writes

RTO de 1 hora (Nível 2):

• Azure Site Recovery (RPO de 15 minutos, minutos para failover)
• Azure SQL geo-restore
• Reimplantação de VM a partir de imagens gerenciadas

RTO de 24 horas (Nível 3):

• Azure Backup com restauração
• Reimplantação a partir de templates ARM/Bicep
• Backups em cold storage com restauração manual

Dica 4: Calculo de Porcentagem de Uptime

Para converter RTO em porcentagem mínima de uptime:

• Minutos em um ano: 525.600
• RTO 1 min: (525.600 - 1) / 525.600 = 99,99981% (mas isso assume apenas UMA interrupcao por ano)
• De forma mais realista, considere metas mensais de SLA:
  • 99,99% = 4,32 min de inatividade/mes
  • 99,95% = 21,6 min de inatividade/mes
  • 99,9% = 43,2 min de inatividade/mes
  • 99% = 7,2 horas de inatividade/mes

Recursos de aprendizagem

• Business continuity and disaster recovery - Cloud Adoption Framework
• Azure Well-Architected Framework - Reliability pillar
• Backup and disaster recovery for Azure applications
• SLA summary for Azure services
• Composite SLA calculation

Verificação de conhecimento

1. Uma carga de trabalho tem SLA composto de 99,9% mas requer 99,99% de disponibilidade. Qual mudança arquitetural fecha essa lacuna de forma mais eficaz?

Adicionar redundância multi-região com failover automático. Quando uma implantação em região única não consegue atingir o SLA alvo apenas pela multiplicacao de componentes, implantar em uma segunda região e usar um balanceador de carga global (Azure Front Door ou Traffic Manager) cria caminhos de disponibilidade paralelos. A formula se torna: 1 - (1 - 0,999)^2 = 0,999999 (99,9999%), que excede o requisito. A contrapartida e aumento de custo e complexidade de sincronizacao de dados.

2. Por que você escolheria warm standby ao inves de hot standby para uma carga de trabalho Nível 2 com RTO de 1 hora?

Warm standby custa 30-50% da produção versus 80-100% para hot standby, e o RTO de 1 hora fornece tempo suficiente para escalar os recursos. Hot standby mantem uma replica em capacidade total funcionando o tempo todo, o que é desnecessário quando você tem 60 minutos para detectar a falha, acionar o failover e escalar uma replica mínima. Warm standby mantem uma versao em escala reduzida em execução (por exemplo, SKUs de VM menores, databases com DTU mais baixo) que pode ser escalada para capacidade de produção dentro da janela de RTO.

3. O sistema EHR de um hospital depende de quatro serviços Azure, cada um com SLA de 99,99%. Qual é o SLA composto, e ele atende a uma meta de 99,99%?

O SLA composto e 0,9999^4 = 99,96%, que NAO atende a meta de 99,99%. Quando múltiplos serviços estao encadeados em serie, o SLA composto e sempre menor que o SLA individual mais fraco. Cada dependência adicional reduz a disponibilidade geral. Para atingir 99,99% com quatro dependências, você precisa de SLAs individuais mais altos (por exemplo, tier Business Critical a 99,995%) ou redundância em uma ou mais camadas para compensar o efeito multiplicativo.

4. Qual é a diferenca principal entre RTO e MTD (Maximum Tolerable Downtime)?

RTO e o tempo alvo de recuperação para sistemas de TI; MTD e o tempo máximo absoluto antes que o próprio negócio seja ameacado. O RTO deve sempre ser menor que o MTD para fornecer uma margem de segurança. Por exemplo, o sistema EHR de um hospital pode ter um RTO de 1 minuto (meta para restaurar o serviço) mas um MTD de 15 minutos (além do qual a segurança do paciente esta em risco e violacoes regulatorias ocorrem). A diferenca entre RTO e MTD e sua margem de segurança para complicacoes inesperadas na recuperação.

Laboratório de validação

Implante uma prova de conceito mínima para validar seu design:

1. Crie um resource group para este laboratório:

az group create --name rg-az305-challenge25 --location eastus

2. Implante duas VMs em diferentes availability zones para observar a composicao de SLA:

az vm create \
  --resource-group rg-az305-challenge25 \
  --name vm-zone1 \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --zone 1 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --no-wait

az vm create \
  --resource-group rg-az305-challenge25 \
  --name vm-zone2 \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --zone 2 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --no-wait

3. Verifique o posicionamento de zona para cada VM:

az vm show \
  --resource-group rg-az305-challenge25 \
  --name vm-zone1 \
  --query "{name:name, zone:zones[0]}" -o table

az vm show \
  --resource-group rg-az305-challenge25 \
  --name vm-zone2 \
  --query "{name:name, zone:zones[0]}" -o table

4. Confirme o tier de SLA listando as atribuicoes de availability zone:

az vm list \
  --resource-group rg-az305-challenge25 \
  --query "[].{Name:name, Zone:zones[0]}" -o table

5. Verifique que ambas as VMs estao em execução em zonas separadas (esta configuração qualifica para SLA de 99,99%):

az vm list \
  --resource-group rg-az305-challenge25 \
  --query "length(unique([].zones[0]))" -o tsv

dica

Esta mini-implantação válida suas decisoes de design com recursos reais do Azure. E opcional, mas recomendada.

Limpeza

az group delete --name rg-az305-challenge25 --yes --no-wait

---

Próximo: Challenge 26: Design Backup & Recovery for Compute