Princípios de design de confiabilidade

Interrupções e defeitos 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 fornecendo consistentemente sua funcionalidade pretendida. Ele deve ser resiliente para que possa detectar, resistir e se recuperar de falhas dentro de um período de tempo aceitável. 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 operando. Em algum momento, a experiência do usuário pode ser afetada, o que compromete as metas 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. Essas alterações devem ser consideradas compensações significativas.

Os princípios de design destinam-se a fornecer diretrizes para aspectos de confiabilidade que você deve considerar em todo o ciclo de vida de desenvolvimento. Comece com as abordagens recomendadas e justifique os benefícios de um conjunto de requisitos. Depois de definir sua estratégia, conduza 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 prever ou lidar com problemas na produção. O resultado pode ser interrupções de serviço que levam à perda financeira. No caso de cargas de trabalho críticas, não aplicar esses princípios pode comprometer a segurança.

Design para requisitos de negócios

Reúna os requisitos de negócios com foco no utilitário pretendido da carga de trabalho.

Os requisitos devem abranger experiência do usuário, dados, fluxos de trabalho e características exclusivas da carga de trabalho. O resultado do processo de requisitos deve declarar claramente as expectativas. As metas devem ser alcançáveis e negociadas com a equipe, dado um investimento especificado. Eles devem ser documentados para impulsionar escolhas tecnológicas, implementações e operações.

Abordagem	Benefício
Quantifique o sucesso definindo metas em indicadores para componentes individuais, fluxos do sistema e o sistema como um todo. Esses destinos tornam os fluxos de usuário mais confiáveis?	As métricas quantificam as expectativas. Eles permitem que você entenda as complexidades e determine se os custos downstream dessas complexidades estão dentro do limite de investimento. Os valores de destino indicam um estado ideal. Você pode usar os valores como limites de teste que ajudam a detectar desvios desse estado e quanto tempo leva para retornar ao estado de destino. Os requisitos de conformidade também devem ter resultados previsíveis para fluxos no escopo. Priorizar esses fluxos chamam a atenção para áreas mais sensíveis.
Entenda os compromissos da plataforma. Considere os limites, cotas, regiões e restrições de capacidade para serviços .	Os SLAs (contratos de nível de serviço) variam de acordo com o serviço. Nem todos os serviços e recursos são abordados igualmente. Nem todos os serviços ou recursos estão disponíveis em todas as regiões. A maioria dos limites de recursos de assinatura é por região. Ter uma boa compreensão da cobertura e dos limites pode ajudá-lo a detectar descompasso e criar mecanismos de resiliência e recuperação.
Determine as dependências e seus efeitos sobre a resiliência.	Manter o controle de infraestrutura, serviços, APIs e funções dependentes desenvolvidos por outras equipes ou terceiros ajuda a determinar se a carga de trabalho pode operar na ausência dessas dependências. Ele também ajuda você a entender as falhas em cascata e melhorar as operações downstream. Os desenvolvedores podem implementar padrões de design resilientes para lidar com possíveis falhas quando você usa serviços externos que podem ser suscetíveis a falhas.

Design para resiliência

A carga de trabalho deve continuar operando com funcionalidade completa ou reduzida.

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 ser degradado normalmente.

Abordagem	Benefício
Distingue 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 criticalidade ajuda você a projetar de acordo com a criticalidade de cada componente. Você não usará resiliência excessiva para componentes que possam deteriorar ligeiramente a experiência do usuário, em vez de componentes que podem causar problemas de ponta a ponta se falharem. O design 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.
Identifique possíveis pontos de falha no sistema, especialmente para os componentes críticos, e determine o efeito nos fluxos do usuário.	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 das funcionalidades de tratamento de erros no nível do componente.
Crie recursos de autopreservação usando padrões de design corretamente e modularizando o design para isolar falhas.	O sistema poderá evitar que um problema afete componentes downstream. O sistema poderá atenuar falhas transitórias e permanentes, gargalos de desempenho e outros problemas que podem afetar a confiabilidade. Você também poderá minimizar o raio da explosão.
Adicione a capacidade de escalar horizontalmente os componentes críticos (aplicativo e infraestrutura) considerando as restrições de capacidade dos serviços nas regiões com suporte.	A carga de trabalho será capaz de lidar com picos de capacidade variável e flutuações. Essa funcionalidade é crucial quando há uma carga inesperada no sistema, como um aumento no uso válido. Se a carga de trabalho for projetada para escalar horizontalmente em várias regiões, ela poderá até mesmo superar possíveis restrições de capacidade temporária de recursos ou outros problemas que afetam em uma única região.
Crie redundância em camadas e resiliência em várias camadas de aplicativo. Aponte para redundância em utilitários físicos e replicação imediata de dados. Também visa a 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 um componente, interrupção zonal ou regional, a implantação redundante (em ativo-ativo ou ativo-passivo) permitirá que você atenda às metas de tempo de atividade. A adição de intermediários impede a dependência direta entre componentes e melhora o buffer. Esses dois benefícios endurecem a resiliência do sistema.
Provisionamento excessivo para atenuar imediatamente a falha individual de instâncias redundantes e para armazenar em buffer o consumo de recursos sem controle.	O maior investimento em superprovisionamento aumenta a resiliência. O sistema continuará operando em um utilitário completo 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 de recursos descontrolado inesperado reivindicando o buffer planejado, ganhando tempo crítico de triagem, antes que ocorram falhas do sistema ou dimensionamento agressivo.

