APRENDER. PRATICAR. EVOLUIR.1. Escolher a falha que o desenho tem de suportar
O requisito fictício diz que a consulta de posições deve continuar após a perda de uma zona. Antes de desenhar réplicas, transforma essa frase num ensaio observável: que operações precisam de continuar, com que dados, latência e capacidade? Perder um processo, um host, uma zona ou uma região são eventos com âmbitos diferentes. Uma VM colocada numa zona continua a ser uma instância nessa zona; o seletor de localização não cria automaticamente outra instância disponível. Desenha os componentes que sobrevivem ao evento escolhido e marca os que deixam de responder. Depois segue um pedido completo, desde o cliente até aos dados. Se o pedido precisa de um componente perdido, a redundância dos restantes ainda não prova a continuidade pretendida.
2. Relacionar placement com falhas correlacionadas
Availability sets distribuem VMs por fault domains e update domains para reduzir certos riscos partilhados e coordenar manutenção. Não devem ser apresentados como equivalentes a um desenho distribuído por zonas para uma falha zonal. No cenário fictício, duas VMs foram separadas logicamente, mas a equipa nunca confirmou o tipo de isolamento. O arquiteto regista a configuração real e o evento que ela cobre. Também compara a necessidade de proximidade e baixa latência com a distância entre domínios de falha. Colocar todos os componentes muito próximos pode ajudar um requisito e concentrar outro risco. A decisão deve mostrar esse compromisso, as limitações aceites e o ensaio que verificará o comportamento. Contar duas VMs não basta para caracterizar independência. Entre subscrições, confirma o mapeamento físico antes de comparar números de zonas lógicas: zona 1 numa subscrição pode corresponder a outra localização física na segunda.
3. Dimensionar os sobreviventes com carga real
Três zonas não garantem capacidade suficiente depois de perder uma. No exercício, as capacidades úteis medidas são 120, 100 e 100 operações por segundo; o pico acordado é 180 e a reserva exigida é 20. Perder a zona maior deixa 200, exatamente o total necessário no modelo. Se a reserva subir para 21, o mesmo desenho deixa de passar. Estes números são fictícios e pressupõem capacidade aditiva e distribuição de trabalho possível. Um sistema real precisa de medir filas, estado, dependências e limites do balanceamento. Não contes capacidade ainda por criar como disponível imediatamente sem provar provisionamento, quotas e tempo de arranque. Ensaiar apenas em horas de baixa utilização pode esconder a insuficiência que aparece precisamente durante o fecho.
4. Confirmar a configuração de disponibilidade de SQL
Um serviço gerido inclui mecanismos de disponibilidade, mas o arquiteto continua a escolher uma configuração que cubra o requisito. Em Azure SQL Database, a redundância por zona depende da opção, tier e suporte aplicáveis. Uma cópia de segurança noutra região não prova que a base continua imediatamente acessível após falhar uma zona. No caso fictício, o diagrama escreve apenas SQL gerido e a equipa assume que o assunto está resolvido. A aceitação pede a configuração efetiva, um ensaio do comportamento do cliente e a comparação com o objetivo do serviço. Ligações podem ter de ser restabelecidas e trabalho em curso pode necessitar de tratamento apropriado. A disponibilidade da base e a conclusão correta de uma operação de negócio precisam de evidências relacionadas, mas distintas. Por exemplo, Basic no modelo DTU não oferece redundância por zona. Numa leitura que falhou com erro transitório de ligação, restabelece a ligação antes de repetir, com uma política limitada; escritas exigem também tratamento do resultado da transação.
5. Relacionar regiões, consistência e clientes Cosmos DB
Num desenho com Cosmos DB, documenta onde são aceites escritas, que regiões o cliente prefere e qual a consistência escolhida. A existência de várias regiões não responde sozinha ao que sucede às escritas durante uma falha. Um procedimento de mudança planeada pressupõe condições diferentes de uma recuperação com uma região indisponível. No cenário fictício, o ensaio anterior mudou a região de escrita com ambas saudáveis; a equipa apresenta-o como prova de recuperação durante uma falha. Pede um teste correspondente ao evento real, incluindo a configuração do SDK e o estado dos dados observados. O negócio deve conhecer o compromisso entre continuidade e possíveis alterações ainda não replicadas. Evita prometer o mesmo resultado para qualquer combinação de consistência, topologia e operação de failover.
6. Distinguir redundância local e cópia geográfica de storage
ZRS distribui cópias por zonas na região primária. GRS e GZRS acrescentam replicação geográfica assíncrona, com diferenças na proteção dentro da região primária. A opção de leitura na secundária também precisa de ser escolhida quando faz parte do desenho; não deves inferir escrita simultânea nas duas regiões. No caso fictício, um consumidor tenta escrever no endpoint secundário durante uma falha e a equipa descobre que o runbook confundiu leitura com promoção do serviço. Descreve a operação de recuperação e as alterações de cliente necessárias. Considera ainda dados recentemente aceites que podem não ter chegado à cópia geográfica. Redundância de infraestrutura não substitui proteção contra uma alteração lógica incorreta que seja propagada às cópias.
7. Seguir dependências até ao resultado de negócio
O front-end sobrevive em duas zonas, mas depende de um serviço interno de configuração que só existe na zona perdida. O pedido continua a falhar. Este caso fictício mostra por que razão o inventário deve incluir identidade, resolução de nomes, certificados, segredos, rede e dados, além das VMs visíveis no diagrama principal. Para cada dependência, regista o efeito de indisponibilidade e se o serviço pode continuar com informação já disponível. Um retry também precisa de semântica: se o resultado de uma escrita ficou desconhecido, repetir cegamente pode duplicar uma instrução. O owner da aplicação deve definir identificação da operação, consulta de resultado e comportamento de repetição. Medir apenas hosts saudáveis deixa por demonstrar a experiência do consumidor.
8. Preparar uma matriz de aceitação por falha
A ficha final deve relacionar falha, deteção, encaminhamento, capacidade, estado dos dados, resultado do cliente e regresso ao serviço normal. No exercício fictício, cada equipa preenche apenas a sua componente; o PM identifica uma lacuna entre a recuperação da base e a retoma do batch. O ensaio integrado acrescenta essa transição e observa o resultado funcional, sem dar como concluída uma etapa pela simples ausência de alarmes. Regista também quem pode iniciar uma recuperação fora de horas e que evidência autoriza o regresso à configuração normal. Uma mudança planeada bem-sucedida e um restore isolado continuam úteis, mas só devem suportar as conclusões que efetivamente demonstram. A aceitação final deve nomear limitações ainda abertas e a pessoa responsável por as resolver.
# Fictional additive capacity model: no Azure calls or availability prediction.
def survives_one_zone(capacity, peak, reserve):
if not capacity or peak < 0 or reserve < 0:
raise ValueError("nonempty zones and nonnegative demand required")
if any(value < 0 for value in capacity.values()):
raise ValueError("negative capacity")
total = sum(capacity.values())
return all(total - lost >= peak + reserve for lost in capacity.values())
assert survives_one_zone({"a": 120, "b": 100, "c": 100}, 180, 20)
assert not survives_one_zone({"a": 120, "b": 100, "c": 100}, 180, 21)
assert not survives_one_zone({"a": 300}, 180, 20)
assert survives_one_zone({"a": 210, "b": 210}, 180, 20)
assert not survives_one_zone({"a": 160, "b": 80, "c": 80}, 180, 0)
assert survives_one_zone({"a": 160, "b": 80, "c": 80}, 150, 10)
print("six fictional surviving-capacity checks passed")
Caso fictício: três zonas suportam a carga normal, mas perder a maior deixa capacidade insuficiente durante o fecho. A equipa ajusta capacidade e ensaia o percurso completo do cliente antes do handover.
Armadilhas comuns
Contar réplicas sem verificar isolamento; ignorar capacidade sobrevivente; confundir mudança planeada com recuperação durante falha; inferir continuidade da aplicação a partir da disponibilidade de uma componente.
Tópicos relacionados: Domínios de falha · Capacidade e degradação · Recuperação e aceitação operacional
Alta disponibilidade precisa de sobreviver à falha escolhida com capacidade, dados e dependências suficientes para cumprir o resultado prometido ao utilizador.
Referência: Reliability in Azure Virtual Machines · AZ-305 objectives 2026-04-17