Converta requisitos de negócio em metas de confiabilidade, arquitetura resiliente e recuperável, operações observáveis e soluções deliberadamente simples.
Tempo de estudo sugerido: 88 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. Trate a confiabilidade como capacidade da carga
O pilar de Confiabilidade do Well-Architected avalia se uma carga permanece disponível, resiste a falhas e volta a um estado saudável depois de uma interrupção. Indisponibilidade, dependência degradada, implantação defeituosa, capacidade esgotada e corrupção de dados são riscos normais de sistemas distribuídos. O projeto confiável detecta problemas, contém o impacto, mantém as jornadas prioritárias na qualidade acordada e se recupera de forma previsível.
Confiabilidade não é um complemento da infraestrutura. Código, dados, recursos do , entrega, monitoramento e resposta a incidentes precisam sustentar as mesmas promessas de negócio. Cada medida traz custo ou complexidade; por isso, o arquiteto precisa de requisitos explícitos, não de uma solicitação indefinida para que tudo fique sempre online.
Requisitos de negócio, resiliência, recuperação, operações e simplicidade formam um único sistema.
Resumo do tópico
Projete a confiabilidade no código, infraestrutura, dados e operações e compare o resultado com promessas mensuráveis de negócio.
2. Use cinco princípios conectados
Princípios de confiabilidade e sua pergunta central.
Princípio
Pergunta de arquitetura
Requisitos de negócio
Quais fluxos importam e quais metas mensuráveis de serviço e recuperação exigem?
Resiliência
Como a carga preservará funcionalidade total ou reduzida quando ocorrer uma falha?
Recuperação
Como componentes e estado voltarão a uma condição operacional confiável?
Operações
Como as equipes observarão, preverão, testarão e aprenderão com os riscos?
Simplicidade
Quais componentes, códigos personalizados e processos podem ser removidos ou padronizados?
Os princípios dependem uns dos outros. Redundância sem monitoramento pode esconder uma réplica quebrada; recuperação sem exercício é apenas um documento; dimensionamento automático sem objetivo de fluxo pode aumentar custos sem proteger a jornada correta. A confiabilidade também precisa ser equilibrada com Eficiência de Desempenho e Otimização de Custos.
Resumo do tópico
Aplique os cinco princípios como uma única estrutura de decisão e registre as compensações de custo, desempenho e operação.
3. Comece o projeto da Contoso Insurance pelos requisitos
Considere uma seguradora fictícia que cria um aplicativo Web para processar sinistros. A solução combina ,, serviços de IA do , e . Antes de escolher camadas ou replicação, equipe e partes interessadas definem experiência do usuário, dados, fluxos de trabalho, conformidade, orçamento e restrições operacionais.
A aplicação é dividida em fluxos de usuário e de sistema. O envio e a aprovação do sinistro recebem a maior criticidade porque médicos e pacientes dependem deles. Os componentes de apoio herdam metas adequadas, em vez de cada recurso receber a arquitetura mais cara.
Resumo do tópico
Comece por expectativas de negócio compartilhadas e alcançáveis e pela criticidade dos fluxos; serviços e investimento vêm depois.
4. Defina metas para fluxos, componentes e para a carga completa
Defina objetivos de nível de serviço e recuperação para componentes individuais, fluxos importantes de usuário ou sistema e a carga como um todo. Métricas transformam intenção em critério testável e mostram se a arquitetura cabe no orçamento. Disponibilidade, latência, taxa de erro, taxa de transferência, RTO, RPO, tempo médio de recuperação e duração do estado degradado são exemplos úteis.
Fluxos sujeitos a conformidade precisam de resultados inequívocos. O sistema de monitoramento é dependência e controle operacional, mas não é um dos escopos de negócio para os quais o exercício pede metas de confiabilidade da carga. Separe os objetivos da carga das ferramentas que os medem.
Cada meta permanece rastreável do resultado esperado ao recurso que sustenta o fluxo.
Resumo do tópico
Associe metas mensuráveis aos fluxos críticos, aos componentes de apoio e à carga ponta a ponta; teste operação normal e recuperação.
5. Entenda compromissos e restrições da plataforma
Os contratos de nível de serviço do variam por serviço, camada, região, topologia e funcionalidade. Consulte os da Microsoft para serviços online para confirmar a disponibilidade garantida; preço, FAQ ou artigo geral não são a fonte contratual. Inclua limites, cotas, capacidade regional, manutenção e recursos fora do .
Se o fluxo crítico exige RTO de até 30 segundos, a equipe pode avaliar a camada comercialmente crítica do com replicação geográfica ativa. Ainda são necessários monitoramento, ensaiado, tratamento de conexões, análise de perda de dados e capacidade na secundária. Comprar a camada não comprova o RTO.
Resumo do tópico
Fundamente a promessa no aplicável, nos limites, nas cotas, na capacidade e na topologia testada.
6. Mapeie todas as dependências internas e externas
Documente infraestrutura, , funções, fontes de dados, identidade, , certificados, redes, terceiros e processos de outras equipes. Para cada dependência, registre fluxos consumidores, meta, comportamento de falha, , tolerância a dados antigos, proprietário e escalonamento. Assim aparecem falhas em cascata e consequências posteriores.
O fluxo de sinistros depende de um pequeno conjunto de referência mantido por outro departamento. Sua disponibilidade é inferior à do fluxo; a aplicação tolera defasagem limitada, mas não a ausência. Um local elimina a dependência em tempo de execução e uma tarefa em segundo plano o atualiza. Atualização noturna só é válida quando a tolerância de negócio aceita essa idade.
Desacoplar altera a falha, mas introduz decisões de atualidade e reconciliação.
Resumo do tópico
Inclua todas as dependências e aplique , fila, isolamento ou fallback somente quando a compensação de consistência for aceitável.
7. Projete o fluxo de reservas da Contoso Air para resiliência
Uma companhia aérea fictícia usa ,,, e . A compra da passagem é o fluxo mais importante, portanto a equipe concentra as melhorias onde a falha gera maior impacto ao negócio e ao cliente.
O de pagamento externo é altamente disponível, mas pode devolver erros transitórios por rede ou picos simultâneos. O projeto síncrono original obriga o cliente a reenviar pagamentos rejeitados. A solução deve melhorar a experiência sem duplicar a cobrança nem perder o pedido.
Resumo do tópico
Priorize a resiliência pela criticidade e pelo impacto do fluxo, mesmo quando o ponto fraco é um serviço externo altamente disponível.
8. Analise os modos de falha antes de testar
Para cada falha possível, descreva gatilho, componente, raio de impacto, intensidade, duração, sinal de detecção, efeito visível e recuperação. Inclua perda temporária de processo, saturação e limitação, além de eventos de zona ou região. Classifique probabilidade e impacto para investir nos riscos prioritários.
Um exercício de DDoS ou outro teste disruptivo deve ser precedido pela análise de modos de falha. Defina fronteira esperada, proteções, condições de interrupção, aprovações, telemetria e recuperação segura antes de gerar estresse.
O teste de falhas é seguro e útil quando limites e comportamento esperado são conhecidos.
Resumo do tópico
Use a análise de modos de falha para classificar riscos e definir experimentos controlados antes de injetar falhas.
9. Crie autopreservação com repetição e isolamento
Autopreservação evita que uma dependência defeituosa consuma o sistema inteiro. Limites modulares, , repetição, , bulkheads, nivelamento de carga, idempotência e degradação controlada tratam riscos diferentes. Repita somente operações seguras e erros transitórios; aumente o intervalo, use jitter e limite tentativas para não ampliar a sobrecarga.
No cenário aéreo, o separa a interação do cliente do processamento. Um worker repete falhas temporárias. Ao alcançar o limite, para de pressionar o e mantém ou transfere a mensagem para tratamento posterior. Correlação, deduplicação, mensagem problemática, visibilidade ao cliente e reconciliação são essenciais.
A fila protege o fluxo e a dependência enquanto preserva o trabalho para recuperação.
Resumo do tópico
Combine repetição limitada, isolamento, idempotência, contrapressão e uma rota durável de falha; nunca repita indefinidamente.
10. Adicione redundância nas camadas corretas
A redundância pode cobrir energia, instalações, zonas, regiões, réplicas de dados, instâncias, caminhos de rede, funções, processos e pessoas. Escolha ativo-ativo ou ativo-passivo conforme consistência, , capacidade, custo e maturidade. Filas amortecem a demanda e reduzem o acoplamento direto.
A camada premium do pode usar zonas de disponibilidade em regiões compatíveis. A recuperação geográfica de desastre oferece configuração secundária para continuidade regional; diferencie replicação de da replicação dos dados das mensagens e confirme o comportamento atual. Somente exercícios comprovam a redundância.
Cada camada responde a um raio de impacto diferente.
Resumo do tópico
Use replicação geográfica quando o modelo de dados e recuperação permitir e teste o comportamento exato de do serviço.
11. Prepare a plataforma analítica da Contoso para recuperação
Uma solução fictícia ingere SQL Server local com e usa ,, e . Um processo Windows legado roda em VM. Como os usuários são internos e a carga não é crítica, a equipe aceita uma região e reconstrução em outra após desastre.
A escolha só é válida quando metas, dados de origem, definições de infraestrutura, identidades, rede, segredos, capacidade e procedimento tornam a reconstrução possível no prazo prometido.
Resumo do tópico
Uma arquitetura de região única pode ser correta quando a reconstrução testada e a proteção dos dados cumprem as metas explícitas.
12. Crie e exercite um plano completo de recuperação
O plano de recuperação de desastre cobre cada componente e o sistema ponta a ponta: autoridade, detecção, declaração, comunicação, , validação, ,, integridade e encerramento. Mantenha o runbook acessível durante o incidente e registre proprietários, dependências, credenciais, automação, capacidade, e ações de terceiros.
A equipe analítica escreveu um plano de reconstrução, mas não o ensaiou. Uma indisponibilidade real revelou etapas ausentes. A correção é atualizar o runbook e antecipar o exercício completo. O tempo médio para restaurar um banco a partir do backup é uma medida diretamente útil ao plano.
O documento vira capacidade somente depois de ensaios realistas.
Resumo do tópico
Documente, automatize, atribua responsáveis e ensaie e ; use tempos medidos de restauração para validar o RTO.
13. Recupere dados com estado a partir de um ponto confiável
Cada componente com estado precisa de um método compatível com RPO e RTO. Backups devem ser imutáveis quando necessário, consistentes em transação, isolados do mesmo domínio de falha, retidos por política e restaurados regularmente. Replicação reduz RPO, mas pode copiar corrupção; não substitui pontos independentes.
No cenário, bancos acima de 4 TB ficam em com SQL Server 2022. O Backup Automatizado protege todos. Os críticos também usam o vínculo da Instância Gerenciada para replicar à . Confirme direção, ,, política de atualização, versão e região atuais. Tornar uma conta do multirregional é outro exemplo de recuperação de estado.
Resumo do tópico
Combine backups restauráveis e replicação adequada; valide consistência, imutabilidade, compatibilidade e procedimentos de e .
14. Adicione autorrecuperação automatizada
A autorrecuperação usa sinais de integridade e automação limitada para reiniciar, recriar imagem, substituir ou redirecionar um componente. Reduz tempo e erro manual, mas precisa de período de carência, limites, proteção de estado, escalonamento e observabilidade.
O processo Windows pode rodar em . A extensão de Integridade do Aplicativo informa a saúde e os reparos automáticos podem reiniciar, recriar a imagem ou substituir a instância conforme a configuração aceita. Ações do também podem iniciar uma reinicialização aprovada. verifica conformidade e recomenda melhorias; nenhum deles é a ação direta deste exemplo.
Recuperar dados e reparar componentes atendem partes distintas da meta.
Resumo do tópico
Acione o reparo por sinais confiáveis, limite a automação, preserve o estado e escale quando as tentativas falharem.
15. Opere os microsserviços da Contoso University com visibilidade
Uma universidade fictícia usa cinco serviços desacoplados com ,,,,, e . Uma solicitação cruza várias camadas; todos os recursos verdes isoladamente não provam que matrícula ou acesso às aulas funciona.
A operação precisa enxergar a jornada ponta a ponta, a saúde das dependências e falhas correntes. A visibilidade compartilhada acelera triagem, causa raiz, -mortem e priorização.
Resumo do tópico
Monitore fluxos de usuário e de sistema entre serviços, não apenas a saúde isolada dos recursos.
16. Correlacione telemetria em um sistema observável
Instrumente a aplicação e combine telemetria com e métricas da plataforma. O captura o comportamento; sinais relevantes seguem para um do Analytics no . Identificadores de correlação conectam a mesma solicitação entre camadas, filas e bancos.
O modelo deve cobrir sintomas do usuário, saturação, dependências, implantações, transações e automação. Retenção, acesso, custo, amostragem e proteção de dados sensíveis também fazem parte do projeto.
A observabilidade explica quando, onde e por que um fluxo degradou.
Resumo do tópico
Tornar a carga observável significa emitir e correlacionar telemetria acionável da jornada completa, com governança.
17. Antecipe problemas com alertas acionáveis e capacidade
Um alerta deve indicar condição que exige responsável e resposta definida. Priorize por fluxo e urgência, elimine duplicação e inclua contexto e runbook. Sinais informativos ficam em painéis quando ninguém precisa agir imediatamente.
A universidade prevê pico no início do período. Prepara as camadas Web e de banco para escalar horizontalmente e prioriza alertas de matrícula, conteúdo e compras. Capacidade antecipada e dimensionamento por métricas devem ser testados contra cotas, limites, dependências, atraso e custo.
Resumo do tópico
Combine capacidade e dimensionamento testados com alertas priorizados e acionáveis, cada um com proprietário e resposta.
18. Teste a confiabilidade antes e em produção
Exercite falhas, modo degradado, recuperação e limites de negócio em pré-produção e, com proteção, em produção. Exercício de mesa testa decisões; teste de carga avalia demanda; simular uma falha de componente comprova operação degradada.
A matrícula sazonal usa certificados de cliente. Transações sintéticas mensais percorrem o fluxo e avisam sobre falha ou expiração. Experimentos de caos entram no ciclo de desenvolvimento com hipótese, escopo, condição de parada, telemetria e resultados. A evidência valida autopreservação e descobre acoplamentos.
Resumo do tópico
Use transações sintéticas e caos controlado para comprovar jornadas, degradação e recuperação antes de um incidente.
19. Simplifique a carga da Contoso Travel
Uma empresa fictícia adquire uma aplicação Node.js em VMs locais e na AWS. Um recurso de feedback no site quase não é usado, pois clientes preferem as redes sociais. Cada recurso extra adiciona código, dependências, risco de implantação, monitoramento e suporte.
A equipe remove o feedback da primeira versão. A base menor reduz custo sem violar requisito. Simplicidade não é remoção cega: simplificar demais pode criar ponto único de falha, portanto confira as metas.
Resumo do tópico
Mantenha somente componentes justificados por resultado de negócio, sem remover a redundância exigida.
20. Padronize o ciclo de vida de desenvolvimento
A equipe adquirida usa bibliotecas sobrepostas, estilos inconsistentes e sem gates automatizados. Grandes versões exigem ou hotfix, mobilizam todos, prejudicam reputação e experiência.
Padronize linguagens, , bibliotecas, padrões, nomes, estilo, documentação, testes e implantação. Formatação, análise estática, segurança, regressão e gates detectam desvios cedo. Documente ferramentas e padrões para revisão e solução de problemas.
Resumo do tópico
Padronizar ferramentas, documentação e testes reduz variação humana e torna entrega, manutenção e incidentes repetíveis.
21. Prefira recursos gerenciados ao ônus personalizado
A equipe transfere o Node.js de VMs para . A instrumentação automática do substitui código próprio, enquanto dimensionamento automático, integração com e redundância de zona atendem requisitos onde disponíveis. A mudança reduz código e infraestrutura próprios; não transforma automaticamente a aplicação em sem servidor.
A plataforma reduz código indiferenciado e mantém controles explícitos.
Resumo do tópico
Use funções comprovadas da plataforma quando cumprirem o requisito e reserve engenharia personalizada para valor de negócio distinto.
22. Revise a decisão completa de confiabilidade
Classifique fluxos e defina metas mensuráveis de disponibilidade e recuperação.
Valide , limites, cotas, capacidade e dependências internas e externas.
Analise modos de falha e crie autopreservação limitada e redundância em camadas.
Proteja estado com backups testados e replicação adequada; ensaie e .
Correlacione telemetria, encaminhe alertas acionáveis e teste degradação com sintéticos e caos.
Remova componentes injustificados, padronize o ciclo e prefira capacidades gerenciadas.
Na prova, conecte requisito, modelo de falha, capacidade do , evidência de teste e proprietário operacional. Réplica, fila, investigação de integridade ou alerta só tem valor quando atende à meta e suas compensações são conhecidas.
Arquitetura confiável é um acordo continuamente testado entre metas de negócio, resiliência, estado recuperável, operações observáveis e simplicidade disciplinada.