Design para recuperação

A carga de trabalho deve ser capaz de prever e se recuperar da maioria das falhas, de todas as magnitudes, com interrupção mínima para a experiência do usuário e os objetivos de negócios.

Mesmo sistemas altamente resilientes precisam de abordagens de preparação para desastres, tanto no design da 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 planos de recuperação estruturados, testados e documentados 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 recuperação rápida que pode evitar impacto negativo nas finanças e na reputação de seus negócios. A realização de análises 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 as principais medidas de sucesso.
Certifique-se de que você pode reparar dados de todos os componentes com estado dentro de seus destinos de recuperação.	Os backups são essenciais para levar o sistema de volta a um estado de trabalho usando um ponto de recuperação confiável, como o último estado válido conhecido. Backups imutáveis e transacionalmente consistentes garantem que os dados não possam ser alterados e que os dados restaurados não estejam corrompidos.
Implemente recursos automatizados de autorrecuperação no design.	Essa automação reduz os riscos de fatores externos, como a intervenção humana, e reduz o ciclo de correção de interrupção.
Substitua componentes sem estado por unidades efêmeras imutáveis.	A criação de unidades efêmeras que você pode criar e destruir sob demanda fornece repetibilidade e consistência. Use modelos de implantação lado a lado para fazer a transição para as novas unidades incrementais, minimizando interrupções.

Design para operações

Deslocar para a esquerda nas operações para prever condições de falha.

Teste falhas no início e frequentemente no ciclo de vida de desenvolvimento e determine o impacto do desempenho na confiabilidade. Para fins de análise de causa raiz e pós-morte, você precisa ter visibilidade compartilhada, entre equipes, de dependência status e falhas contínuas. Insights, diagnóstico e alertas de sistemas observáveis são fundamentais para um gerenciamento eficaz de incidentes e melhoria contínua.

Abordagem	Benefício
Crie sistemas observáveis que podem correlacionar a telemetria.	Monitoramento e diagnóstico são operações cruciais. Se algo falhar, você precisará saber se ele falhou, quando falhou e por que falhou. A observabilidade no nível do componente é fundamental, mas a observabilidade agregada de componentes e fluxos de usuário correlacionados fornece uma visão holística do status de integridade. Esses dados são necessários para permitir que os engenheiros de confiabilidade do site priorizem seus esforços para correção.
Prever possíveis defeitos e comportamento anormal. Torne as falhas de confiabilidade ativas visíveis usando alertas priorizados e acionáveis. Invista em processos confiáveis e infraestrutura que levem a uma triagem mais rápida.	Os engenheiros de confiabilidade do site podem ser notificados imediatamente para que possam atenuar os incidentes contínuos do site ao vivo e mitigar proativamente possíveis falhas identificadas por alertas preditivos antes de se tornarem incidentes dinâmicos.
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 de recuperação. Isso permite que você faça escolhas de design que respondam normalmente a falhas. Além disso, ele permite que você teste os limites definidos para métricas de negócios.
Crie componentes com automação em mente e automatize o máximo possível.	A automação minimiza o potencial de erro humano, trazendo consistência para testes, implantação e 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 em andamento, como revisões de aplicativo, auditorias de segurança e conformidade, atualizações de componentes e processos de backup. Examinar essas alterações garante a estabilidade do sistema.
Aprenda continuamente com incidentes em produção.	Com base nos incidentes, você pode determinar o impacto e as supervisões no design e nas operações que podem passar despercebidas na pré-produção. Em última análise, você poderá promover melhorias com base em incidentes da vida real.

Simplifique

Evite criar demais o design da arquitetura, o código do aplicativo e as operações.

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 controle, minimizando ineficiências e possíveis configurações incorretas ou interações inesperadas. Por outro lado, a simplificação excessiva pode introduzir pontos únicos de falha. Mantenha uma abordagem equilibrada.

Abordagem	Benefício
Adicione componentes à sua arquitetura somente se eles ajudarem você a alcançar valores comerciais de destino. Mantenha o caminho crítico enxuto.	A criação de requisitos de negócios pode levar a uma solução simples que é fácil de implementar e gerenciar. Evite ter muitos componentes críticos, pois cada um deles é um ponto significativo de falha.
Estabeleça padrões em implementação, implantação e processos de código e documente-os. Identifique oportunidades para impor esses padrões usando validações automatizadas.	Os padrões fornecem consistência e minimizam 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 se traduzem em design pragmático que se aplica 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 que são resultado de implementações ineficientes, como consumo inesperado de recursos, falhas de fluxo de dados ou usuário e bugs de código. Por outro lado, 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 predefinidos que podem ajudá-lo a atender efetivamente às metas de negócios.	Essa abordagem minimiza o tempo de desenvolvimento. Ele também permite que você confie em práticas testadas e testadas que foram usadas com cargas de trabalho semelhantes.

Próximas etapas

Lista de verificação de confiabilidade