Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Interrupções e avarias são preocupações sérias para todas as cargas de trabalho. Uma carga de trabalho confiável deve sobreviver a esses eventos e continuar a fornecer consistentemente a funcionalidade pretendida. Deve ser resiliente para que possa detetar e resistir a falhas enquanto continua a funcionar. Deve ser recuperável para que, se uma interrupção exceder as medidas de resiliência, a carga de trabalho possa ser restabelecida dentro dos objetivos de recuperação acordados. Ele também deve estar disponível para que os usuários possam acessar a carga de trabalho durante o período de tempo prometido no nível de qualidade prometido.
Não é realista assumir que falhas não ocorrerão, especialmente quando a carga de trabalho é criada para ser executada em sistemas distribuídos. Alguns componentes podem falhar, enquanto outros continuam a funcionar. Em algum momento, a experiência do usuário pode ser afetada, o que compromete os objetivos de negócios.
As arquiteturas de carga de trabalho devem ter garantias de confiabilidade no código do aplicativo, na infraestrutura e nas operações. As opções de design não devem alterar a intenção especificada pelos requisitos de negócios. Tais alterações devem ser consideradas compensações significativas.
Os princípios de design destinam-se a fornecer orientação para aspetos de confiabilidade que você deve considerar durante todo o ciclo de vida do desenvolvimento. Comece com as abordagens recomendadas e justifique os benefícios para um conjunto de requisitos. Depois de definir sua estratégia, direcione ações usando a lista de verificação Confiabilidade.
Se você não aplicar esses princípios ao seu design, a carga de trabalho provavelmente não estará preparada para antecipar ou lidar com problemas na produção. O resultado pode ser a interrupção de serviços que conduz a perdas financeiras. No caso de cargas de trabalho críticas, a não aplicação destes princípios pode pôr em risco a segurança.
Design para requisitos de negócios
|
|
|---|
Design não é adivinhação com base em resultados indefinidos ou vagos. A confiabilidade requer uma atividade deliberada que alcance o alinhamento sobre a experiência aceitável do usuário, as restrições de design e como o sucesso se parece e como ele é medido.
Estabeleça metas claras, realizáveis e documentadas, negociadas com as partes interessadas do negócio e fundamentadas em um investimento e previsão realistas. Esses requisitos informarão diretamente suas escolhas arquitetônicas, desde estratégias de resiliência até ferramentas de observabilidade e planos de escala.
| Abordagem | Benefício |
|---|---|
| Concentre-se na coleta de informações necessárias para definir o escopo e a profundidade da solução. Esclareça as restrições que influenciam os objetivos de negócios. Comece com perguntas de alto nível, como: - Que nível de resiliência, recuperação, observabilidade e simplicidade é necessário? - Existem restrições definidas relacionadas com custo, conformidade, geografia ou latência? Com base nessas informações, documente o que é bom o suficiente e simples de alcançar. |
Compreender os objetivos e os limites evitará adivinhações. Caso contrário, você pode ficar preso em um loop de design iterativo, resultando em esforços desperdiçados e custos desnecessários. |
| Orientar a tomada de decisões traduzindo os objetivos de negócios em compreensão compartilhada das compensações arquitetônicas dentro de restrições reais. Apresente opções com impacto: - Custo financeiro - Complexidade da engenharia - Considerações de segurança - Despesas gerais operacionais |
Isso ajudará as partes interessadas a entender o custo, a complexidade e as implicações operacionais de suas solicitações e orientá-las para resultados realistas e alinhados. |
|
Priorize a definição de resultados de confiabilidade para cada fluxo crítico de usuários em vez de medições genéricas, como tempo de atividade. Identifique os recursos e fluxos voltados para o usuário através do sistema e, para cada um, avalie seu valor comercial, padrões de uso e requisitos de resiliência. Conduza o consenso no nível do fluxo para garantir que as decisões de projeto permaneçam alinhadas aos objetivos de negócios. |
Essa conversa ajuda a deslocar as partes interessadas de declarações insustentáveis, como "o site deve estar sempre ativo", para expectativas práticas e realizáveis vinculadas à funcionalidade e resultados reais. Esses resultados ajudam a estabelecer o que é resolvido com a tecnologia e o que pode ser resolvido com planos adicionais de continuidade de negócios. |
|
Ancorar as escolhas de design em torno de horizontes temporais. Defina as expectativas de uso com previsões realistas. Por exemplo, qual é a carga de usuário esperada no lançamento? Espera-se que o crescimento de usuários seja linear, exponencial ou incerto? |
Essas informações ajudarão você a projetar uma arquitetura que atenda às necessidades de confiabilidade de curto prazo, evitando decisões de projeto que exigirão retrabalho significativo para lidar com horizontes futuros. Essa abordagem afeta como pensar em elasticidade, fluxos de trabalho orientados a eventos e permite que você faça escolhas estratégicas em torno de qual dívida técnica incorrer ou evitar. |
|
Considere as dependências que podem limitar a autonomia da conceção, como restrições organizacionais. Esteja ciente da infraestrutura centralizada, mandatos de segurança, políticas de roteamento de rede ou decisões de plataforma que afetam diretamente o que você pode prometer em termos de resiliência, disponibilidade e recuperação. |
Compreender a sua dependência de serviços fora do seu controlo ajuda-o a projetar com expectativas realistas de fiabilidade. Ele garante que suas metas de RTO/RPO e SLOs sejam alcançáveis e claramente comunicadas, evitando promessas excessivas e reduzindo surpresas. |
Design para resiliência
|
|
|---|
Você deve esperar que ocorram falhas de componentes, interrupções de plataforma, degradações de desempenho, disponibilidade limitada de recursos e outras falhas. Crie resiliência no sistema para que ele seja tolerante a falhas e possa degradar-se graciosamente.
| Abordagem | Benefício |
|---|---|
| Distinga os componentes que estão no caminho crítico daqueles que podem funcionar em um estado degradado. | Nem todos os componentes da carga de trabalho precisam ser igualmente confiáveis. Determinar a criticidade ajuda a projetar de acordo com a criticidade de cada componente. Você não fará engenharia excessiva de resiliência para componentes que podem deteriorar ligeiramente a experiência do usuário, ao contrário de componentes que podem causar problemas de ponta a ponta se falharem. O projeto pode ser eficiente na alocação de recursos para componentes críticos. Você também pode implementar estratégias de isolamento de falhas para que, se um componente não crítico falhar ou entrar em um estado degradado, ele possa ser isolado para evitar falhas em cascata. |
| Identificar potenciais pontos de falha no sistema, especialmente para os componentes críticos, e determinar o efeito nos fluxos de usuários. | Você pode analisar os casos de falha, o raio de explosão e a intensidade da falha: interrupção total ou parcial. Essa análise influencia o design de recursos de tratamento de erros no nível do componente. |
| Crie recursos de autopreservação usando padrões de projeto corretamente e modularizando o projeto para isolar falhas. | O sistema será capaz de evitar que um problema afete os componentes a jusante. O sistema será capaz de mitigar falhas transitórias e permanentes, gargalos de desempenho e outros problemas que podem afetar a confiabilidade. Você também será capaz de minimizar o raio de explosão. |
| Adicione a capacidade de dimensionar os componentes críticos (aplicativo e infraestrutura) considerando as restrições de capacidade dos serviços nas regiões suportadas. | A carga de trabalho será capaz de lidar com picos e flutuações de capacidade variável. Essa capacidade é crucial quando há uma carga inesperada no sistema, como um aumento no uso válido. Se a carga de trabalho for projetada para ser dimensionada em várias regiões, ela poderá até mesmo superar possíveis restrições temporárias de capacidade de recursos ou outros problemas que afetem uma única região. |
|
Crie redundância em camadas e resiliência em várias camadas de aplicativos. Ter como objetivo a redundância nas infraestruturas físicas e a replicação imediata de dados. Visar também redundância na camada funcional que abrange serviços, operações e pessoal. |
A redundância ajuda a minimizar pontos únicos de falha. Por exemplo, se houver uma interrupção de componente, zonal ou regional, a implantação redundante (em ativo/ativo ou ativo/passivo) permitirá que você atinja as metas de tempo de atividade. A adição de intermediários evita a dependência direta entre componentes e melhora o buffer. Ambos os benefícios endurecem a resiliência do sistema. |
| Superprovisionamento para mitigar imediatamente a falha individual de instâncias redundantes e para proteger contra o consumo descontrolado de recursos. | Um maior investimento em excesso de provisionamento aumenta a resiliência. O sistema continuará a operar com plena funcionalidade durante uma falha ativa, mesmo antes que as operações de dimensionamento possam começar a corrigir a falha. Da mesma forma, você pode reduzir o risco de consumo inesperado de recursos descontrolados, reivindicando seu buffer planejado, ganhando tempo de triagem crítico, antes que ocorram falhas no sistema ou dimensionamento agressivo. |
Projeto para recuperação
|
|
|---|
Mesmo sistemas altamente resilientes precisam de abordagens de preparação para desastres, tanto no projeto de arquitetura quanto nas operações de carga de trabalho. Na camada de dados, você deve ter estratégias que possam reparar o estado da carga de trabalho em caso de corrupção.
| Abordagem | Benefício |
|---|---|
| Ter estruturado, testado e documentado planos de recuperação alinhados com as metas de recuperação negociadas. Os planos devem abranger todos os componentes, além do sistema como um todo. | Um processo bem definido leva a uma rápida recuperação que pode evitar impactos negativos nas finanças e na reputação do seu negócio. A realização de exercícios de recuperação regulares testa o processo de recuperação de componentes do sistema, dados e etapas de failover e failback para evitar confusão quando o tempo e a integridade dos dados são medidas fundamentais de sucesso. |
| Certifique-se de poder reparar os dados de todos os componentes com estado dentro das suas metas de recuperação. | Os backups são essenciais para que o sistema volte a funcionar usando um ponto de recuperação confiável, como o último estado válido. Backups imutáveis e transacionalmente consistentes garantem que os dados não possam ser alterados e que os dados restaurados não sejam corrompidos. |
| Implemente recursos automatizados de autorrecuperação no projeto. | Essa automação reduz os riscos de fatores externos, como a intervenção humana, e encurta o ciclo de reparação. |
| Substitua componentes sem estado por unidades efêmeras imutáveis. | A construção de unidades efêmeras que você pode girar e destruir sob demanda fornece repetibilidade e consistência. Use modelos de implantação lado a lado para tornar a transição para as novas unidades incremental, minimizando interrupções. |
Projeto para operações
|
|
|---|
Teste falhas no início e frequentemente no ciclo de vida do desenvolvimento e determine o impacto do desempenho na confiabilidade. Por uma questão de análise de causa raiz e postmortems, você precisa ter visibilidade compartilhada, entre as equipes, do status de dependência e falhas contínuas. Insights, diagnósticos e alertas de sistemas observáveis são fundamentais para o gerenciamento eficaz de incidentes e a melhoria contínua.
| Abordagem | Benefício |
|---|---|
| Construa sistemas observáveis que possam correlacionar a telemetria. | A monitorização e o diagnóstico são operações cruciais. Se algo falhar, você precisa saber que falhou, quando falhou e por que falhou. A observabilidade no nível do componente é fundamental, mas a observabilidade agregada dos componentes e fluxos de usuários correlacionados fornece uma visão holística do estado de saúde. Esses dados são necessários para permitir que os engenheiros de confiabilidade do local priorizem seus esforços de remediação. |
| Prever potenciais avarias e comportamentos anómalos. Torne visíveis as falhas de confiabilidade ativas usando alertas priorizados e acionáveis. Invista em processos e infraestrutura confiáveis que levem a uma triagem mais rápida. |
Os engenheiros de confiabilidade do local podem ser notificados imediatamente para que possam mitigar incidentes contínuos no local ativo e mitigar proativamente possíveis falhas identificadas por alertas preditivos antes que se tornem incidentes ativos. |
| Simule falhas e execute testes em ambientes de produção e pré-produção. | É benéfico experimentar falhas na produção para que você possa definir expectativas realistas para a recuperação. Isso permite que você faça escolhas de design que respondem graciosamente a falhas. Além disso, ele permite que você teste os limites definidos para métricas de negócios. |
| Crie componentes com a automação em mente e automatize o máximo que puder. | A automação minimiza o potencial de erro humano, trazendo consistência aos testes, à implantação e às operações. |
| Fator nas operações de rotina e seu impacto na estabilidade do sistema. | A carga de trabalho pode estar sujeita a operações contínuas, como revisões de aplicativos, auditorias de segurança e conformidade, atualizações de componentes e processos de backup. O escrutínio dessas alterações garante a estabilidade do sistema. |
| Aprenda continuamente com os incidentes na produção. | Com base nos incidentes, você pode determinar o impacto e os descuidos no design e nas operações que podem passar despercebidos na pré-produção. Em última análise, você será capaz de impulsionar melhorias com base em incidentes da vida real. |
Mantenha a simplicidade
|
|
|---|
Muitas vezes, é o que você remove, em vez do que você adiciona, que leva às soluções mais confiáveis. A simplicidade reduz a área de superfície para controlo, minimizando ineficiências e potenciais erros de configuração ou interações inesperadas. Por outro lado, a simplificação excessiva pode introduzir pontos únicos de falha. Manter uma abordagem equilibrada.
| Abordagem | Benefício |
|---|---|
| Adicione componentes à sua arquitetura somente se eles ajudarem você a atingir os valores de negócios desejados. Mantenha o caminho crítico eficiente. | Projetar para requisitos de negócios pode levar a uma solução simples que é fácil de implementar e gerenciar. Evite ter muitos componentes críticos, porque cada um é um ponto significativo de falha. |
| Estabeleça padrões na implementação, implantação e processos de código e documente-os. Identifique oportunidades para aplicar esses padrões usando validações automatizadas. | As normas proporcionam consistência e minimizam os erros humanos. Abordagens como convenções de nomenclatura padrão e guias de estilo de código podem ajudá-lo a manter a qualidade e facilitar a identificação de ativos durante a solução de problemas. |
| Avalie se as abordagens teóricas são traduzidas em design pragmático aplicável aos seus casos de uso. | O código do aplicativo muito granular pode levar a interdependência desnecessária, operações extras e manutenção difícil. |
| Desenvolva apenas código suficiente. | Você poderá evitar problemas resultantes de implementações ineficientes, como consumo inesperado de recursos, falhas de usuário ou fluxo de dados e bugs de código. Por outro lado, os problemas de confiabilidade devem levar a revisões de código para garantir que o código seja resiliente o suficiente para lidar com os problemas. |
| Aproveite os recursos fornecidos pela plataforma e os ativos pré-criados que podem ajudá-lo a atingir efetivamente as metas de negócios. | Essa abordagem minimiza o tempo de desenvolvimento. Ele também permite que você confie em práticas testadas e comprovadas que foram usadas com cargas de trabalho semelhantes. |