Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A criação de um aplicativo crítico em qualquer plataforma de nuvem exige uma abordagem de engenharia pensada. Há complexidade relacionada a: entender os recursos da plataforma, selecionar os serviços corretos, configurá-los corretamente, operacionalizá-los efetivamente e manter-se alinhado com as melhores práticas e roteiros de serviço em evolução.
Para navegar por essa complexidade, estabeleça uma metodologia de design clara e simples que se alinhe aos seus requisitos de negócios, especialmente em tempo de atividade e recuperação. Quando a tomada de decisões se torna desafiadora ou você se encontra preso à paralisia da análise, retorne à sua metodologia como ponto de referência. Ele pode ajudar a validar suas escolhas, manter seu design focado e garantir o alinhamento com suas metas gerais.
Este artigo sugere uma metodologia de design que é informada por insights obtidos com a revisão de vários aplicativos críticos implantados no Azure.
Design para seus objetivos de confiabilidade
Missão crítica não significa o mesmo para todos. A arquitetura variará de acordo com os requisitos de negócios da carga de trabalho e o tempo de inatividade aceitável. Geralmente, eles são definidos por SLOs (Objetivos de Nível de Serviço), como 99,9% de disponibilidade no nível% e 99,999% no nível%. Considere que os objetivos de disponibilidade envolvem mais do que apenas o tempo de operação. Eles representam um serviço consistente em relação a um estado de aplicativo saudável. Como ponto de partida, as equipes devem definir quanto tempo de inatividade é aceitável. Use uma calculadora de Tempo de Atividade/Tempo de Inatividade para determinar o tempo de inatividade tolerável.
Essa metodologia de design pode servir como ponto de partida para decisões e compensações arquitetônicas após a definição dos objetivos. À medida que uma arquitetura de destino de rascunho toma forma e o custo e a complexidade ficam mais claros, os requisitos iniciais podem ser revisitados, desafiados, ajustados ou resolvidos por meio de soluções alternativas.
Por exemplo, embora uma configuração de várias zonas de região única possa ser suficiente para muitas cargas de trabalho críticas, maior confiabilidade exige mais esforço de engenharia e complexidade. Evite optar por soluções complexas, como a configuração ativa-ativa em várias regiões, a menos que haja requisitos sólidos que justifiquem essa necessidade.
RTO (Objetivo de Tempo de Recuperação) e RPO (Objetivo de Ponto de Recuperação) também são fundamentais para definir as necessidades de confiabilidade. Por exemplo, se sua meta for recuperar um aplicativo em menos de um minuto, as estratégias baseadas em backup ou ativas-passivas provavelmente não serão rápidas o suficiente.
Lutar pela automação de ponta a ponta
Adote uma estratégia de automação abrangente que abrange a implantação e as atividades de gerenciamento contínuas. Essa metodologia enfatiza a consistência, a repetibilidade e a resiliência por meio de princípios centrados na automação.
Áreas típicas para automação incluem tarefas rotineiras, como aplicação de correções, dimensionamento e monitoramento, visando reduzir o esforço manual e os erros. Favoreça modelos para configuração e implantação para garantir a consistência e a clareza, usando scripts somente quando os modelos não são viáveis.
Design para implantações de tempo de inatividade zero
Implantações de tempo de inatividade zero garantem que os usuários não experimentem nenhuma interrupção durante as alterações.
Essa metodologia exige testes de pré-lançamento rigorosos para que as atualizações não introduzam defeitos, vulnerabilidades ou instabilidade. Para dar suporte a isso, as ferramentas e os processos de implantação devem estar altamente disponíveis e resilientes.
Consistência é a chave. Os mesmos artefatos e processos automatizados devem ser usados em todos os ambientes para eliminar qualquer chance de erros manuais e reduzir o risco geral. A automação de ponta a ponta não é apenas preferencial; é obrigatório para alcançar implantações confiáveis, repetíveis e sem interrupções.
Design para detecção e recuperação rápidas de falhas
A detecção rápida de falhas começa com um modelo de saúde bem definido. Como as falhas geralmente são cascatas entre componentes, a detecção precoce e a dependência clara entre os componentes da carga de trabalho são inegociáveis para minimizar o raio de explosão e acelerar a recuperação.
Isso significa identificar claramente como é saudável e não saudável para cada componente, com base em fluxos reais de usuários e limites de negócios para desempenho e disponibilidade. Essas definições devem orientar as métricas que você monitora e ajudar a rastrear problemas de volta à causa raiz.
Consulte o guia de design sobre modelagem de saúde
Evoluir com o Azure
Crie sua arquitetura para ser modular e flexível para que seja mais fácil adotar novos recursos sem grandes alterações. Examine regularmente seu design para se manter atualizado com os serviços e funcionalidades em evolução do Azure. Priorize os serviços gerenciados nativos do Azure para sua menor sobrecarga operacional e melhor integração. Como o Azure é atualizado com frequência, alinhar sua arquitetura com seu roteiro ajuda a garantir que seu aplicativo permaneça otimizado e pronto para o futuro.
Consulte Evolve com Azure e atualizações do Azure para obter as informações mais recentes sobre novos serviços e recursos.
Próxima etapa
Inicie seu percurso de design examinando como os pilares do Well-Architected Framework se aplicam à classe crítica de cargas de trabalho.
As áreas de design estão interconectadas, portanto, as alterações em uma área podem afetar outras. Comece com a área mais crítica para sua empresa e examine as considerações e recomendações para entender como suas escolhas criam compensações em toda a arquitetura.
Consulte essas arquiteturas de referência que descrevem as decisões de design com base nessa metodologia.