Azure: Reliability vs Resiliency vs Recoverability

Introdução: porque isto importa

Em muitas revisões pós-incidente, as equipas descobrem que otimizaram a coisa errada — investindo muito em runbooks de disaster recovery quando a aplicação precisava, na verdade, de melhor isolamento de falhas, ou assumindo que infraestrutura “redundante” produz automaticamente uma experiência de utilizador fiável. A orientação mais recente da Microsoft traça uma linha clara entre reliability, resiliency e recoverability no Azure, e mostra como construir continuidade por design em vez de por suposições.

Conceitos-chave (e o princípio âncora)

A Microsoft enquadra estes conceitos como ideias distintas e complementares:

• Reliability: O grau em que um serviço/workload executa de forma consistente ao nível de serviço pretendido dentro de restrições de negócio definidas. Este é o objetivo final que os clientes experienciam.
• Resiliency: A capacidade de suportar falhas e disrupções (outages zonais/regionais, falhas de infraestrutura, ciberataques, picos de carga) e continuar a operar sem impacto visível para o cliente.
• Recoverability: A capacidade de restaurar as operações normais após uma disrupção, quando os limites de resiliency são excedidos.

Princípio âncora: Reliability é o objetivo. Resiliency mantém-te operacional durante a disrupção. Recoverability restaura o serviço quando a disrupção excede os limites de design.

O que há de novo / o que a Microsoft está a enfatizar

1) Alinhar o modelo operacional com a arquitetura

O artigo liga a intenção organizacional ao design técnico:

• O Microsoft Cloud Adoption Framework (CAF) ajuda a definir governação, accountability e expectativas de continuidade.
• O Azure Well-Architected Framework (WAF) traduz essas expectativas em padrões de arquitetura e tradeoffs.

2) Tornar reliability mensurável e operacional

Reliability só importa se a conseguires demonstrar continuamente:

• Definir níveis de serviço aceitáveis para fluxos críticos de utilizador.
• Instrumentar o steady-state e a experiência do cliente com Azure Monitor e Application Insights.
• Validar suposições com testes de falhas controlados (por exemplo, Azure Chaos Studio).
• Escalar a governação com Azure Policy, Azure landing zones e Azure Verified Modules.
• Usar o Reliability Maturity Model para avaliar a consistência das práticas de reliability.

3) Tratar resiliency como um ciclo de vida (não como uma checklist)

Resiliency é apresentada como uma prática contínua:

• Start resilient (padrões em design-time, configurações secure-by-default, proteções da plataforma)
• Get resilient (avaliar apps existentes, priorizar workloads mission-critical, fechar lacunas)
• Stay resilient (monitorizar, detetar drift e validar continuamente)

4) Mudar para uma postura de resiliency centrada na aplicação

A Microsoft destaca que os utilizadores experienciam outages de aplicações — não eventos de VM/disco. A zone resiliency experience do Azure suporta o agrupamento de recursos em grupos lógicos de serviços de aplicação, avaliando risco, acompanhando drift e orientando a remediação com visibilidade de custos.

Impacto para administradores de IT e equipas de plataforma

• Limites mais claros de shared responsibility: O comportamento incorporado do serviço vs. o que tens de configurar torna-se explícito através dos guias de Azure Reliability.
• Melhores decisões de design: Consegues distinguir quando investir em design zonal/multi-region (resiliency) versus backups/processos de failover (recoverability).
• Maior preparação para incidentes: SLOs mensuráveis, observabilidade e chaos drills reduzem os “unknown unknowns” durante outages reais.

Ações / próximos passos

1. Uniformizar a terminologia entre equipas (reliability vs. resiliency vs. recoverability) e atualizar os standards de arquitetura em conformidade.
2. Rever os Azure Reliability guides de cada serviço core que utilizas para confirmar o comportamento face a falhas e os requisitos de configuração.
3. Mapear workloads para padrões zonal, zone-resilient ou multi-region com base em failure domains e no impacto no negócio.
4. Implementar SLOs + monitoring (Azure Monitor/App Insights) e agendar fault injection drills (Chaos Studio).
5. Usar Policy/landing zones para evitar configuration drift e normalizar controlos de resiliency em escala.